diff options
Diffstat (limited to 'Documentation')
567 files changed, 49761 insertions, 11258 deletions
diff --git a/Documentation/.gitignore b/Documentation/.gitignore index 2c8b2d612e..9022d48355 100644 --- a/Documentation/.gitignore +++ b/Documentation/.gitignore @@ -11,3 +11,7 @@ doc.dep cmds-*.txt mergetools-*.txt manpage-base-url.xsl +SubmittingPatches.txt +tmp-doc-diff/ +GIT-ASCIIDOCFLAGS +/GIT-EXCLUDED-PROGRAMS diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index a600e35c81..45465bc0c9 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -1,5 +1,5 @@ Like other projects, we also have some guidelines to keep to the -code. For Git in general, three rough rules are: +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." @@ -18,6 +18,14 @@ code. For Git in general, three rough rules are: 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 @@ -34,7 +42,17 @@ For shell scripts specifically (not exhaustive): - We use tabs for indentation. - - Case arms are indented at the same depth as case and esac lines. + - 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"' @@ -43,13 +61,21 @@ For shell scripts specifically (not exhaustive): 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 + The output of 'which' is not machine parsable and its exit code is not reliable across platforms. - We use POSIX compliant parameter substitutions and avoid bashisms; @@ -65,39 +91,70 @@ For shell scripts specifically (not exhaustive): - 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. The - opening "{" should also be on the same line. - E.g.: my_function () { + - 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\}, - [::], [==], nor [..]) for portability. + [::], [==], or [..]) for portability. - We do not use \{m,n\}; - We do not use -E; - - We do not use ? nor + (which are \{0,1\} and \{1,\} + - 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). @@ -106,6 +163,19 @@ For shell scripts specifically (not exhaustive): 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 @@ -113,11 +183,36 @@ For C programs: - 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. That means that you should not use C99 - initializers, even if a lot of compilers grok it. + 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 identifier at the end. - - Variables have to be declared at the beginning of the block. + . 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. @@ -126,19 +221,69 @@ For C programs: "char * string". This makes it easier to understand code like "char *string, c;". + - Use whitespace around operators and keywords, but not inside + parentheses and not around functions. So: + + while (condition) + func(bar + 1); + + and not: + + while( condition ) + func (bar+1); + + - Do not explicitly compare an integral value with constant 0 or '\0', + or a pointer value with constant NULL. For instance, to validate that + counted array <ptr, cnt> is initialized but has no elements, write: + + if (!ptr || cnt) + BUG("empty array expected"); + + and not: + + if (ptr == NULL || cnt != 0); + BUG("empty array expected"); + - We avoid using braces unnecessarily. I.e. if (bla) { x = 1; } - is frowned upon. A gray area is when the statement extends - over a few lines, and/or you have a lengthy comment atop of - it. Also, like in the Linux kernel, if there is a long list - of "else if" statements, it can make sense to add braces to - single line blocks. - - - We try to avoid assignments inside if(). + 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 @@ -153,9 +298,101 @@ For C programs: * 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. @@ -165,11 +402,19 @@ For C programs: 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 it. + - 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, should be git-compat-util.h or another - header file that includes it, such as cache.h or builtin.h. + - 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 @@ -188,6 +433,17 @@ For C programs: - Use Git's gettext wrappers to make the user interface translatable. See "Marking strings for translation" in po/README. + - Variables and functions local to a given source file should be marked + with "static". Variables that are visible to other source files + must be declared with "extern" in header files. However, function + declarations should not use "extern", as that is already the default. + + - 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. @@ -233,15 +489,42 @@ 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. + - As a minimum, we aim to be compatible with Python 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: @@ -260,15 +543,21 @@ Writing Documentation: 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: + 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>.) @@ -285,12 +574,12 @@ Writing Documentation: (Zero or more of <patch>. Note that the dots are inside, not outside the brackets.) - Multiple alternatives are indicated with vertical bar: + Multiple alternatives are indicated with vertical bars: [-q | --quiet] [--utf8 | --no-utf8] Parentheses are used for grouping: - [(<rev>|<range>)...] + [(<rev> | <range>)...] (Any number of either <rev> or <range>. Parens are needed to make it clear that "..." pertains to both <rev> and <range>.) @@ -312,3 +601,40 @@ Writing Documentation: 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/Documentation/Makefile b/Documentation/Makefile index 4f13a23893..ecd0b340b1 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -2,13 +2,19 @@ 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 += gitremote-helpers.txt MAN1_TXT += gitweb.txt MAN5_TXT += gitattributes.txt @@ -23,26 +29,36 @@ MAN7_TXT += gitcore-tutorial.txt MAN7_TXT += gitcredentials.txt MAN7_TXT += gitcvs-migration.txt MAN7_TXT += gitdiffcore.txt +MAN7_TXT += giteveryday.txt +MAN7_TXT += gitfaq.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 = git-remote-helpers.html -DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML) +OBSOLETE_HTML += everyday.html +OBSOLETE_HTML += git-remote-helpers.html -ARTICLES = howto-index -ARTICLES += everyday +ARTICLES += howto-index ARTICLES += git-tools ARTICLES += git-bisect-lk2009 # with their own formatting rules. -SP_ARTICLES = user-manual +SP_ARTICLES += user-manual SP_ARTICLES += howto/new-command SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree @@ -53,30 +69,45 @@ 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 = technical/index-format +TECH_DOCS += MyFirstContribution +TECH_DOCS += MyFirstObjectWalk +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/reftable 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 -DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES)) +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,$(MAN1_TXT)) -DOC_MAN5 = $(patsubst %.txt,%.5,$(MAN5_TXT)) -DOC_MAN7 = $(patsubst %.txt,%.7,$(MAN7_TXT)) +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 @@ -91,6 +122,14 @@ man7dir = $(mandir)/man7 ASCIIDOC = asciidoc ASCIIDOC_EXTRA = +ASCIIDOC_HTML = xhtml11 +ASCIIDOC_DOCBOOK = docbook +ASCIIDOC_CONF = -f asciidoc.conf +ASCIIDOC_COMMON = $(ASCIIDOC) $(ASCIIDOC_EXTRA) $(ASCIIDOC_CONF) \ + -amanversion=$(GIT_VERSION) \ + -amanmanual='Git Manual' -amansource='Git' +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 = @@ -104,6 +143,7 @@ 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 @@ -111,32 +151,9 @@ 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 -ifdef MAN_BOLD_LITERAL +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 @@ -157,6 +174,19 @@ ifdef GNU_ROFF XMLTO_EXTRA += -m manpage-quote-apos.xsl endif +ifdef USE_ASCIIDOCTOR +ASCIIDOC = asciidoctor +ASCIIDOC_CONF = +ASCIIDOC_HTML = xhtml5 +ASCIIDOC_DOCBOOK = docbook5 +ASCIIDOC_EXTRA += -acompat-mode -atabsize=8 +ASCIIDOC_EXTRA += -I. -rasciidoctor-extensions +ASCIIDOC_EXTRA += -alitdd='&\#x2d;&\#x2d;' +DBLATEX_COMMON = +XMLTO_EXTRA += --skip-validation +XMLTO_EXTRA += -x manpage.xsl +endif + SHELL_PATH ?= $(SHELL) # Shell quote; SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) @@ -189,6 +219,7 @@ ifndef V 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; \ @@ -249,7 +280,7 @@ docdep_prereqs = \ mergetools-list.made $(mergetools_txt) \ cmd-list.made $(cmds_txt) -doc.dep : $(docdep_prereqs) $(wildcard *.txt) build-docdep.perl +doc.dep : $(docdep_prereqs) $(wildcard *.txt) $(wildcard config/*.txt) build-docdep.perl $(QUIET_GEN)$(RM) $@+ $@ && \ $(PERL_PATH) ./build-docdep.perl >$@+ $(QUIET_STDERR) && \ mv $@+ $@ @@ -287,43 +318,51 @@ mergetools-list.made: ../git-mergetool--lib.sh $(wildcard ../mergetools/*) 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 +$(MAN_HTML): %.html : %.txt asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + $(TXT_TO_HTML) -d manpage -o $@+ $< && \ mv $@+ $@ -$(OBSOLETE_HTML): %.html : %.txto asciidoc.conf +$(OBSOLETE_HTML): %.html : %.txto asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + $(TXT_TO_HTML) -o $@+ $< && \ mv $@+ $@ manpage-base-url.xsl: manpage-base-url.xsl.in - sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@ + $(QUIET_GEN)sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@ -%.1 %.5 %.7 : %.xml manpage-base-url.xsl +%.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 +%.xml : %.txt asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + $(TXT_TO_XML) -d manpage -o $@+ $< && \ mv $@+ $@ -user-manual.xml: user-manual.txt user-manual.conf +user-manual.xml: user-manual.txt user-manual.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b docbook -d book -o $@+ $< && \ + $(TXT_TO_XML) -d book -o $@+ $< && \ mv $@+ $@ technical/api-index.txt: technical/api-index-skel.txt \ @@ -331,9 +370,12 @@ technical/api-index.txt: technical/api-index-skel.txt \ $(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 - $(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt +$(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 @@ -355,13 +397,14 @@ user-manual.texi: user-manual.xml user-manual.pdf: user-manual.xml $(QUIET_DBLATEX)$(RM) $@+ $@ && \ - $(DBLATEX) -o $@+ -p $(ASCIIDOC_DBLATEX_DIR)/asciidoc-dblatex.xsl -s $(ASCIIDOC_DBLATEX_DIR)/asciidoc-dblatex.sty $< && \ + $(DBLATEX) -o $@+ $(DBLATEX_COMMON) $< && \ mv $@+ $@ -gitman.texi: $(MAN_XML) cat-texi.perl +gitman.texi: $(MAN_XML) cat-texi.perl texi.xsl $(QUIET_DB2TEXI)$(RM) $@+ $@ && \ - ($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --encoding=UTF-8 \ - --to-stdout $(xml) &&) true) > $@++ && \ + ($(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 $@+ $@ @@ -380,14 +423,15 @@ howto-index.txt: howto-index.sh $(wildcard howto/*.txt) mv $@+ $@ $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt - $(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 $*.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 +$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt GIT-ASCIIDOCFLAGS $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - sed -e '1,/^$$/d' $< | $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 - >$@+ && \ + sed -e '1,/^$$/d' $< | \ + $(TXT_TO_HTML) - >$@+ && \ mv $@+ $@ install-webdoc : html @@ -403,16 +447,24 @@ require-manrepo:: 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) + '$(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) + '$(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/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt new file mode 100644 index 0000000000..d85c9b5143 --- /dev/null +++ b/Documentation/MyFirstContribution.txt @@ -0,0 +1,1217 @@ +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-help]] +=== Getting Help + +If you get stuck, you can seek help in the following places. + +==== git@vger.kernel.org + +This is the main Git project mailing list where code reviews, version +announcements, design discussions, and more take place. Those interested in +contributing are welcome to post questions here. The Git list requires +plain-text-only emails and prefers inline and bottom-posting when replying to +mail; you will be CC'd in all replies to you. Optionally, you can subscribe to +the list by sending an email to majordomo@vger.kernel.org with "subscribe git" +in the body. The https://lore.kernel.org/git[archive] of this mailing list is +available to view in a browser. + +==== https://groups.google.com/forum/#!forum/git-mentoring[git-mentoring@googlegroups.com] + +This mailing list is targeted to new contributors and was created as a place to +post questions and receive answers outside of the public eye of the main list. +Veteran contributors who are especially interested in helping mentor newcomers +are present on the list. In order to avoid search indexers, group membership is +required to view messages; anyone can join and no approval is required. + +==== https://webchat.freenode.net/#git-devel[#git-devel] on Freenode + +This IRC channel is for conversations between Git contributors. If someone is +currently online and knows the answer to your question, you can receive help +in real time. Otherwise, you can read the +https://colabti.org/irclogger/irclogger_logs/git-devel[scrollback] to see +whether someone answered you. IRC does not allow offline private messaging, so +if you try to private message someone and then log out of IRC, they cannot +respond to you. It's better to ask your questions in the channel so that you +can be answered if you disconnect and so that others can learn from the +conversation. + +[[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 +---- + +[[dependencies]] +=== Installing Dependencies + +To build Git from source, you need to have a handful of dependencies installed +on your system. For a hint of what's needed, you can take a look at +`INSTALL`, paying close attention to the section about Git's dependencies on +external programs and libraries. That document mentions a way to "test-drive" +our freshly built Git without installing; that's the method we'll be using in +this tutorial. + +Make sure that your environment has everything you need by building your brand +new clone of Git from the above step: + +---- +$ make +---- + +NOTE: The Git build is parallelizable. `-j#` is not included above but you can +use it as you prefer, here and elsewhere. + +[[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_pull`, and add a new line for `psuh` immediately before it, +in order to keep the declarations alphabetically 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/pull.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. + +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 (immediately before `cmd_pull`). + +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-pull`, 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. + +Now that you have a usage hint, you can teach Git how to show it in the general +command list shown by `git help git` or `git help -a`, which is generated from +`command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh' +line above it in alphabetical order. Now, we can add some attributes about the +command which impacts where it shows up in the aforementioned help commands. The +top of `command-list.txt` shares some information about what each attribute +means; in those help pages, the commands are sorted according to these +attributes. `git psuh` is user-facing, or porcelain - so we will mark it as +"mainporcelain". For "mainporcelain" commands, the comments at the top of +`command-list.txt` indicate we can also optionally add an attribute from another +list; since `git psuh` shows some information about the user's workspace but +doesn't modify anything, let's mark it as "info". Make sure to keep your +attributes in the same style as the rest of `command-list.txt` using spaces to +align and delineate them: + +---- +git-prune-packed plumbingmanipulators +git-psuh mainporcelain info +git-pull mainporcelain remote +git-push mainporcelain remote +---- + +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. + +NOTE: You can typically find someone who can `/allow` you on GitGitGadget by +either examining recent pull requests where someone has been granted `/allow` +(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search: +is:pr is:open "/allow"]), in which case both the author and the person who +granted the `/allow` can now `/allow` you, or by inquiring on the +https://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode +linking your pull request and asking for someone to `/allow` you. + +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://lore.kernel.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: `seen`, `next`, `master`, and +`maint`. Your change will be placed into `seen` 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/Documentation/MyFirstObjectWalk.txt b/Documentation/MyFirstObjectWalk.txt new file mode 100644 index 0000000000..c3f2d1a831 --- /dev/null +++ b/Documentation/MyFirstObjectWalk.txt @@ -0,0 +1,902 @@ += My First Object Walk + +== What's an Object Walk? + +The object walk is a key concept in Git - this is the process that underpins +operations like object transfer and fsck. Beginning from a given commit, the +list of objects is found by walking parent relationships between commits (commit +X based on commit W) and containment relationships between objects (tree Y is +contained within commit X, and blob Z is located within tree Y, giving our +working tree for commit X something like `y/z.txt`). + +A related concept is the revision walk, which is focused on commit objects and +their parent relationships and does not delve into other object types. The +revision walk is used for operations like `git log`. + +=== Related Reading + +- `Documentation/user-manual.txt` under "Hacking Git" contains some coverage of + the revision walker in its various incarnations. +- `revision.h` +- https://eagain.net/articles/git-for-computer-scientists/[Git for Computer Scientists] + gives a good overview of the types of objects in Git and what your object + walk is really describing. + +== Setting Up + +Create a new branch from `master`. + +---- +git checkout -b revwalk origin/master +---- + +We'll put our fiddling into a new command. For fun, let's name it `git walken`. +Open up a new file `builtin/walken.c` and set up the command handler: + +---- +/* + * "git walken" + * + * Part of the "My First Object Walk" tutorial. + */ + +#include "builtin.h" + +int cmd_walken(int argc, const char **argv, const char *prefix) +{ + trace_printf(_("cmd_walken incoming...\n")); + return 0; +} +---- + +NOTE: `trace_printf()` differs from `printf()` in that it can be turned on or +off at runtime. For the purposes of this tutorial, we will write `walken` as +though it is intended for use as a "plumbing" command: that is, a command which +is used primarily in scripts, rather than interactively by humans (a "porcelain" +command). So we will send our debug output to `trace_printf()` instead. When +running, enable trace output by setting the environment variable `GIT_TRACE`. + +Add usage text and `-h` handling, like all subcommands should consistently do +(our test suite will notice and complain if you fail to do so). + +---- +int cmd_walken(int argc, const char **argv, const char *prefix) +{ + const char * const walken_usage[] = { + N_("git walken"), + NULL, + } + struct option options[] = { + OPT_END() + }; + + argc = parse_options(argc, argv, prefix, options, walken_usage, 0); + + ... +} +---- + +Also add the relevant line in `builtin.h` near `cmd_whatchanged()`: + +---- +int cmd_walken(int argc, const char **argv, const char *prefix); +---- + +Include the command in `git.c` in `commands[]` near the entry for `whatchanged`, +maintaining alphabetical ordering: + +---- +{ "walken", cmd_walken, RUN_SETUP }, +---- + +Add it to the `Makefile` near the line for `builtin/worktree.o`: + +---- +BUILTIN_OBJS += builtin/walken.o +---- + +Build and test out your command, without forgetting to ensure the `DEVELOPER` +flag is set, and with `GIT_TRACE` enabled so the debug output can be seen: + +---- +$ echo DEVELOPER=1 >>config.mak +$ make +$ GIT_TRACE=1 ./bin-wrappers/git walken +---- + +NOTE: For a more exhaustive overview of the new command process, take a look at +`Documentation/MyFirstContribution.txt`. + +NOTE: A reference implementation can be found at +https://github.com/nasamuffin/git/tree/revwalk. + +=== `struct rev_cmdline_info` + +The definition of `struct rev_cmdline_info` can be found in `revision.h`. + +This struct is contained within the `rev_info` struct and is used to reflect +parameters provided by the user over the CLI. + +`nr` represents the number of `rev_cmdline_entry` present in the array. + +`alloc` is used by the `ALLOC_GROW` macro. Check `cache.h` - this variable is +used to track the allocated size of the list. + +Per entry, we find: + +`item` is the object provided upon which to base the object walk. Items in Git +can be blobs, trees, commits, or tags. (See `Documentation/gittutorial-2.txt`.) + +`name` is the object ID (OID) of the object - a hex string you may be familiar +with from using Git to organize your source in the past. Check the tutorial +mentioned above towards the top for a discussion of where the OID can come +from. + +`whence` indicates some information about what to do with the parents of the +specified object. We'll explore this flag more later on; take a look at +`Documentation/revisions.txt` to get an idea of what could set the `whence` +value. + +`flags` are used to hint the beginning of the revision walk and are the first +block under the `#include`s in `revision.h`. The most likely ones to be set in +the `rev_cmdline_info` are `UNINTERESTING` and `BOTTOM`, but these same flags +can be used during the walk, as well. + +=== `struct rev_info` + +This one is quite a bit longer, and many fields are only used during the walk +by `revision.c` - not configuration options. Most of the configurable flags in +`struct rev_info` have a mirror in `Documentation/rev-list-options.txt`. It's a +good idea to take some time and read through that document. + +== Basic Commit Walk + +First, let's see if we can replicate the output of `git log --oneline`. We'll +refer back to the implementation frequently to discover norms when performing +an object walk of our own. + +To do so, we'll first find all the commits, in order, which preceded the current +commit. We'll extract the name and subject of the commit from each. + +Ideally, we will also be able to find out which ones are currently at the tip of +various branches. + +=== Setting Up + +Preparing for your object walk has some distinct stages. + +1. Perform default setup for this mode, and others which may be invoked. +2. Check configuration files for relevant settings. +3. Set up the `rev_info` struct. +4. Tweak the initialized `rev_info` to suit the current walk. +5. Prepare the `rev_info` for the walk. +6. Iterate over the objects, processing each one. + +==== Default Setups + +Before examining configuration files which may modify command behavior, set up +default state for switches or options your command may have. If your command +utilizes other Git components, ask them to set up their default states as well. +For instance, `git log` takes advantage of `grep` and `diff` functionality, so +its `init_log_defaults()` sets its own state (`decoration_style`) and asks +`grep` and `diff` to initialize themselves by calling each of their +initialization functions. + +For our first example within `git walken`, we don't intend to use any other +components within Git, and we don't have any configuration to do. However, we +may want to add some later, so for now, we can add an empty placeholder. Create +a new function in `builtin/walken.c`: + +---- +static void init_walken_defaults(void) +{ + /* + * We don't actually need the same components `git log` does; leave this + * empty for now. + */ +} +---- + +Make sure to add a line invoking it inside of `cmd_walken()`. + +---- +int cmd_walken(int argc, const char **argv, const char *prefix) +{ + init_walken_defaults(); +} +---- + +==== Configuring From `.gitconfig` + +Next, we should have a look at any relevant configuration settings (i.e., +settings readable and settable from `git config`). This is done by providing a +callback to `git_config()`; within that callback, you can also invoke methods +from other components you may need that need to intercept these options. Your +callback will be invoked once per each configuration value which Git knows about +(global, local, worktree, etc.). + +Similarly to the default values, we don't have anything to do here yet +ourselves; however, we should call `git_default_config()` if we aren't calling +any other existing config callbacks. + +Add a new function to `builtin/walken.c`: + +---- +static int git_walken_config(const char *var, const char *value, void *cb) +{ + /* + * For now, we don't have any custom configuration, so fall back to + * the default config. + */ + return git_default_config(var, value, cb); +} +---- + +Make sure to invoke `git_config()` with it in your `cmd_walken()`: + +---- +int cmd_walken(int argc, const char **argv, const char *prefix) +{ + ... + + git_config(git_walken_config, NULL); + + ... +} +---- + +==== Setting Up `rev_info` + +Now that we've gathered external configuration and options, it's time to +initialize the `rev_info` object which we will use to perform the walk. This is +typically done by calling `repo_init_revisions()` with the repository you intend +to target, as well as the `prefix` argument of `cmd_walken` and your `rev_info` +struct. + +Add the `struct rev_info` and the `repo_init_revisions()` call: +---- +int cmd_walken(int argc, const char **argv, const char *prefix) +{ + /* This can go wherever you like in your declarations.*/ + struct rev_info rev; + ... + + /* This should go after the git_config() call. */ + repo_init_revisions(the_repository, &rev, prefix); + + ... +} +---- + +==== Tweaking `rev_info` For the Walk + +We're getting close, but we're still not quite ready to go. Now that `rev` is +initialized, we can modify it to fit our needs. This is usually done within a +helper for clarity, so let's add one: + +---- +static void final_rev_info_setup(struct rev_info *rev) +{ + /* + * We want to mimic the appearance of `git log --oneline`, so let's + * force oneline format. + */ + get_commit_format("oneline", rev); + + /* Start our object walk at HEAD. */ + add_head_to_pending(rev); +} +---- + +[NOTE] +==== +Instead of using the shorthand `add_head_to_pending()`, you could do +something like this: +---- + struct setup_revision_opt opt; + + memset(&opt, 0, sizeof(opt)); + opt.def = "HEAD"; + opt.revarg_opt = REVARG_COMMITTISH; + setup_revisions(argc, argv, rev, &opt); +---- +Using a `setup_revision_opt` gives you finer control over your walk's starting +point. +==== + +Then let's invoke `final_rev_info_setup()` after the call to +`repo_init_revisions()`: + +---- +int cmd_walken(int argc, const char **argv, const char *prefix) +{ + ... + + final_rev_info_setup(&rev); + + ... +} +---- + +Later, we may wish to add more arguments to `final_rev_info_setup()`. But for +now, this is all we need. + +==== Preparing `rev_info` For the Walk + +Now that `rev` is all initialized and configured, we've got one more setup step +before we get rolling. We can do this in a helper, which will both prepare the +`rev_info` for the walk, and perform the walk itself. Let's start the helper +with the call to `prepare_revision_walk()`, which can return an error without +dying on its own: + +---- +static void walken_commit_walk(struct rev_info *rev) +{ + if (prepare_revision_walk(rev)) + die(_("revision walk setup failed")); +} +---- + +NOTE: `die()` prints to `stderr` and exits the program. Since it will print to +`stderr` it's likely to be seen by a human, so we will localize it. + +==== Performing the Walk! + +Finally! We are ready to begin the walk itself. Now we can see that `rev_info` +can also be used as an iterator; we move to the next item in the walk by using +`get_revision()` repeatedly. Add the listed variable declarations at the top and +the walk loop below the `prepare_revision_walk()` call within your +`walken_commit_walk()`: + +---- +static void walken_commit_walk(struct rev_info *rev) +{ + struct commit *commit; + struct strbuf prettybuf = STRBUF_INIT; + + ... + + while ((commit = get_revision(rev))) { + strbuf_reset(&prettybuf); + pp_commit_easy(CMIT_FMT_ONELINE, commit, &prettybuf); + puts(prettybuf.buf); + } + strbuf_release(&prettybuf); +} +---- + +NOTE: `puts()` prints a `char*` to `stdout`. Since this is the part of the +command we expect to be machine-parsed, we're sending it directly to stdout. + +Give it a shot. + +---- +$ make +$ ./bin-wrappers/git walken +---- + +You should see all of the subject lines of all the commits in +your tree's history, in order, ending with the initial commit, "Initial revision +of "git", the information manager from hell". Congratulations! You've written +your first revision walk. You can play with printing some additional fields +from each commit if you're curious; have a look at the functions available in +`commit.h`. + +=== Adding a Filter + +Next, let's try to filter the commits we see based on their author. This is +equivalent to running `git log --author=<pattern>`. We can add a filter by +modifying `rev_info.grep_filter`, which is a `struct grep_opt`. + +First some setup. Add `init_grep_defaults()` to `init_walken_defaults()` and add +`grep_config()` to `git_walken_config()`: + +---- +static void init_walken_defaults(void) +{ + init_grep_defaults(the_repository); +} + +... + +static int git_walken_config(const char *var, const char *value, void *cb) +{ + grep_config(var, value, cb); + return git_default_config(var, value, cb); +} +---- + +Next, we can modify the `grep_filter`. This is done with convenience functions +found in `grep.h`. For fun, we're filtering to only commits from folks using a +`gmail.com` email address - a not-very-precise guess at who may be working on +Git as a hobby. Since we're checking the author, which is a specific line in the +header, we'll use the `append_header_grep_pattern()` helper. We can use +the `enum grep_header_field` to indicate which part of the commit header we want +to search. + +In `final_rev_info_setup()`, add your filter line: + +---- +static void final_rev_info_setup(int argc, const char **argv, + const char *prefix, struct rev_info *rev) +{ + ... + + append_header_grep_pattern(&rev->grep_filter, GREP_HEADER_AUTHOR, + "gmail"); + compile_grep_patterns(&rev->grep_filter); + + ... +} +---- + +`append_header_grep_pattern()` adds your new "gmail" pattern to `rev_info`, but +it won't work unless we compile it with `compile_grep_patterns()`. + +NOTE: If you are using `setup_revisions()` (for example, if you are passing a +`setup_revision_opt` instead of using `add_head_to_pending()`), you don't need +to call `compile_grep_patterns()` because `setup_revisions()` calls it for you. + +NOTE: We could add the same filter via the `append_grep_pattern()` helper if we +wanted to, but `append_header_grep_pattern()` adds the `enum grep_context` and +`enum grep_pat_token` for us. + +=== Changing the Order + +There are a few ways that we can change the order of the commits during a +revision walk. Firstly, we can use the `enum rev_sort_order` to choose from some +typical orderings. + +`topo_order` is the same as `git log --topo-order`: we avoid showing a parent +before all of its children have been shown, and we avoid mixing commits which +are in different lines of history. (`git help log`'s section on `--topo-order` +has a very nice diagram to illustrate this.) + +Let's see what happens when we run with `REV_SORT_BY_COMMIT_DATE` as opposed to +`REV_SORT_BY_AUTHOR_DATE`. Add the following: + +---- +static void final_rev_info_setup(int argc, const char **argv, + const char *prefix, struct rev_info *rev) +{ + ... + + rev->topo_order = 1; + rev->sort_order = REV_SORT_BY_COMMIT_DATE; + + ... +} +---- + +Let's output this into a file so we can easily diff it with the walk sorted by +author date. + +---- +$ make +$ ./bin-wrappers/git walken > commit-date.txt +---- + +Then, let's sort by author date and run it again. + +---- +static void final_rev_info_setup(int argc, const char **argv, + const char *prefix, struct rev_info *rev) +{ + ... + + rev->topo_order = 1; + rev->sort_order = REV_SORT_BY_AUTHOR_DATE; + + ... +} +---- + +---- +$ make +$ ./bin-wrappers/git walken > author-date.txt +---- + +Finally, compare the two. This is a little less helpful without object names or +dates, but hopefully we get the idea. + +---- +$ diff -u commit-date.txt author-date.txt +---- + +This display indicates that commits can be reordered after they're written, for +example with `git rebase`. + +Let's try one more reordering of commits. `rev_info` exposes a `reverse` flag. +Set that flag somewhere inside of `final_rev_info_setup()`: + +---- +static void final_rev_info_setup(int argc, const char **argv, const char *prefix, + struct rev_info *rev) +{ + ... + + rev->reverse = 1; + + ... +} +---- + +Run your walk again and note the difference in order. (If you remove the grep +pattern, you should see the last commit this call gives you as your current +HEAD.) + +== Basic Object Walk + +So far we've been walking only commits. But Git has more types of objects than +that! Let's see if we can walk _all_ objects, and find out some information +about each one. + +We can base our work on an example. `git pack-objects` prepares all kinds of +objects for packing into a bitmap or packfile. The work we are interested in +resides in `builtins/pack-objects.c:get_object_list()`; examination of that +function shows that the all-object walk is being performed by +`traverse_commit_list()` or `traverse_commit_list_filtered()`. Those two +functions reside in `list-objects.c`; examining the source shows that, despite +the name, these functions traverse all kinds of objects. Let's have a look at +the arguments to `traverse_commit_list_filtered()`, which are a superset of the +arguments to the unfiltered version. + +- `struct list_objects_filter_options *filter_options`: This is a struct which + stores a filter-spec as outlined in `Documentation/rev-list-options.txt`. +- `struct rev_info *revs`: This is the `rev_info` used for the walk. +- `show_commit_fn show_commit`: A callback which will be used to handle each + individual commit object. +- `show_object_fn show_object`: A callback which will be used to handle each + non-commit object (so each blob, tree, or tag). +- `void *show_data`: A context buffer which is passed in turn to `show_commit` + and `show_object`. +- `struct oidset *omitted`: A linked-list of object IDs which the provided + filter caused to be omitted. + +It looks like this `traverse_commit_list_filtered()` uses callbacks we provide +instead of needing us to call it repeatedly ourselves. Cool! Let's add the +callbacks first. + +For the sake of this tutorial, we'll simply keep track of how many of each kind +of object we find. At file scope in `builtin/walken.c` add the following +tracking variables: + +---- +static int commit_count; +static int tag_count; +static int blob_count; +static int tree_count; +---- + +Commits are handled by a different callback than other objects; let's do that +one first: + +---- +static void walken_show_commit(struct commit *cmt, void *buf) +{ + commit_count++; +} +---- + +The `cmt` argument is fairly self-explanatory. But it's worth mentioning that +the `buf` argument is actually the context buffer that we can provide to the +traversal calls - `show_data`, which we mentioned a moment ago. + +Since we have the `struct commit` object, we can look at all the same parts that +we looked at in our earlier commit-only walk. For the sake of this tutorial, +though, we'll just increment the commit counter and move on. + +The callback for non-commits is a little different, as we'll need to check +which kind of object we're dealing with: + +---- +static void walken_show_object(struct object *obj, const char *str, void *buf) +{ + switch (obj->type) { + case OBJ_TREE: + tree_count++; + break; + case OBJ_BLOB: + blob_count++; + break; + case OBJ_TAG: + tag_count++; + break; + case OBJ_COMMIT: + BUG("unexpected commit object in walken_show_object\n"); + default: + BUG("unexpected object type %s in walken_show_object\n", + type_name(obj->type)); + } +} +---- + +Again, `obj` is fairly self-explanatory, and we can guess that `buf` is the same +context pointer that `walken_show_commit()` receives: the `show_data` argument +to `traverse_commit_list()` and `traverse_commit_list_filtered()`. Finally, +`str` contains the name of the object, which ends up being something like +`foo.txt` (blob), `bar/baz` (tree), or `v1.2.3` (tag). + +To help assure us that we aren't double-counting commits, we'll include some +complaining if a commit object is routed through our non-commit callback; we'll +also complain if we see an invalid object type. Since those two cases should be +unreachable, and would only change in the event of a semantic change to the Git +codebase, we complain by using `BUG()` - which is a signal to a developer that +the change they made caused unintended consequences, and the rest of the +codebase needs to be updated to understand that change. `BUG()` is not intended +to be seen by the public, so it is not localized. + +Our main object walk implementation is substantially different from our commit +walk implementation, so let's make a new function to perform the object walk. We +can perform setup which is applicable to all objects here, too, to keep separate +from setup which is applicable to commit-only walks. + +We'll start by enabling all types of objects in the `struct rev_info`. We'll +also turn on `tree_blobs_in_commit_order`, which means that we will walk a +commit's tree and everything it points to immediately after we find each commit, +as opposed to waiting for the end and walking through all trees after the commit +history has been discovered. With the appropriate settings configured, we are +ready to call `prepare_revision_walk()`. + +---- +static void walken_object_walk(struct rev_info *rev) +{ + rev->tree_objects = 1; + rev->blob_objects = 1; + rev->tag_objects = 1; + rev->tree_blobs_in_commit_order = 1; + + if (prepare_revision_walk(rev)) + die(_("revision walk setup failed")); + + commit_count = 0; + tag_count = 0; + blob_count = 0; + tree_count = 0; +---- + +Let's start by calling just the unfiltered walk and reporting our counts. +Complete your implementation of `walken_object_walk()`: + +---- + traverse_commit_list(rev, walken_show_commit, walken_show_object, NULL); + + printf("commits %d\nblobs %d\ntags %d\ntrees %d\n", commit_count, + blob_count, tag_count, tree_count); +} +---- + +NOTE: This output is intended to be machine-parsed. Therefore, we are not +sending it to `trace_printf()`, and we are not localizing it - we need scripts +to be able to count on the formatting to be exactly the way it is shown here. +If we were intending this output to be read by humans, we would need to localize +it with `_()`. + +Finally, we'll ask `cmd_walken()` to use the object walk instead. Discussing +command line options is out of scope for this tutorial, so we'll just hardcode +a branch we can change at compile time. Where you call `final_rev_info_setup()` +and `walken_commit_walk()`, instead branch like so: + +---- + if (1) { + add_head_to_pending(&rev); + walken_object_walk(&rev); + } else { + final_rev_info_setup(argc, argv, prefix, &rev); + walken_commit_walk(&rev); + } +---- + +NOTE: For simplicity, we've avoided all the filters and sorts we applied in +`final_rev_info_setup()` and simply added `HEAD` to our pending queue. If you +want, you can certainly use the filters we added before by moving +`final_rev_info_setup()` out of the conditional and removing the call to +`add_head_to_pending()`. + +Now we can try to run our command! It should take noticeably longer than the +commit walk, but an examination of the output will give you an idea why. Your +output should look similar to this example, but with different counts: + +---- +Object walk completed. Found 55733 commits, 100274 blobs, 0 tags, and 104210 trees. +---- + +This makes sense. We have more trees than commits because the Git project has +lots of subdirectories which can change, plus at least one tree per commit. We +have no tags because we started on a commit (`HEAD`) and while tags can point to +commits, commits can't point to tags. + +NOTE: You will have different counts when you run this yourself! The number of +objects grows along with the Git project. + +=== Adding a Filter + +There are a handful of filters that we can apply to the object walk laid out in +`Documentation/rev-list-options.txt`. These filters are typically useful for +operations such as creating packfiles or performing a partial clone. They are +defined in `list-objects-filter-options.h`. For the purposes of this tutorial we +will use the "tree:1" filter, which causes the walk to omit all trees and blobs +which are not directly referenced by commits reachable from the commit in +`pending` when the walk begins. (`pending` is the list of objects which need to +be traversed during a walk; you can imagine a breadth-first tree traversal to +help understand. In our case, that means we omit trees and blobs not directly +referenced by `HEAD` or `HEAD`'s history, because we begin the walk with only +`HEAD` in the `pending` list.) + +First, we'll need to `#include "list-objects-filter-options.h`" and set up the +`struct list_objects_filter_options` at the top of the function. + +---- +static void walken_object_walk(struct rev_info *rev) +{ + struct list_objects_filter_options filter_options = {}; + + ... +---- + +For now, we are not going to track the omitted objects, so we'll replace those +parameters with `NULL`. For the sake of simplicity, we'll add a simple +build-time branch to use our filter or not. Replace the line calling +`traverse_commit_list()` with the following, which will remind us which kind of +walk we've just performed: + +---- + if (0) { + /* Unfiltered: */ + trace_printf(_("Unfiltered object walk.\n")); + traverse_commit_list(rev, walken_show_commit, + walken_show_object, NULL); + } else { + trace_printf( + _("Filtered object walk with filterspec 'tree:1'.\n")); + parse_list_objects_filter(&filter_options, "tree:1"); + + traverse_commit_list_filtered(&filter_options, rev, + walken_show_commit, walken_show_object, NULL, NULL); + } +---- + +`struct list_objects_filter_options` is usually built directly from a command +line argument, so the module provides an easy way to build one from a string. +Even though we aren't taking user input right now, we can still build one with +a hardcoded string using `parse_list_objects_filter()`. + +With the filter spec "tree:1", we are expecting to see _only_ the root tree for +each commit; therefore, the tree object count should be less than or equal to +the number of commits. (For an example of why that's true: `git commit --revert` +points to the same tree object as its grandparent.) + +=== Counting Omitted Objects + +We also have the capability to enumerate all objects which were omitted by a +filter, like with `git log --filter=<spec> --filter-print-omitted`. Asking +`traverse_commit_list_filtered()` to populate the `omitted` list means that our +object walk does not perform any better than an unfiltered object walk; all +reachable objects are walked in order to populate the list. + +First, add the `struct oidset` and related items we will use to iterate it: + +---- +static void walken_object_walk( + ... + + struct oidset omitted; + struct oidset_iter oit; + struct object_id *oid = NULL; + int omitted_count = 0; + oidset_init(&omitted, 0); + + ... +---- + +Modify the call to `traverse_commit_list_filtered()` to include your `omitted` +object: + +---- + ... + + traverse_commit_list_filtered(&filter_options, rev, + walken_show_commit, walken_show_object, NULL, &omitted); + + ... +---- + +Then, after your traversal, the `oidset` traversal is pretty straightforward. +Count all the objects within and modify the print statement: + +---- + /* Count the omitted objects. */ + oidset_iter_init(&omitted, &oit); + + while ((oid = oidset_iter_next(&oit))) + omitted_count++; + + printf("commits %d\nblobs %d\ntags %d\ntrees%d\nomitted %d\n", + commit_count, blob_count, tag_count, tree_count, omitted_count); +---- + +By running your walk with and without the filter, you should find that the total +object count in each case is identical. You can also time each invocation of +the `walken` subcommand, with and without `omitted` being passed in, to confirm +to yourself the runtime impact of tracking all omitted objects. + +=== Changing the Order + +Finally, let's demonstrate that you can also reorder walks of all objects, not +just walks of commits. First, we'll make our handlers chattier - modify +`walken_show_commit()` and `walken_show_object()` to print the object as they +go: + +---- +static void walken_show_commit(struct commit *cmt, void *buf) +{ + trace_printf("commit: %s\n", oid_to_hex(&cmt->object.oid)); + commit_count++; +} + +static void walken_show_object(struct object *obj, const char *str, void *buf) +{ + trace_printf("%s: %s\n", type_name(obj->type), oid_to_hex(&obj->oid)); + + ... +} +---- + +NOTE: Since we will be examining this output directly as humans, we'll use +`trace_printf()` here. Additionally, since this change introduces a significant +number of printed lines, using `trace_printf()` will allow us to easily silence +those lines without having to recompile. + +(Leave the counter increment logic in place.) + +With only that change, run again (but save yourself some scrollback): + +---- +$ GIT_TRACE=1 ./bin-wrappers/git walken | head -n 10 +---- + +Take a look at the top commit with `git show` and the object ID you printed; it +should be the same as the output of `git show HEAD`. + +Next, let's change a setting on our `struct rev_info` within +`walken_object_walk()`. Find where you're changing the other settings on `rev`, +such as `rev->tree_objects` and `rev->tree_blobs_in_commit_order`, and add the +`reverse` setting at the bottom: + +---- + ... + + rev->tree_objects = 1; + rev->blob_objects = 1; + rev->tag_objects = 1; + rev->tree_blobs_in_commit_order = 1; + rev->reverse = 1; + + ... +---- + +Now, run again, but this time, let's grab the last handful of objects instead +of the first handful: + +---- +$ make +$ GIT_TRACE=1 ./bin-wrappers git walken | tail -n 10 +---- + +The last commit object given should have the same OID as the one we saw at the +top before, and running `git show <oid>` with that OID should give you again +the same results as `git show HEAD`. Furthermore, if you run and examine the +first ten lines again (with `head` instead of `tail` like we did before applying +the `reverse` setting), you should see that now the first commit printed is the +initial commit, `e83c5163`. + +== Wrapping Up + +Let's review. In this tutorial, we: + +- Built a commit walk from the ground up +- Enabled a grep filter for that commit walk +- Changed the sort order of that filtered commit walk +- Built an object walk (tags, commits, trees, and blobs) from the ground up +- Learned how to add a filter-spec to an object walk +- Changed the display order of the filtered object walk diff --git a/Documentation/RelNotes/1.5.0.txt b/Documentation/RelNotes/1.5.0.txt index daf4bdb0d7..d6d42f3183 100644 --- a/Documentation/RelNotes/1.5.0.txt +++ b/Documentation/RelNotes/1.5.0.txt @@ -251,7 +251,7 @@ Updates in v1.5.0 since v1.4.4 series the repository when that happens. -* Crufts removal +* Cruft removal - We used to say "old commits are retrievable using reflog and 'master@{yesterday}' syntax as long as you haven't run @@ -379,7 +379,7 @@ Updates in v1.5.0 since v1.4.4 series - 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 + and re-encodes 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 diff --git a/Documentation/RelNotes/1.6.2.txt b/Documentation/RelNotes/1.6.2.txt index ad060f4f89..980adfb315 100644 --- a/Documentation/RelNotes/1.6.2.txt +++ b/Documentation/RelNotes/1.6.2.txt @@ -11,7 +11,7 @@ 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 + https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan. diff --git a/Documentation/RelNotes/1.6.3.txt b/Documentation/RelNotes/1.6.3.txt index 418c685cf8..4bcff945e0 100644 --- a/Documentation/RelNotes/1.6.3.txt +++ b/Documentation/RelNotes/1.6.3.txt @@ -11,7 +11,7 @@ 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 + https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan. diff --git a/Documentation/RelNotes/1.6.4.txt b/Documentation/RelNotes/1.6.4.txt index 7a904419f7..a2a34b43a7 100644 --- a/Documentation/RelNotes/1.6.4.txt +++ b/Documentation/RelNotes/1.6.4.txt @@ -11,7 +11,7 @@ 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 + https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan. diff --git a/Documentation/RelNotes/1.6.5.4.txt b/Documentation/RelNotes/1.6.5.4.txt index d3a2a3e712..344333de66 100644 --- a/Documentation/RelNotes/1.6.5.4.txt +++ b/Documentation/RelNotes/1.6.5.4.txt @@ -10,7 +10,7 @@ Fixes since v1.6.5.3 * "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. + produce cruft. * "git pack-objects --all-progress" is an option to ask progress output from write-object phase _if_ progress output were to be produced, and diff --git a/Documentation/RelNotes/1.6.5.txt b/Documentation/RelNotes/1.6.5.txt index ee141c19ad..6c7f7da7eb 100644 --- a/Documentation/RelNotes/1.6.5.txt +++ b/Documentation/RelNotes/1.6.5.txt @@ -22,7 +22,7 @@ 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 + https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan. diff --git a/Documentation/RelNotes/1.6.6.txt b/Documentation/RelNotes/1.6.6.txt index c50b59c495..3ed1e01433 100644 --- a/Documentation/RelNotes/1.6.6.txt +++ b/Documentation/RelNotes/1.6.6.txt @@ -64,7 +64,7 @@ users will fare this time. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare - http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 + https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition process that already took place so far. diff --git a/Documentation/RelNotes/1.7.0.2.txt b/Documentation/RelNotes/1.7.0.2.txt index fcb46ca6a4..73ed2b5278 100644 --- a/Documentation/RelNotes/1.7.0.2.txt +++ b/Documentation/RelNotes/1.7.0.2.txt @@ -34,7 +34,7 @@ Fixes since v1.7.0.1 * "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 + * "gitweb" did not diagnose parsing errors properly while reading its configuration file. And other minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.10.1.txt b/Documentation/RelNotes/1.7.10.1.txt index be68524cff..71a86cb7c6 100644 --- a/Documentation/RelNotes/1.7.10.1.txt +++ b/Documentation/RelNotes/1.7.10.1.txt @@ -69,7 +69,7 @@ Fixes since v1.7.10 * 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 unreleated to + $there using the upstream information to a remote unrelated to $there. * Giving "--continue" to a conflicted "rebase -i" session skipped a diff --git a/Documentation/RelNotes/1.7.10.4.txt b/Documentation/RelNotes/1.7.10.4.txt index 326670df6e..57597f2bf3 100644 --- a/Documentation/RelNotes/1.7.10.4.txt +++ b/Documentation/RelNotes/1.7.10.4.txt @@ -7,7 +7,7 @@ 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. + incorrectly and could overrun 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. diff --git a/Documentation/RelNotes/1.7.11.7.txt b/Documentation/RelNotes/1.7.11.7.txt index e7e79d999b..e743a2a8e4 100644 --- a/Documentation/RelNotes/1.7.11.7.txt +++ b/Documentation/RelNotes/1.7.11.7.txt @@ -25,7 +25,7 @@ Fixes since v1.7.11.6 references" nor "Reload" did not update what is shown as the contents of it, when the user overwrote the tag with "git tag -f". - * "git for-each-ref" did not currectly support more than one --sort + * "git for-each-ref" did not correctly support more than one --sort option. * "git log .." errored out saying it is both rev range and a path diff --git a/Documentation/RelNotes/1.7.12.3.txt b/Documentation/RelNotes/1.7.12.3.txt index ecda427a35..4b822976b8 100644 --- a/Documentation/RelNotes/1.7.12.3.txt +++ b/Documentation/RelNotes/1.7.12.3.txt @@ -25,7 +25,7 @@ Fixes since v1.7.12.2 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 + progress output while processing objects it received to the user when run over the smart-http protocol. * "git status" honored the ignore=dirty settings in .gitmodules but diff --git a/Documentation/RelNotes/1.7.5.3.txt b/Documentation/RelNotes/1.7.5.3.txt index 9c03353af2..1d24edcf2f 100644 --- a/Documentation/RelNotes/1.7.5.3.txt +++ b/Documentation/RelNotes/1.7.5.3.txt @@ -22,7 +22,7 @@ Fixes since v1.7.5.2 * "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 + * "git send-pack" (hence "git push") over smart-HTTP protocol could deadlock when the client side pack-object died early. * Compressed tarball gitweb generates used to be made with the timestamp diff --git a/Documentation/RelNotes/1.7.7.txt b/Documentation/RelNotes/1.7.7.txt index 7655cccfaa..6eff128c80 100644 --- a/Documentation/RelNotes/1.7.7.txt +++ b/Documentation/RelNotes/1.7.7.txt @@ -84,7 +84,7 @@ Updates since v1.7.6 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 + 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 diff --git a/Documentation/RelNotes/1.8.0.txt b/Documentation/RelNotes/1.8.0.txt index 43883c14f0..63d6e4afa4 100644 --- a/Documentation/RelNotes/1.8.0.txt +++ b/Documentation/RelNotes/1.8.0.txt @@ -233,7 +233,7 @@ to them for details). together, misdetected branches. * "git receive-pack" (the counterpart to "git push") did not give - progress output while processing objects it received to the puser + progress output while processing objects it received to the user when run over the smart-http protocol. * When you misspell the command name you give to the "exec" action in diff --git a/Documentation/RelNotes/1.8.3.1.txt b/Documentation/RelNotes/1.8.3.1.txt index fc3ea185a5..986637b755 100644 --- a/Documentation/RelNotes/1.8.3.1.txt +++ b/Documentation/RelNotes/1.8.3.1.txt @@ -1,5 +1,5 @@ Git v1.8.3.1 Release Notes -======================== +========================== Fixes since v1.8.3 ------------------ diff --git a/Documentation/RelNotes/1.8.4.1.txt b/Documentation/RelNotes/1.8.4.1.txt index 3aa25a2743..c257beb114 100644 --- a/Documentation/RelNotes/1.8.4.1.txt +++ b/Documentation/RelNotes/1.8.4.1.txt @@ -1,5 +1,5 @@ Git v1.8.4.1 Release Notes -======================== +========================== Fixes since v1.8.4 ------------------ @@ -15,7 +15,7 @@ Fixes since v1.8.4 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 + random, data dependent error message to 'echo' and expecting it to come out literally. * Setting the "submodule.<name>.path" variable to the empty diff --git a/Documentation/RelNotes/1.8.4.2.txt b/Documentation/RelNotes/1.8.4.2.txt index 867ae69070..bf6fb1a023 100644 --- a/Documentation/RelNotes/1.8.4.2.txt +++ b/Documentation/RelNotes/1.8.4.2.txt @@ -1,9 +1,23 @@ 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. diff --git a/Documentation/RelNotes/1.8.4.3.txt b/Documentation/RelNotes/1.8.4.3.txt new file mode 100644 index 0000000000..267a1b34b4 --- /dev/null +++ b/Documentation/RelNotes/1.8.4.3.txt @@ -0,0 +1,54 @@ +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/Documentation/RelNotes/1.8.4.4.txt b/Documentation/RelNotes/1.8.4.4.txt new file mode 100644 index 0000000000..a7c1ce15c0 --- /dev/null +++ b/Documentation/RelNotes/1.8.4.4.txt @@ -0,0 +1,10 @@ +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/Documentation/RelNotes/1.8.4.5.txt b/Documentation/RelNotes/1.8.4.5.txt new file mode 100644 index 0000000000..215bd1a7a2 --- /dev/null +++ b/Documentation/RelNotes/1.8.4.5.txt @@ -0,0 +1,13 @@ +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/Documentation/RelNotes/1.8.4.txt b/Documentation/RelNotes/1.8.4.txt index 02f681b710..255e185af6 100644 --- a/Documentation/RelNotes/1.8.4.txt +++ b/Documentation/RelNotes/1.8.4.txt @@ -58,7 +58,7 @@ Foreign interfaces, subsystems and ports. 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 + this is fine with Cygwin 1.7 (cf. <51A606A0.5060101@web.de>) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has diff --git a/Documentation/RelNotes/1.8.5.1.txt b/Documentation/RelNotes/1.8.5.1.txt new file mode 100644 index 0000000000..7236aaf232 --- /dev/null +++ b/Documentation/RelNotes/1.8.5.1.txt @@ -0,0 +1,9 @@ +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/Documentation/RelNotes/1.8.5.2.txt b/Documentation/RelNotes/1.8.5.2.txt new file mode 100644 index 0000000000..3ac4984f10 --- /dev/null +++ b/Documentation/RelNotes/1.8.5.2.txt @@ -0,0 +1,20 @@ +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/Documentation/RelNotes/1.8.5.3.txt b/Documentation/RelNotes/1.8.5.3.txt new file mode 100644 index 0000000000..3de2dd0f19 --- /dev/null +++ b/Documentation/RelNotes/1.8.5.3.txt @@ -0,0 +1,27 @@ +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/Documentation/RelNotes/1.8.5.4.txt b/Documentation/RelNotes/1.8.5.4.txt new file mode 100644 index 0000000000..d18c40389e --- /dev/null +++ b/Documentation/RelNotes/1.8.5.4.txt @@ -0,0 +1,48 @@ +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/Documentation/RelNotes/1.8.5.5.txt b/Documentation/RelNotes/1.8.5.5.txt new file mode 100644 index 0000000000..9191ce948f --- /dev/null +++ b/Documentation/RelNotes/1.8.5.5.txt @@ -0,0 +1,37 @@ +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/Documentation/RelNotes/1.8.5.6.txt b/Documentation/RelNotes/1.8.5.6.txt new file mode 100644 index 0000000000..92ff92b1e6 --- /dev/null +++ b/Documentation/RelNotes/1.8.5.6.txt @@ -0,0 +1,34 @@ +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/Documentation/RelNotes/1.8.5.txt b/Documentation/RelNotes/1.8.5.txt index 4c2aa7077b..602df0cac2 100644 --- a/Documentation/RelNotes/1.8.5.txt +++ b/Documentation/RelNotes/1.8.5.txt @@ -8,7 +8,7 @@ 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: +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 @@ -53,9 +53,12 @@ Updates since v1.8.4 Foreign interfaces, subsystems and ports. - * "git-svn" used with SVN 1.8.0 when talking over https:// connection + * "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 - it around on our side, even though the SVN side is being fixed. + 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. @@ -65,10 +68,7 @@ Foreign interfaces, subsystems and ports. 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 one. - - * Subversion 1.8.0 that was recently released breaks older subversion - clients coming over http/https in various ways. + OpenSSL's. * "git fast-import" treats an empty path given to "ls" as the root of the tree. @@ -76,22 +76,25 @@ Foreign interfaces, subsystems and ports. UI, Workflows & Features - * "git grep" and "git show" pays attention to "--textconv" option + * 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 HEAD:Makefile"). + 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 replacement using "git update-ref", as an + still manually craft such a replacement using "git update-ref", as an escape hatch). - * "git status" no longer prints dirty status information for + * "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 what original commit is + * "git status" during a cherry-pick shows which original commit is being picked. * Instead of typing four capital letters "HEAD", you can say "@" now, @@ -99,21 +102,21 @@ UI, Workflows & Features * "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 "--no-index" option, it + 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" learnt a "--stdin" option to read multiple update + * "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" + * 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. @@ -123,59 +126,58 @@ UI, Workflows & Features "git status --porcelain" instead, as its format is stable and easier to parse. - * Make "foo^{tag}" to peel a tag to itself, i.e. no-op., and fail if - "foo" is not a tag. "git rev-parse --verify v1.0^{tag}" would be - a more convenient way to say "test $(git cat-file -t v1.0) = tag". + * 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 does not build on any other branch, a branch that is in - sync with the branch it builds on, and a branch that is configured - to build on some other branch that no longer exists. + 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. - * A packfile that stores the same object more than once is broken and - will be rejected by "git index-pack" that is run when receiving - data over the wire. - - * Earlier we started rejecting an attempt to add 0{40} object name to + * 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 so to be able to use tools like filter-branch to correct such - broken tree objects. "filter-branch" can again be used to to do - so. + 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" by + 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" that matches both - Makefile and makefile can be used in more places. + * 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 per URL that the - configuration applies. For example, + * 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 specified + would flip http.sslVerify off only when talking to that specific site. - * "git mv A B" when moving a submodule A has been taught to - relocate its working tree and to adjust the paths in the + * "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 the lines. + origin of multiple blocks of lines. * The http transport clients can optionally ask to save cookies - with http.savecookies configuration variable. + 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 @@ -197,7 +199,7 @@ UI, Workflows & Features * "git whatchanged" may still be used by old timers, but mention of it in documents meant for new users will only waste readers' time - wonderig what the difference is between it and "git log". Make it + 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. @@ -205,6 +207,12 @@ UI, Workflows & Features 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. @@ -213,23 +221,23 @@ Performance, Internal Implementation, etc. should apply the same "no subprocess or pipe" optimization as we apply to user-supplied GIT_PAGER=cat. - * Many commands use --dashed-option as a operation mode selector - (e.g. "git tag --delete") that the user can use at most one - (e.g. "git tag --delete --verify" is a nonsense) and you cannot - negate (e.g. "git tag --no-delete" is a nonsense). parse-options + * 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 parse-options API was misdesigned to be "counting + * 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 a double-work when it detects + * "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 filehandle to - an open but unused packfiles. These are now controlled separately + 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. @@ -239,20 +247,82 @@ 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 release notes to them for +track are contained in this release (see the maintenance releases' notes for details). - * "git clone" gave some progress messages to the standard output, not - to the standard error, and did not allow suppressing them with the + * 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 unnecessary in-body + * "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 ignore such a commit + 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). @@ -266,16 +336,16 @@ details). 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 to trigger a + * "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 from. + local branch of the upstream repository you are tracking. (merge b0f49ff jh/checkout-auto-tracking later to maint). - * When the webserver responds with "405 Method Not Allowed", "git + * 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). @@ -289,22 +359,22 @@ details). executable files. (merge 1b48d56 jc/cvsserver-perm-bit-fix later to maint). - * When send-email comes up with an error message to die with upon + * 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 a crippling code to work around + * 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 the user-supplied GIT_DIR is actually a + * 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 then + * 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(). @@ -322,22 +392,22 @@ details). made it unnecessarily inefficient. (merge 680be04 jc/ls-files-killed-optim later to maint). - * The commit object names in the insn sheet that was prepared at the - beginning of "rebase -i" session can become ambiguous as the + * 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 merge summary message in the log, but - when rebasing, there should not be a need for merge summary. + 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 to cope with short - read in the codepath to stream new contents to a pack. + * 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 can be + * "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). @@ -348,8 +418,8 @@ details). * 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 take more than 2GB read or - write in one go. + 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 @@ -363,17 +433,17 @@ details). had a similar problem. (merge 838f9a1 tr/log-full-diff-keep-true-parents later to maint). - * Setting submodule.*.path configuration variable to true (without + * 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 dependeant string to 'echo' and - expects it to come out literally, corrupting its error message. + 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' the prompt and + 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). diff --git a/Documentation/RelNotes/1.9.0.txt b/Documentation/RelNotes/1.9.0.txt new file mode 100644 index 0000000000..4e4b88aa5c --- /dev/null +++ b/Documentation/RelNotes/1.9.0.txt @@ -0,0 +1,345 @@ +Git v1.9.0 Release Notes +======================== + +Backward compatibility notes +---------------------------- + +"git submodule foreach $cmd $args" used to treat "$cmd $args" the same +way "ssh" did, concatenating them into a single string and letting the +shell unquote. Careless users who forget to sufficiently quote $args +get their argument split at $IFS whitespaces by the shell, and got +unexpected results due to this. Starting from this release, the +command line is passed directly to the shell, if it has an argument. + +Read-only support for experimental loose-object format, in which users +could optionally choose to write their loose objects for a short +while between v1.4.3 and v1.5.3 era, has been dropped. + +The meanings of the "--tags" option to "git fetch" has changed; the +command fetches tags _in addition to_ what is fetched by the same +command line without the option. + +The way "git push $there $what" interprets the $what part given on the +command line, when it does not have a colon that explicitly tells us +what ref at the $there repository is to be updated, has been enhanced. + +A handful of ancient commands that have long been deprecated are +finally gone (repo-config, tar-tree, lost-found, and peek-remote). + + +Backward compatibility notes (for Git 2.0.0) +-------------------------------------------- + +When "git push [$there]" does not say what to push, we have used the +traditional "matching" semantics so far (all your branches were sent +to the remote as long as there already are branches of the same name +over there). In Git 2.0, the default will change to the "simple" +semantics, which pushes: + + - only the current branch to the branch with the same name, and only + when the current branch is set to integrate with that remote + branch, if you are pushing to the same remote as you fetch from; or + + - only the current branch to the branch with the same name, if you + are pushing to a remote that is not where you usually fetch from. + +Use the user preference configuration variable "push.default" to +change this. If you are an old-timer who is used to the "matching" +semantics, you can set the variable to "matching" to keep the +traditional behaviour. If you want to live in the future early, you +can set it to "simple" today without waiting for Git 2.0. + +When "git add -u" (and "git add -A") is run inside a subdirectory and +does not specify which paths to add on the command line, it +will operate on the entire tree in Git 2.0 for consistency +with "git commit -a" and other commands. There will be no +mechanism to make plain "git add -u" behave like "git add -u .". +Current users of "git add -u" (without a pathspec) should start +training their fingers to explicitly say "git add -u ." +before Git 2.0 comes. A warning is issued when these commands are +run without a pathspec and when you have local changes outside the +current directory, because the behaviour in Git 2.0 will be different +from today's version in such a situation. + +In Git 2.0, "git add <path>" will behave as "git add -A <path>", so +that "git add dir/" will notice paths you removed from the directory +and record the removal. Versions before Git 2.0, including this +release, will keep ignoring removals, but the users who rely on this +behaviour are encouraged to start using "git add --ignore-removal <path>" +now before 2.0 is released. + +The default prefix for "git svn" will change in Git 2.0. For a long +time, "git svn" created its remote-tracking branches directly under +refs/remotes, but it will place them under refs/remotes/origin/ unless +it is told otherwise with its --prefix option. + + +Updates since v1.8.5 +-------------------- + +Foreign interfaces, subsystems and ports. + + * The HTTP transport, when talking GSS-Negotiate, uses "100 + Continue" response to avoid having to rewind and resend a large + payload, which may not be always doable. + + * Various bugfixes to remote-bzr and remote-hg (in contrib/). + + * The build procedure is aware of MirBSD now. + + * Various "git p4", "git svn" and "gitk" updates. + + +UI, Workflows & Features + + * Fetching from a shallowly-cloned repository used to be forbidden, + primarily because the codepaths involved were not carefully vetted + and we did not bother supporting such usage. This release attempts + to allow object transfer out of a shallowly-cloned repository in a + more controlled way (i.e. the receiver becomes a shallow repository + with a truncated history). + + * Just like we give a reasonable default for "less" via the LESS + environment variable, we now specify a reasonable default for "lv" + via the "LV" environment variable when spawning the pager. + + * Two-level configuration variable names in "branch.*" and "remote.*" + hierarchies, whose variables are predominantly three-level, were + not completed by hitting a <TAB> in bash and zsh completions. + + * Fetching a 'frotz' branch with "git fetch", while a 'frotz/nitfol' + remote-tracking branch from an earlier fetch was still there, would + error out, primarily because the command was not told that it is + allowed to lose any information on our side. "git fetch --prune" + now can be used to remove 'frotz/nitfol' to make room for fetching and + storing the 'frotz' remote-tracking branch. + + * "diff.orderfile=<file>" configuration variable can be used to + pretend as if the "-O<file>" option were given from the command + line of "git diff", etc. + + * The negative pathspec syntax allows "git log -- . ':!dir'" to tell + us "I am interested in everything but 'dir' directory". + + * "git difftool" shows how many different paths there are in total, + and how many of them have been shown so far, to indicate progress. + + * "git push origin master" used to push our 'master' branch to update + the 'master' branch at the 'origin' repository. This has been + enhanced to use the same ref mapping "git push origin" would use to + determine what ref at the 'origin' to be updated with our 'master'. + For example, with this configuration + + [remote "origin"] + push = refs/heads/*:refs/review/* + + that would cause "git push origin" to push out our local branches + to corresponding refs under refs/review/ hierarchy at 'origin', + "git push origin master" would update 'refs/review/master' over + there. Alternatively, if push.default is set to 'upstream' and our + 'master' is set to integrate with 'topic' from the 'origin' branch, + running "git push origin" while on our 'master' would update their + 'topic' branch, and running "git push origin master" while on any + of our branches does the same. + + * "gitweb" learned to treat ref hierarchies other than refs/heads as + if they are additional branch namespaces (e.g. refs/changes/ in + Gerrit). + + * "git for-each-ref --format=..." learned a few formatting directives; + e.g. "%(color:red)%(HEAD)%(color:reset) %(refname:short) %(subject)". + + * The command string given to "git submodule foreach" is passed + directly to the shell, without being eval'ed. This is a backward + incompatible change that may break existing users. + + * "git log" and friends learned the "--exclude=<glob>" option, to + allow people to say "list history of all branches except those that + match this pattern" with "git log --exclude='*/*' --branches". + + * "git rev-parse --parseopt" learned a new "--stuck-long" option to + help scripts parse options with an optional parameter. + + * The "--tags" option to "git fetch" no longer tells the command to + fetch _only_ the tags. It instead fetches tags _in addition to_ + what are fetched by the same command line without the option. + + +Performance, Internal Implementation, etc. + + * When parsing a 40-hex string into the object name, the string is + checked to see if it can be interpreted as a ref so that a warning + can be given for ambiguity. The code kicked in even when the + core.warnambiguousrefs is set to false to squelch this warning, in + which case the cycles spent to look at the ref namespace were an + expensive no-op, as the result was discarded without being used. + + * The naming convention of the packfiles has been updated; it used to + be based on the enumeration of names of the objects that are + contained in the pack, but now it also depends on how the packed + result is represented--packing the same set of objects using + different settings (or delta order) would produce a pack with + different name. + + * "git diff --no-index" mode used to unnecessarily attempt to read + the index when there is one. + + * The deprecated parse-options macro OPT_BOOLEAN has been removed; + use OPT_BOOL or OPT_COUNTUP in new code. + + * A few duplicate implementations of prefix/suffix string comparison + functions have been unified to starts_with() and ends_with(). + + * The new PERLLIB_EXTRA makefile variable can be used to specify + additional directories Perl modules (e.g. the ones necessary to run + git-svn) are installed on the platform when building. + + * "git merge-base" learned the "--fork-point" mode, that implements + the same logic used in "git pull --rebase" to find a suitable fork + point out of the reflog entries for the remote-tracking branch the + work has been based on. "git rebase" has the same logic that can be + triggered with the "--fork-point" option. + + * A third-party "receive-pack" (the responder to "git push") can + advertise the "no-thin" capability to tell "git push" not to use + the thin-pack optimization. Our receive-pack has always been + capable of accepting and fattening a thin-pack, and will continue + not to ask "git push" to use a non-thin pack. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v1.8.5 +------------------ + +Unless otherwise noted, all the fixes since v1.8.5 in the maintenance +track are contained in this release (see the maintenance releases' notes +for details). + + * The pathspec matching code, while comparing two trees (e.g. "git + diff A B -- path1 path2") was too aggressive and failed to match + some paths when multiple pathspecs were involved. + + * "git repack --max-pack-size=8g" stopped being parsed correctly when + the command was reimplemented in C. + + * An earlier update in v1.8.4.x to "git rev-list --objects" with + negative ref had a performance regression. + (merge 200abe7 jk/mark-edges-uninteresting later to maint). + + * A recent update to "git send-email" broke platforms where + /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path + (e.g. Fedora rawhide). + + * A handful of bugs around interpreting $branch@{upstream} notation + and its lookalike, when $branch part has interesting characters, + e.g. "@", and ":", have been fixed. + + * "git clone" would fail to clone from a repository that has a ref + directly under "refs/", e.g. "refs/stash", because different + validation paths do different things on such a refname. Loosen the + client side's validation to allow such a ref. + + * "git log --left-right A...B" lost the "leftness" of commits + reachable from A when A is a tag as a side effect of a recent + bugfix. This is a regression in 1.8.4.x series. + + * documentations to "git pull" hinted there is an "-m" option because + it incorrectly shared the documentation with "git merge". + + * "git diff A B submod" and "git diff A B submod/" ought to have done + the same for a submodule "submod", but didn't. + + * "git clone $origin foo\bar\baz" on Windows failed to create the + leading directories (i.e. a moral-equivalent of "mkdir -p"). + + * "submodule.*.update=checkout", when propagated from .gitmodules to + .git/config, turned into a "submodule.*.update=none", which did not + make much sense. + (merge efa8fd7 fp/submodule-checkout-mode later to maint). + + * The implementation of 'git stash $cmd "stash@{...}"' did not quote + the stash argument properly and left it split at IFS whitespace. + + * The "--[no-]informative-errors" options to "git daemon" were parsed + a bit too loosely, allowing any other string after these option + names. + + * There is no reason to have a hardcoded upper limit for the number of + parents of an octopus merge, created via the graft mechanism, but + there was. + + * The basic test used to leave unnecessary trash directories in the + t/ directory. + (merge 738a8be jk/test-framework-updates later to maint). + + * "git merge-base --octopus" used to leave cleaning up suboptimal + result to the caller, but now it does the clean-up itself. + + * A "gc" process running as a different user should be able to stop a + new "gc" process from starting, but it didn't. + + * An earlier "clean-up" introduced an unnecessary memory leak. + + * "git add -A" (no other arguments) in a totally empty working tree + used to emit an error. + + * "git log --decorate" did not handle a tag pointed by another tag + nicely. + + * When we figure out how many file descriptors to allocate for + keeping packfiles open, a system with non-working getrlimit() could + cause us to die(), but because we make this call only to get a + rough estimate of how many are available and we do not even attempt + to use up all available file descriptors ourselves, it is nicer to + fall back to a reasonable low value rather than dying. + + * read_sha1_file(), that is the workhorse to read the contents given + an object name, honoured object replacements, but there was no + corresponding mechanism to sha1_object_info() that was used to + obtain the metainfo (e.g. type & size) about the object. This led + callers to weird inconsistencies. + (merge 663a856 cc/replace-object-info later to maint). + + * "git cat-file --batch=", an admittedly useless command, did not + behave very well. + + * "git rev-parse <revs> -- <paths>" did not implement the usual + disambiguation rules the commands in the "git log" family used in + the same way. + + * "git mv A B/", when B does not exist as a directory, should error + out, but it didn't. + + * A workaround to an old bug in glibc prior to glibc 2.17 has been + retired; this would remove a side effect of the workaround that + corrupts system error messages in non-C locales. + + * SSL-related options were not passed correctly to underlying socket + layer in "git send-email". + + * "git commit -v" appends the patch to the log message before + editing, and then removes the patch when the editor returned + control. However, the patch was not stripped correctly when the + first modified path was a submodule. + + * "git fetch --depth=0" was a no-op, and was silently ignored. + Diagnose it as an error. + + * Remote repository URLs expressed in scp-style host:path notation are + parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks + to connect to user's home directory on host at address ::1. + + * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the + command line parser. + + * "git cat-file --batch-check=ok" did not check the existence of + the named object. + + * "git am --abort" sometimes complained about not being able to write + a tree with an 0{40} object in it. + + * Two processes creating loose objects at the same time could have + failed unnecessarily when the name of their new objects started + with the same byte value, due to a race condition. diff --git a/Documentation/RelNotes/1.9.1.txt b/Documentation/RelNotes/1.9.1.txt new file mode 100644 index 0000000000..5b0602053c --- /dev/null +++ b/Documentation/RelNotes/1.9.1.txt @@ -0,0 +1,59 @@ +Git v1.9.1 Release Notes +======================== + +Fixes since v1.9.0 +------------------ + + * "git clean -d pathspec" did not use the given pathspec correctly + and ended up cleaning too much. + + * "git difftool" misbehaved when the repository is bound to the + working tree with the ".git file" mechanism, where a textual file + ".git" tells us where it is. + + * "git push" did not pay attention to branch.*.pushremote if it is + defined earlier than remote.pushdefault; the order of these two + variables in the configuration file should not matter, but it did + by mistake. + + * Codepaths that parse timestamps in commit objects have been + tightened. + + * "git diff --external-diff" incorrectly fed the submodule directory + in the working tree to the external diff driver when it knew it is + the same as one of the versions being compared. + + * "git reset" needs to refresh the index when working in a working + tree (it can also be used to match the index to the HEAD in an + otherwise bare repository), but it failed to set up the working + tree properly, causing GIT_WORK_TREE to be ignored. + + * "git check-attr" when working on a repository with a working tree + did not work well when the working tree was specified via the + --work-tree (and obviously with --git-dir) option. + + * "merge-recursive" was broken in 1.7.7 era and stopped working in + an empty (temporary) working tree, when there are renames + involved. This has been corrected. + + * "git rev-parse" was loose in rejecting command line arguments + that do not make sense, e.g. "--default" without the required + value for that option. + + * include.path variable (or any variable that expects a path that + can use ~username expansion) in the configuration file is not a + boolean, but the code failed to check it. + + * "git diff --quiet -- pathspec1 pathspec2" sometimes did not return + correct status value. + + * Attempting to deepen a shallow repository by fetching over smart + HTTP transport failed in the protocol exchange, when no-done + extension was used. The fetching side waited for the list of + shallow boundary commits after the sending end stopped talking to + it. + + * Allow "git cmd path/", when the 'path' is where a submodule is + bound to the top-level working tree, to match 'path', despite the + extra and unnecessary trailing slash (such a slash is often + given by command line completion). diff --git a/Documentation/RelNotes/1.9.2.txt b/Documentation/RelNotes/1.9.2.txt new file mode 100644 index 0000000000..47a34ca964 --- /dev/null +++ b/Documentation/RelNotes/1.9.2.txt @@ -0,0 +1,67 @@ +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/Documentation/RelNotes/1.9.3.txt b/Documentation/RelNotes/1.9.3.txt new file mode 100644 index 0000000000..17b05ca7b5 --- /dev/null +++ b/Documentation/RelNotes/1.9.3.txt @@ -0,0 +1,21 @@ +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/Documentation/RelNotes/1.9.4.txt b/Documentation/RelNotes/1.9.4.txt new file mode 100644 index 0000000000..e1d1835436 --- /dev/null +++ b/Documentation/RelNotes/1.9.4.txt @@ -0,0 +1,16 @@ +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/Documentation/RelNotes/1.9.5.txt b/Documentation/RelNotes/1.9.5.txt new file mode 100644 index 0000000000..8d6ac0cf53 --- /dev/null +++ b/Documentation/RelNotes/1.9.5.txt @@ -0,0 +1,34 @@ +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/Documentation/RelNotes/2.0.0.txt b/Documentation/RelNotes/2.0.0.txt new file mode 100644 index 0000000000..2617372a0c --- /dev/null +++ b/Documentation/RelNotes/2.0.0.txt @@ -0,0 +1,364 @@ +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/Documentation/RelNotes/2.0.1.txt b/Documentation/RelNotes/2.0.1.txt new file mode 100644 index 0000000000..ce5579db3e --- /dev/null +++ b/Documentation/RelNotes/2.0.1.txt @@ -0,0 +1,115 @@ +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/Documentation/RelNotes/2.0.2.txt b/Documentation/RelNotes/2.0.2.txt new file mode 100644 index 0000000000..8e8321b2ef --- /dev/null +++ b/Documentation/RelNotes/2.0.2.txt @@ -0,0 +1,32 @@ +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/Documentation/RelNotes/2.0.3.txt b/Documentation/RelNotes/2.0.3.txt new file mode 100644 index 0000000000..4047b46bbe --- /dev/null +++ b/Documentation/RelNotes/2.0.3.txt @@ -0,0 +1,17 @@ +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/Documentation/RelNotes/2.0.4.txt b/Documentation/RelNotes/2.0.4.txt new file mode 100644 index 0000000000..7e340921a2 --- /dev/null +++ b/Documentation/RelNotes/2.0.4.txt @@ -0,0 +1,5 @@ +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/Documentation/RelNotes/2.0.5.txt b/Documentation/RelNotes/2.0.5.txt new file mode 100644 index 0000000000..3a16f697e8 --- /dev/null +++ b/Documentation/RelNotes/2.0.5.txt @@ -0,0 +1,34 @@ +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/Documentation/RelNotes/2.1.0.txt b/Documentation/RelNotes/2.1.0.txt new file mode 100644 index 0000000000..ae4753728e --- /dev/null +++ b/Documentation/RelNotes/2.1.0.txt @@ -0,0 +1,391 @@ +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/Documentation/RelNotes/2.1.1.txt b/Documentation/RelNotes/2.1.1.txt new file mode 100644 index 0000000000..830fc3cc6d --- /dev/null +++ b/Documentation/RelNotes/2.1.1.txt @@ -0,0 +1,44 @@ +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/Documentation/RelNotes/2.1.2.txt b/Documentation/RelNotes/2.1.2.txt new file mode 100644 index 0000000000..abc3b8928a --- /dev/null +++ b/Documentation/RelNotes/2.1.2.txt @@ -0,0 +1,20 @@ +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/Documentation/RelNotes/2.1.3.txt b/Documentation/RelNotes/2.1.3.txt new file mode 100644 index 0000000000..0dfb17c4fc --- /dev/null +++ b/Documentation/RelNotes/2.1.3.txt @@ -0,0 +1,26 @@ +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 reachability 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/Documentation/RelNotes/2.1.4.txt b/Documentation/RelNotes/2.1.4.txt new file mode 100644 index 0000000000..d16e5f041f --- /dev/null +++ b/Documentation/RelNotes/2.1.4.txt @@ -0,0 +1,34 @@ +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/Documentation/RelNotes/2.10.0.txt b/Documentation/RelNotes/2.10.0.txt new file mode 100644 index 0000000000..3792b7d03d --- /dev/null +++ b/Documentation/RelNotes/2.10.0.txt @@ -0,0 +1,675 @@ +Git 2.10 Release Notes +====================== + +Backward compatibility notes +---------------------------- + +Updates since v2.9 +------------------ + +UI, Workflows & Features + + * "git pull --rebase --verify-signature" learned to warn the user + that "--verify-signature" is a no-op when rebasing. + + * An upstream project can make a recommendation to shallowly clone + some submodules in the .gitmodules file it ships. + + * "git worktree add" learned that '-' can be used as a short-hand for + "@{-1}", the previous branch. + + * Update the funcname definition to support css files. + + * The completion script (in contrib/) learned to complete "git + status" options. + + * Messages that are generated by auto gc during "git push" on the + receiving end are now passed back to the sending end in such a way + that they are shown with "remote: " prefix to avoid confusing the + users. + + * "git add -i/-p" learned to honor diff.compactionHeuristic + experimental knob, so that the user can work on the same hunk split + as "git diff" output. + + * "upload-pack" allows a custom "git pack-objects" replacement when + responding to "fetch/clone" via the uploadpack.packObjectsHook. + (merge b738396 jk/upload-pack-hook later to maint). + + * Teach format-patch and mailsplit (hence "am") how a line that + happens to begin with "From " in the e-mail message is quoted with + ">", so that these lines can be restored to their original shape. + (merge d9925d1 ew/mboxrd-format-am later to maint). + + * "git repack" learned the "--keep-unreachable" option, which sends + loose unreachable objects to a pack instead of leaving them loose. + This helps heuristics based on the number of loose objects + (e.g. "gc --auto"). + (merge e26a8c4 jk/repack-keep-unreachable later to maint). + + * "log --graph --format=" learned that "%>|(N)" specifies the width + relative to the terminal's left edge, not relative to the area to + draw text that is to the right of the ancestry-graph section. It + also now accepts negative N that means the column limit is relative + to the right border. + + * A careless invocation of "git send-email directory/" after editing + 0001-change.patch with an editor often ends up sending both + 0001-change.patch and its backup file, 0001-change.patch~, causing + embarrassment and a minor confusion. Detect such an input and + offer to skip the backup files when sending the patches out. + (merge 531220b jc/send-email-skip-backup later to maint). + + * "git submodule update" that drives many "git clone" could + eventually hit flaky servers/network conditions on one of the + submodules; the command learned to retry the attempt. + + * The output coloring scheme learned two new attributes, italic and + strike, in addition to existing bold, reverse, etc. + + * "git log" learns log.showSignature configuration variable, and a + command line option "--no-show-signature" to countermand it. + (merge fce04c3 mj/log-show-signature-conf later to maint). + + * More markings of messages for i18n, with updates to various tests + to pass GETTEXT_POISON tests. + + * "git archive" learned to handle files that are larger than 8GB and + commits far in the future than expressible by the traditional US-TAR + format. + (merge 560b0e8 jk/big-and-future-archive-tar later to maint). + + + * A new configuration variable core.sshCommand has been added to + specify what value for GIT_SSH_COMMAND to use per repository. + + * "git worktree prune" protected worktrees that are marked as + "locked" by creating a file in a known location. "git worktree" + command learned a dedicated command pair to create and remove such + a file, so that the users do not have to do this with editor. + + * A handful of "git svn" updates. + + * "git push" learned to accept and pass extra options to the + receiving end so that hooks can read and react to them. + + * "git status" learned to suggest "merge --abort" during a conflicted + merge, just like it already suggests "rebase --abort" during a + conflicted rebase. + + * "git jump" script (in contrib/) has been updated a bit. + (merge a91e692 jk/git-jump later to maint). + + * "git push" and "git clone" learned to give better progress meters + to the end user who is waiting on the terminal. + + * An entry "git log --decorate" for the tip of the current branch is + shown as "HEAD -> name" (where "name" is the name of the branch); + the arrow is now painted in the same color as "HEAD", not in the + color for commits. + + * "git format-patch" learned format.from configuration variable to + specify the default settings for its "--from" option. + + * "git am -3" calls "git merge-recursive" when it needs to fall back + to a three-way merge; this call has been turned into an internal + subroutine call instead of spawning a separate subprocess. + + * The command line completion scripts (in contrib/) now knows about + "git branch --delete/--move [--remote]". + (merge 2703c22 vs/completion-branch-fully-spelled-d-m-r later to maint). + + * "git rev-parse --git-path hooks/<hook>" learned to take + core.hooksPath configuration variable (introduced during 2.9 cycle) + into account. + (merge 9445b49 ab/hooks later to maint). + + * "git log --show-signature" and other commands that display the + verification status of PGP signature now shows the longer key-id, + as 32-bit key-id is so last century. + + +Performance, Internal Implementation, Development Support etc. + + * "git fast-import" learned the same performance trick to avoid + creating too small a packfile as "git fetch" and "git push" have, + using *.unpackLimit configuration. + + * When "git daemon" is run without --[init-]timeout specified, a + connection from a client that silently goes offline can hang around + for a long time, wasting resources. The socket-level KEEPALIVE has + been enabled to allow the OS to notice such failed connections. + + * "git upload-pack" command has been updated to use the parse-options + API. + + * The "git apply" standalone program is being libified; the first + step to move many state variables into a structure that can be + explicitly (re)initialized to make the machinery callable more + than once has been merged. + + * HTTP transport gained an option to produce more detailed debugging + trace. + (merge 73e57aa ep/http-curl-trace later to maint). + + * Instead of taking advantage of the fact that a struct string_list + that is allocated with all NULs happens to be the INIT_NODUP kind, + the users of string_list structures are taught to initialize them + explicitly as such, to document their behaviour better. + (merge 2721ce2 jk/string-list-static-init later to maint). + + * HTTPd tests learned to show the server error log to help diagnosing + a failing tests. + (merge 44f243d nd/test-lib-httpd-show-error-log-in-verbose later to maint). + + * The ownership rule for the piece of memory that hold references to + be fetched in "git fetch" was screwy, which has been cleaned up. + + * "git bisect" makes an internal call to "git diff-tree" when + bisection finds the culprit, but this call did not initialize the + data structure to pass to the diff-tree API correctly. + + * Further preparatory clean-up for "worktree" feature continues. + (merge 0409e0b nd/worktree-cleanup-post-head-protection later to maint). + + * Formats of the various data (and how to validate them) where we use + GPG signature have been documented. + + * A new run-command API function pipe_command() is introduced to + sanely feed data to the standard input while capturing data from + the standard output and the standard error of an external process, + which is cumbersome to hand-roll correctly without deadlocking. + + * The codepath to sign data in a prepared buffer with GPG has been + updated to use this API to read from the status-fd to check for + errors (instead of relying on GPG's exit status). + (merge efee955 jk/gpg-interface-cleanup later to maint). + + * Allow t/perf framework to use the features from the most recent + version of Git even when testing an older installed version. + + * The commands in the "log/diff" family have had an FILE* pointer in the + data structure they pass around for a long time, but some codepaths + used to always write to the standard output. As a preparatory step + to make "git format-patch" available to the internal callers, these + codepaths have been updated to consistently write into that FILE* + instead. + + * Conversion from unsigned char sha1[20] to struct object_id + continues. + + * Improve the look of the way "git fetch" reports what happened to + each ref that was fetched. + + * The .c/.h sources are marked as such in our .gitattributes file so + that "git diff -W" and friends would work better. + + * Code clean-up to avoid using a variable string that compilers may + feel untrustable as printf-style format given to write_file() + helper function. + + * "git p4" used a location outside $GIT_DIR/refs/ to place its + temporary branches, which has been moved to refs/git-p4-tmp/. + + * Existing autoconf generated test for the need to link with pthread + library did not check all the functions from pthread libraries; + recent FreeBSD has some functions in libc but not others, and we + mistakenly thought linking with libc is enough when it is not. + + * When "git fsck" reports a broken link (e.g. a tree object contains + a blob that does not exist), both containing object and the object + that is referred to were reported with their 40-hex object names. + The command learned the "--name-objects" option to show the path to + the containing object from existing refs (e.g. "HEAD~24^2:file.txt"). + + * Allow http daemon tests in Travis CI tests. + + * Makefile assumed that -lrt is always available on platforms that + want to use clock_gettime() and CLOCK_MONOTONIC, which is not a + case for recent Mac OS X. The necessary symbols are often found in + libc on many modern systems and having -lrt on the command line, as + long as the library exists, had no effect, but when the platform + removes librt.a that is a different matter--having -lrt will break + the linkage. + + This change could be seen as a regression for those who do need to + specify -lrt, as they now specifically ask for NEEDS_LIBRT when + building. Hopefully they are in the minority these days. + + * Further preparatory work on the refs API before the pluggable + backend series can land. + + * Error handling in the codepaths that updates refs has been + improved. + + * The API to iterate over all the refs (i.e. for_each_ref(), etc.) + has been revamped. + + * The handling of the "text=auto" attribute has been corrected. + $ echo "* text=auto eol=crlf" >.gitattributes + used to have the same effect as + $ echo "* text eol=crlf" >.gitattributes + i.e. declaring all files are text (ignoring "auto"). The + combination has been fixed to be equivalent to doing + $ git config core.autocrlf true + + * Documentation has been updated to show better example usage + of the updated "text=auto" attribute. + + * A few tests that specifically target "git rebase -i" have been + added. + + * Dumb http transport on the client side has been optimized. + (merge ecba195 ew/http-walker later to maint). + + * Users of the parse_options_concat() API function need to allocate + extra slots in advance and fill them with OPT_END() when they want + to decide the set of supported options dynamically, which makes the + code error-prone and hard to read. This has been corrected by tweaking + the API to allocate and return a new copy of "struct option" array. + + * "git fetch" exchanges batched have/ack messages between the sender + and the receiver, initially doubling every time and then falling + back to enlarge the window size linearly. The "smart http" + transport, being an half-duplex protocol, outgrows the preset limit + too quickly and becomes inefficient when interacting with a large + repository. The internal mechanism learned to grow the window size + more aggressively when working with the "smart http" transport. + + * Tests for "git svn" have been taught to reuse the lib-httpd test + infrastructure when testing the subversion integration that + interacts with subversion repositories served over the http:// + protocol. + (merge a8a5d25 ew/git-svn-http-tests later to maint). + + * "git pack-objects" has a few options that tell it not to pack + objects found in certain packfiles, which require it to scan .idx + files of all available packs. The codepaths involved in these + operations have been optimized for a common case of not having any + non-local pack and/or any .kept pack. + + * The t3700 test about "add --chmod=-x" have been made a bit more + robust and generally cleaned up. + (merge 766cdc4 ib/t3700-add-chmod-x-updates later to maint). + + * The build procedure learned PAGER_ENV knob that lists what default + environment variable settings to export for popular pagers. This + mechanism is used to tweak the default settings to MORE on FreeBSD. + (merge 995bc22 ew/build-time-pager-tweaks later to maint). + + * The http-backend (the server-side component of smart-http + transport) used to trickle the HTTP header one at a time. Now + these write(2)s are batched. + (merge b36045c ew/http-backend-batch-headers later to maint). + + * When "git rebase" tries to compare set of changes on the updated + upstream and our own branch, it computes patch-id for all of these + changes and attempts to find matches. This has been optimized by + lazily computing the full patch-id (which is expensive) to be + compared only for changes that touch the same set of paths. + (merge ba67504 kw/patch-ids-optim later to maint). + + * A handful of tests that were broken under gettext-poison build have + been fixed. + + * The recent i18n patch we added during this cycle did a bit too much + refactoring of the messages to avoid word-legos; the repetition has + been reduced to help translators. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.9 +---------------- + +Unless otherwise noted, all the fixes since v2.8 in the maintenance +track are contained in this release (see the maintenance releases' +notes for details). + + * The commands in `git log` family take %C(auto) in a custom format + string. This unconditionally turned the color on, ignoring + --no-color or with --color=auto when the output is not connected to + a tty; this was corrected to make the format truly behave as + "auto". + + * "git rev-list --count" whose walk-length is limited with "-n" + option did not work well with the counting optimized to look at the + bitmap index. + + * "git show -W" (extend hunks to cover the entire function, delimited + by lines that match the "funcname" pattern) used to show the entire + file when a change added an entire function at the end of the file, + which has been fixed. + + * The documentation set has been updated so that literal commands, + configuration variables and environment variables are consistently + typeset in fixed-width font and bold in manpages. + + * "git svn propset" subcommand that was added in 2.3 days is + documented now. + + * The documentation tries to consistently spell "GPG"; when + referring to the specific program name, "gpg" is used. + + * "git reflog" stopped upon seeing an entry that denotes a branch + creation event (aka "unborn"), which made it appear as if the + reflog was truncated. + + * The git-prompt scriptlet (in contrib/) was not friendly with those + who uses "set -u", which has been fixed. + + * compat/regex code did not cleanly compile. + + * A codepath that used alloca(3) to place an unbounded amount of data + on the stack has been updated to avoid doing so. + + * "git update-index --add --chmod=+x file" may be usable as an escape + hatch, but not a friendly thing to force for people who do need to + use it regularly. "git add --chmod=+x file" can be used instead. + + * Build improvements for gnome-keyring (in contrib/) + + * "git status" used to say "working directory" when it meant "working + tree". + + * Comments about misbehaving FreeBSD shells have been clarified with + the version number (9.x and before are broken, newer ones are OK). + + * "git cherry-pick A" worked on an unborn branch, but "git + cherry-pick A..B" didn't. + + * Fix an unintended regression in v2.9 that breaks "clone --depth" + that recurses down to submodules by forcing the submodules to also + be cloned shallowly, which many server instances that host upstream + of the submodules are not prepared for. + + * Fix unnecessarily waste in the idiomatic use of ': ${VAR=default}' + to set the default value, without enclosing it in double quotes. + + * Some platform-specific code had non-ANSI strict declarations of C + functions that do not take any parameters, which has been + corrected. + + * The internal code used to show local timezone offset is not + prepared to handle timestamps beyond year 2100, and gave a + bogus offset value to the caller. Use a more benign looking + +0000 instead and let "git log" going in such a case, instead + of aborting. + + * One among four invocations of readlink(1) in our test suite has + been rewritten so that the test can run on systems without the + command (others are in valgrind test framework and t9802). + + * t/perf needs /usr/bin/time with GNU extension; the invocation of it + is updated to "gtime" on Darwin. + + * A bug, which caused "git p4" while running under verbose mode to + report paths that are omitted due to branch prefix incorrectly, has + been fixed; the command said "Ignoring file outside of prefix" for + paths that are _inside_. + + * The top level documentation "git help git" still pointed at the + documentation set hosted at now-defunct google-code repository. + Update it to point to https://git.github.io/htmldocs/git.html + instead. + + * A helper function that takes the contents of a commit object and + finds its subject line did not ignore leading blank lines, as is + commonly done by other codepaths. Make it ignore leading blank + lines to match. + + * For a long time, we carried an in-code comment that said our + colored output would work only when we use fprintf/fputs on + Windows, which no longer is the case for the past few years. + + * "gc.autoPackLimit" when set to 1 should not trigger a repacking + when there is only one pack, but the code counted poorly and did + so. + + * Add a test to specify the desired behaviour that currently is not + available in "git rebase -Xsubtree=...". + + * More mark-up updates to typeset strings that are expected to + literally typed by the end user in fixed-width font. + + * "git commit --amend --allow-empty-message -S" for a commit without + any message body could have misidentified where the header of the + commit object ends. + + * "git rebase -i --autostash" did not restore the auto-stashed change + when the operation was aborted. + + * Git does not know what the contents in the index should be for a + path added with "git add -N" yet, so "git grep --cached" should not + show hits (or show lack of hits, with -L) in such a path, but that + logic does not apply to "git grep", i.e. searching in the working + tree files. But we did so by mistake, which has been corrected. + + * "git blame -M" missed a single line that was moved within the file. + + * Fix recently introduced codepaths that are involved in parallel + submodule operations, which gave up on reading too early, and + could have wasted CPU while attempting to write under a corner + case condition. + + * "git grep -i" has been taught to fold case in non-ascii locales + correctly. + + * A test that unconditionally used "mktemp" learned that the command + is not necessarily available everywhere. + + * There are certain house-keeping tasks that need to be performed at + the very beginning of any Git program, and programs that are not + built-in commands had to do them exactly the same way as "git" + potty does. It was easy to make mistakes in one-off standalone + programs (like test helpers). A common "main()" function that + calls cmd_main() of individual program has been introduced to + make it harder to make mistakes. + (merge de61ceb jk/common-main later to maint). + + * The test framework learned a new helper test_match_signal to + check an exit code from getting killed by an expected signal. + + * General code clean-up around a helper function to write a + single-liner to a file. + (merge 7eb6e10 jk/write-file later to maint). + + * One part of "git am" had an oddball helper function that called + stuff from outside "his" as opposed to calling what we have "ours", + which was not gender-neutral and also inconsistent with the rest of + the system where outside stuff is usually called "theirs" in + contrast to "ours". + + * "git blame file" allowed the lineage of lines in the uncommitted, + unadded contents of "file" to be inspected, but it refused when + "file" did not appear in the current commit. When "file" was + created by renaming an existing file (but the change has not been + committed), this restriction was unnecessarily tight. + + * "git add -N dir/file && git write-tree" produced an incorrect tree + when there are other paths in the same directory that sorts after + "file". + + * "git fetch http://user:pass@host/repo..." scrubbed the userinfo + part, but "git push" didn't. + + * "git merge" with renormalization did not work well with + merge-recursive, due to "safer crlf" conversion kicking in when it + shouldn't. + (merge 1335d76 jc/renormalize-merge-kill-safer-crlf later to maint). + + * The use of strbuf in "git rm" to build filename to remove was a bit + suboptimal, which has been fixed. + + * An age old bug that caused "git diff --ignore-space-at-eol" + misbehave has been fixed. + + * "git notes merge" had a code to see if a path exists (and fails if + it does) and then open the path for writing (when it doesn't). + Replace it with open with O_EXCL. + + * "git pack-objects" and "git index-pack" mostly operate with off_t + when talking about the offset of objects in a packfile, but there + were a handful of places that used "unsigned long" to hold that + value, leading to an unintended truncation. + + * Recent update to "git daemon" tries to enable the socket-level + KEEPALIVE, but when it is spawned via inetd, the standard input + file descriptor may not necessarily be connected to a socket. + Suppress an ENOTSOCK error from setsockopt(). + + * Recent FreeBSD stopped making perl available at /usr/bin/perl; + switch the default the built-in path to /usr/local/bin/perl on not + too ancient FreeBSD releases. + + * "git commit --help" said "--no-verify" is only about skipping the + pre-commit hook, and failed to say that it also skipped the + commit-msg hook. + + * "git merge" in Git v2.9 was taught to forbid merging an unrelated + lines of history by default, but that is exactly the kind of thing + the "--rejoin" mode of "git subtree" (in contrib/) wants to do. + "git subtree" has been taught to use the "--allow-unrelated-histories" + option to override the default. + + * The build procedure for "git persistent-https" helper (in contrib/) + has been updated so that it can be built with more recent versions + of Go. + + * There is an optimization used in "git diff $treeA $treeB" to borrow + an already checked-out copy in the working tree when it is known to + be the same as the blob being compared, expecting that open/mmap of + such a file is faster than reading it from the object store, which + involves inflating and applying delta. This however kicked in even + when the checked-out copy needs to go through the convert-to-git + conversion (including the clean filter), which defeats the whole + point of the optimization. The optimization has been disabled when + the conversion is necessary. + + * "git -c grep.patternType=extended log --basic-regexp" misbehaved + because the internal API to access the grep machinery was not + designed well. + + * Windows port was failing some tests in t4130, due to the lack of + inum in the returned values by its lstat(2) emulation. + + * The reflog output format is documented better, and a new format + --date=unix to report the seconds-since-epoch (without timezone) + has been added. + (merge 442f6fd jk/reflog-date later to maint). + + * "git difftool <paths>..." started in a subdirectory failed to + interpret the paths relative to that directory, which has been + fixed. + + * The characters in the label shown for tags/refs for commits in + "gitweb" output are now properly escaped for proper HTML output. + + * FreeBSD can lie when asked mtime of a directory, which made the + untracked cache code to fall back to a slow-path, which in turn + caused tests in t7063 to fail because it wanted to verify the + behaviour of the fast-path. + + * Squelch compiler warnings for nedmalloc (in compat/) library. + + * A small memory leak in the command line parsing of "git blame" + has been plugged. + + * The API documentation for hashmap was unclear if hashmap_entry + can be safely discarded without any other consideration. State + that it is safe to do so. + + * Not-so-recent rewrite of "git am" that started making internal + calls into the commit machinery had an unintended regression, in + that no matter how many seconds it took to apply many patches, the + resulting committer timestamp for the resulting commits were all + the same. + + * "git push --force-with-lease" already had enough logic to allow + ensuring that such a push results in creation of a ref (i.e. the + receiving end did not have another push from sideways that would be + discarded by our force-pushing), but didn't expose this possibility + to the users. It does so now. + (merge 9eed4f3 jk/push-force-with-lease-creation later to maint). + + * The mechanism to limit the pack window memory size, when packing is + done using multiple threads (which is the default), is per-thread, + but this was not documented clearly. + (merge 954176c ms/document-pack-window-memory-is-per-thread later to maint). + + * "import-tars" fast-import script (in contrib/) used to ignore a + hardlink target and replaced it with an empty file, which has been + corrected to record the same blob as the other file the hardlink is + shared with. + (merge 04e0869 js/import-tars-hardlinks later to maint). + + * "git mv dir non-existing-dir/" did not work in some environments + the same way as existing mainstream platforms. The code now moves + "dir" to "non-existing-dir", without relying on rename("A", "B/") + that strips the trailing slash of '/'. + (merge 189d035 js/mv-dir-to-new-directory later to maint). + + * The "t/" hierarchy is prone to get an unusual pathname; "make test" + has been taught to make sure they do not contain paths that cannot + be checked out on Windows (and the mechanism can be reusable to + catch pathnames that are not portable to other platforms as need + arises). + (merge c2cafd3 js/test-lint-pathname later to maint). + + * When "git merge-recursive" works on history with many criss-cross + merges in "verbose" mode, the names the command assigns to the + virtual merge bases could have overwritten each other by unintended + reuse of the same piece of memory. + (merge 5447a76 rs/pull-signed-tag later to maint). + + * "git checkout --detach <branch>" used to give the same advice + message as that is issued when "git checkout <tag>" (or anything + that is not a branch name) is given, but asking with "--detach" is + an explicit enough sign that the user knows what is going on. The + advice message has been squelched in this case. + (merge 779b88a sb/checkout-explit-detach-no-advice later to maint). + + * "git difftool" by default ignores the error exit from the backend + commands it spawns, because often they signal that they found + differences by exiting with a non-zero status code just like "diff" + does; the exit status codes 126 and above however are special in + that they are used to signal that the command is not executable, + does not exist, or killed by a signal. "git difftool" has been + taught to notice these exit status codes. + (merge 45a4f5d jk/difftool-command-not-found later to maint). + + * On Windows, help.browser configuration variable used to be ignored, + which has been corrected. + (merge 6db5967 js/no-html-bypass-on-windows later to maint). + + * The "git -c var[=val] cmd" facility to append a configuration + variable definition at the end of the search order was described in + git(1) manual page, but not in git-config(1), which was more likely + place for people to look for when they ask "can I make a one-shot + override, and if so how?" + (merge ae1f709 dg/document-git-c-in-git-config-doc later to maint). + + * The tempfile (hence its user lockfile) API lets the caller to open + a file descriptor to a temporary file, write into it and then + finalize it by first closing the filehandle and then either + removing or renaming the temporary file. When the process spawns a + subprocess after obtaining the file descriptor, and if the + subprocess has not exited when the attempt to remove or rename is + made, the last step fails on Windows, because the subprocess has + the file descriptor still open. Open tempfile with O_CLOEXEC flag + to avoid this (on Windows, this is mapped to O_NOINHERIT). + (merge 05d1ed6 bw/mingw-avoid-inheriting-fd-to-lockfile later to maint). + + * Correct an age-old calco (is that a typo-like word for calc) + in the documentation. + (merge 7841c48 ls/packet-line-protocol-doc-fix later to maint). + + * Other minor clean-ups and documentation updates + (merge 02a8cfa rs/merge-add-strategies-simplification later to maint). + (merge af4941d rs/merge-recursive-string-list-init later to maint). + (merge 1eb47f1 rs/use-strbuf-add-unique-abbrev later to maint). + (merge ddd0bfa jk/tighten-alloc later to maint). + (merge ecf30b2 rs/mailinfo-lib later to maint). + (merge 0eb75ce sg/reflog-past-root later to maint). + (merge 4369523 hv/doc-commit-reference-style later to maint). diff --git a/Documentation/RelNotes/2.10.1.txt b/Documentation/RelNotes/2.10.1.txt new file mode 100644 index 0000000000..70462f7f7e --- /dev/null +++ b/Documentation/RelNotes/2.10.1.txt @@ -0,0 +1,131 @@ +Git v2.10.1 Release Notes +========================= + +Fixes since v2.10 +----------------- + + * Clarify various ways to specify the "revision ranges" in the + documentation. + + * "diff-highlight" script (in contrib/) learned to work better with + "git log -p --graph" output. + + * The test framework left the number of tests and success/failure + count in the t/test-results directory, keyed by the name of the + test script plus the process ID. The latter however turned out not + to serve any useful purpose. The process ID part of the filename + has been removed. + + * Having a submodule whose ".git" repository is somehow corrupt + caused a few commands that recurse into submodules loop forever. + + * "git symbolic-ref -d HEAD" happily removes the symbolic ref, but + the resulting repository becomes an invalid one. Teach the command + to forbid removal of HEAD. + + * A test spawned a short-lived background process, which sometimes + prevented the test directory from getting removed at the end of the + script on some platforms. + + * Update a few tests that used to use GIT_CURL_VERBOSE to use the + newer GIT_TRACE_CURL. + + * Update Japanese translation for "git-gui". + + * "git fetch http::/site/path" did not die correctly and segfaulted + instead. + + * "git commit-tree" stopped reading commit.gpgsign configuration + variable that was meant for Porcelain "git commit" in Git 2.9; we + forgot to update "git gui" to look at the configuration to match + this change. + + * "git log --cherry-pick" used to include merge commits as candidates + to be matched up with other commits, resulting a lot of wasted time. + The patch-id generation logic has been updated to ignore merges to + avoid the wastage. + + * The http transport (with curl-multi option, which is the default + these days) failed to remove curl-easy handle from a curlm session, + which led to unnecessary API failures. + + * "git diff -W" output needs to extend the context backward to + include the header line of the current function and also forward to + include the body of the entire current function up to the header + line of the next one. This process may have to merge to adjacent + hunks, but the code forgot to do so in some cases. + + * Performance tests done via "t/perf" did not use the same set of + build configuration if the user relied on autoconf generated + configuration. + + * "git format-patch --base=..." feature that was recently added + showed the base commit information after "-- " e-mail signature + line, which turned out to be inconvenient. The base information + has been moved above the signature line. + + * Even when "git pull --rebase=preserve" (and the underlying "git + rebase --preserve") can complete without creating any new commit + (i.e. fast-forwards), it still insisted on having a usable ident + information (read: user.email is set correctly), which was less + than nice. As the underlying commands used inside "git rebase" + would fail with a more meaningful error message and advice text + when the bogus ident matters, this extra check was removed. + + * "git gc --aggressive" used to limit the delta-chain length to 250, + which is way too deep for gaining additional space savings and is + detrimental for runtime performance. The limit has been reduced to + 50. + + * Documentation for individual configuration variables to control use + of color (like `color.grep`) said that their default value is + 'false', instead of saying their default is taken from `color.ui`. + When we updated the default value for color.ui from 'false' to + 'auto' quite a while ago, all of them broke. This has been + corrected. + + * A shell script example in check-ref-format documentation has been + fixed. + + * "git checkout <word>" does not follow the usual disambiguation + rules when the <word> can be both a rev and a path, to allow + checking out a branch 'foo' in a project that happens to have a + file 'foo' in the working tree without having to disambiguate. + This was poorly documented and the check was incorrect when the + command was run from a subdirectory. + + * Some codepaths in "git diff" used regexec(3) on a buffer that was + mmap(2)ed, which may not have a terminating NUL, leading to a read + beyond the end of the mapped region. This was fixed by introducing + a regexec_buf() helper that takes a <ptr,len> pair with REG_STARTEND + extension. + + * The procedure to build Git on Mac OS X for Travis CI hardcoded the + internal directory structure we assumed HomeBrew uses, which was a + no-no. The procedure has been updated to ask HomeBrew things we + need to know to fix this. + + * When "git rebase -i" is given a broken instruction, it told the + user to fix it with "--edit-todo", but didn't say what the step + after that was (i.e. "--continue"). + + * "git add --chmod=+x" added recently lacked documentation, which has + been corrected. + + * "git add --chmod=+x <pathspec>" added recently only toggled the + executable bit for paths that are either new or modified. This has + been corrected to flip the executable bit for all paths that match + the given pathspec. + + * "git pack-objects --include-tag" was taught that when we know that + we are sending an object C, we want a tag B that directly points at + C but also a tag A that points at the tag B. We used to miss the + intermediate tag B in some cases. + + * Documentation around tools to import from CVS was fairly outdated. + + * In the codepath that comes up with the hostname to be used in an + e-mail when the user didn't tell us, we looked at ai_canonname + field in struct addrinfo without making sure it is not NULL first. + +Also contains minor documentation updates and code clean-ups. diff --git a/Documentation/RelNotes/2.10.2.txt b/Documentation/RelNotes/2.10.2.txt new file mode 100644 index 0000000000..abbd331508 --- /dev/null +++ b/Documentation/RelNotes/2.10.2.txt @@ -0,0 +1,111 @@ +Git v2.10.2 Release Notes +========================= + +Fixes since v2.10.1 +------------------- + + * The code that parses the format parameter of for-each-ref command + has seen a micro-optimization. + + * The "graph" API used in "git log --graph" miscounted the number of + output columns consumed so far when drawing a padding line, which + has been fixed; this did not affect any existing code as nobody + tried to write anything after the padding on such a line, though. + + * Almost everybody uses DEFAULT_ABBREV to refer to the default + setting for the abbreviation, but "git blame" peeked into + underlying variable bypassing the macro for no good reason. + + * Doc update to clarify what "log -3 --reverse" does. + + * An author name, that spelled a backslash-quoted double quote in the + human readable part "My \"double quoted\" name", was not unquoted + correctly while applying a patch from a piece of e-mail. + + * The original command line syntax for "git merge", which was "git + merge <msg> HEAD <parent>...", has been deprecated for quite some + time, and "git gui" was the last in-tree user of the syntax. This + is finally fixed, so that we can move forward with the deprecation. + + * Codepaths that read from an on-disk loose object were too loose in + validating what they are reading is a proper object file and + sometimes read past the data they read from the disk, which has + been corrected. H/t to Gustavo Grieco for reporting. + + * "git worktree", even though it used the default_abbrev setting that + ought to be affected by core.abbrev configuration variable, ignored + the variable setting. The command has been taught to read the + default set of configuration variables to correct this. + + * A low-level function verify_packfile() was meant to show errors + that were detected without dying itself, but under some conditions + it didn't and died instead, which has been fixed. + + * When "git fetch" tries to find where the history of the repository + it runs in has diverged from what the other side has, it has a + mechanism to avoid digging too deep into irrelevant side branches. + This however did not work well over the "smart-http" transport due + to a design bug, which has been fixed. + + * When we started cURL to talk to imap server when a new enough + version of cURL library is available, we forgot to explicitly add + imap(s):// before the destination. To some folks, that didn't work + and the library tried to make HTTP(s) requests instead. + + * The ./configure script generated from configure.ac was taught how + to detect support of SSL by libcurl better. + + * http.emptyauth configuration is a way to allow an empty username to + pass when attempting to authenticate using mechanisms like + Kerberos. We took an unspecified (NULL) username and sent ":" + (i.e. no username, no password) to CURLOPT_USERPWD, but did not do + the same when the username is explicitly set to an empty string. + + * "git clone" of a local repository can be done at the filesystem + level, but the codepath did not check errors while copying and + adjusting the file that lists alternate object stores. + + * Documentation for "git commit" was updated to clarify that "commit + -p <paths>" adds to the current contents of the index to come up + with what to commit. + + * A stray symbolic link in $GIT_DIR/refs/ directory could make name + resolution loop forever, which has been corrected. + + * The "submodule.<name>.path" stored in .gitmodules is never copied + to .git/config and such a key in .git/config has no meaning, but + the documentation described it and submodule.<name>.url next to + each other as if both belong to .git/config. This has been fixed. + + * Recent git allows submodule.<name>.branch to use a special token + "." instead of the branch name; the documentation has been updated + to describe it. + + * In a worktree connected to a repository elsewhere, created via "git + worktree", "git checkout" attempts to protect users from confusion + by refusing to check out a branch that is already checked out in + another worktree. However, this also prevented checking out a + branch, which is designated as the primary branch of a bare + 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 + when checking if the object pointed at by a tag (that we are not + going to fetch!) exists in our repository too carefully. + + * The Travis CI configuration we ship ran the tests with --verbose + option but this risks non-TAP output that happens to be "ok" to be + misinterpreted as TAP signalling a test that passed. This resulted + in unnecessary failure. This has been corrected by introducing a + new mode to run our tests in the test harness to send the verbose + output separately to the log file. + + * Some AsciiDoc formatter mishandles a displayed illustration with + tabs in it. Adjust a few of them in merge-base documentation to + work around them. + +Also contains minor documentation updates and code clean-ups. diff --git a/Documentation/RelNotes/2.10.3.txt b/Documentation/RelNotes/2.10.3.txt new file mode 100644 index 0000000000..ad6a01bf83 --- /dev/null +++ b/Documentation/RelNotes/2.10.3.txt @@ -0,0 +1,55 @@ +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/Documentation/RelNotes/2.10.4.txt b/Documentation/RelNotes/2.10.4.txt new file mode 100644 index 0000000000..ee8142ad24 --- /dev/null +++ b/Documentation/RelNotes/2.10.4.txt @@ -0,0 +1,4 @@ +Git v2.10.4 Release Notes +========================= + +This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/Documentation/RelNotes/2.10.5.txt b/Documentation/RelNotes/2.10.5.txt new file mode 100644 index 0000000000..a498fd6fdc --- /dev/null +++ b/Documentation/RelNotes/2.10.5.txt @@ -0,0 +1,17 @@ +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/Documentation/RelNotes/2.11.0.txt b/Documentation/RelNotes/2.11.0.txt new file mode 100644 index 0000000000..b7b7dd361e --- /dev/null +++ b/Documentation/RelNotes/2.11.0.txt @@ -0,0 +1,593 @@ +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/Documentation/RelNotes/2.11.1.txt b/Documentation/RelNotes/2.11.1.txt new file mode 100644 index 0000000000..7d35cf186d --- /dev/null +++ b/Documentation/RelNotes/2.11.1.txt @@ -0,0 +1,168 @@ +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 multiple 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/Documentation/RelNotes/2.11.2.txt b/Documentation/RelNotes/2.11.2.txt new file mode 100644 index 0000000000..7428851168 --- /dev/null +++ b/Documentation/RelNotes/2.11.2.txt @@ -0,0 +1,12 @@ +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/Documentation/RelNotes/2.11.3.txt b/Documentation/RelNotes/2.11.3.txt new file mode 100644 index 0000000000..4e3b78d0e8 --- /dev/null +++ b/Documentation/RelNotes/2.11.3.txt @@ -0,0 +1,4 @@ +Git v2.11.3 Release Notes +========================= + +This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/Documentation/RelNotes/2.11.4.txt b/Documentation/RelNotes/2.11.4.txt new file mode 100644 index 0000000000..ad4da8eb09 --- /dev/null +++ b/Documentation/RelNotes/2.11.4.txt @@ -0,0 +1,17 @@ +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/Documentation/RelNotes/2.12.0.txt b/Documentation/RelNotes/2.12.0.txt new file mode 100644 index 0000000000..d2f6a83614 --- /dev/null +++ b/Documentation/RelNotes/2.12.0.txt @@ -0,0 +1,500 @@ +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 multiple 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/Documentation/RelNotes/2.12.1.txt b/Documentation/RelNotes/2.12.1.txt new file mode 100644 index 0000000000..a74f7db747 --- /dev/null +++ b/Documentation/RelNotes/2.12.1.txt @@ -0,0 +1,41 @@ +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/Documentation/RelNotes/2.12.2.txt b/Documentation/RelNotes/2.12.2.txt new file mode 100644 index 0000000000..441939709c --- /dev/null +++ b/Documentation/RelNotes/2.12.2.txt @@ -0,0 +1,83 @@ +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/Documentation/RelNotes/2.12.3.txt b/Documentation/RelNotes/2.12.3.txt new file mode 100644 index 0000000000..ebca846d5d --- /dev/null +++ b/Documentation/RelNotes/2.12.3.txt @@ -0,0 +1,64 @@ +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/Documentation/RelNotes/2.12.4.txt b/Documentation/RelNotes/2.12.4.txt new file mode 100644 index 0000000000..3f56938221 --- /dev/null +++ b/Documentation/RelNotes/2.12.4.txt @@ -0,0 +1,4 @@ +Git v2.12.4 Release Notes +========================= + +This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/Documentation/RelNotes/2.12.5.txt b/Documentation/RelNotes/2.12.5.txt new file mode 100644 index 0000000000..8fa73cfce7 --- /dev/null +++ b/Documentation/RelNotes/2.12.5.txt @@ -0,0 +1,17 @@ +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/Documentation/RelNotes/2.13.0.txt b/Documentation/RelNotes/2.13.0.txt new file mode 100644 index 0000000000..2a47b4cb0c --- /dev/null +++ b/Documentation/RelNotes/2.13.0.txt @@ -0,0 +1,618 @@ +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 dirtiness 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/Documentation/RelNotes/2.13.1.txt b/Documentation/RelNotes/2.13.1.txt new file mode 100644 index 0000000000..ed7cd976d9 --- /dev/null +++ b/Documentation/RelNotes/2.13.1.txt @@ -0,0 +1,114 @@ +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/Documentation/RelNotes/2.13.2.txt b/Documentation/RelNotes/2.13.2.txt new file mode 100644 index 0000000000..8c2b20071e --- /dev/null +++ b/Documentation/RelNotes/2.13.2.txt @@ -0,0 +1,54 @@ +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/Documentation/RelNotes/2.13.3.txt b/Documentation/RelNotes/2.13.3.txt new file mode 100644 index 0000000000..384e4de265 --- /dev/null +++ b/Documentation/RelNotes/2.13.3.txt @@ -0,0 +1,62 @@ +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 + unnecessarily 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 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. + + * 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/Documentation/RelNotes/2.13.4.txt b/Documentation/RelNotes/2.13.4.txt new file mode 100644 index 0000000000..9a9f8f9599 --- /dev/null +++ b/Documentation/RelNotes/2.13.4.txt @@ -0,0 +1,28 @@ +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/Documentation/RelNotes/2.13.5.txt b/Documentation/RelNotes/2.13.5.txt new file mode 100644 index 0000000000..6949fcda78 --- /dev/null +++ b/Documentation/RelNotes/2.13.5.txt @@ -0,0 +1,4 @@ +Git v2.13.5 Release Notes +========================= + +This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/Documentation/RelNotes/2.13.6.txt b/Documentation/RelNotes/2.13.6.txt new file mode 100644 index 0000000000..afcae9c808 --- /dev/null +++ b/Documentation/RelNotes/2.13.6.txt @@ -0,0 +1,17 @@ +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/Documentation/RelNotes/2.13.7.txt b/Documentation/RelNotes/2.13.7.txt new file mode 100644 index 0000000000..09fc01406c --- /dev/null +++ b/Documentation/RelNotes/2.13.7.txt @@ -0,0 +1,20 @@ +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/Documentation/RelNotes/2.14.0.txt b/Documentation/RelNotes/2.14.0.txt new file mode 100644 index 0000000000..2711a2529d --- /dev/null +++ b/Documentation/RelNotes/2.14.0.txt @@ -0,0 +1,517 @@ +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 distinguish + 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 + unnecessarily 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/Documentation/RelNotes/2.14.1.txt b/Documentation/RelNotes/2.14.1.txt new file mode 100644 index 0000000000..9403340f7f --- /dev/null +++ b/Documentation/RelNotes/2.14.1.txt @@ -0,0 +1,4 @@ +Git v2.14.1 Release Notes +========================= + +This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/Documentation/RelNotes/2.14.2.txt b/Documentation/RelNotes/2.14.2.txt new file mode 100644 index 0000000000..bec9186ade --- /dev/null +++ b/Documentation/RelNotes/2.14.2.txt @@ -0,0 +1,105 @@ +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/Documentation/RelNotes/2.14.3.txt b/Documentation/RelNotes/2.14.3.txt new file mode 100644 index 0000000000..977c9e857c --- /dev/null +++ b/Documentation/RelNotes/2.14.3.txt @@ -0,0 +1,99 @@ +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/Documentation/RelNotes/2.14.4.txt b/Documentation/RelNotes/2.14.4.txt new file mode 100644 index 0000000000..97755a89d9 --- /dev/null +++ b/Documentation/RelNotes/2.14.4.txt @@ -0,0 +1,5 @@ +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/Documentation/RelNotes/2.14.5.txt b/Documentation/RelNotes/2.14.5.txt new file mode 100644 index 0000000000..130645fb29 --- /dev/null +++ b/Documentation/RelNotes/2.14.5.txt @@ -0,0 +1,16 @@ +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/Documentation/RelNotes/2.14.6.txt b/Documentation/RelNotes/2.14.6.txt new file mode 100644 index 0000000000..72b7af6799 --- /dev/null +++ b/Documentation/RelNotes/2.14.6.txt @@ -0,0 +1,54 @@ +Git v2.14.6 Release Notes +========================= + +This release addresses the security issues CVE-2019-1348, +CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, +CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387. + +Fixes since v2.14.5 +------------------- + + * CVE-2019-1348: + The --export-marks option of git fast-import is exposed also via + the in-stream command feature export-marks=... and it allows + overwriting arbitrary paths. + + * CVE-2019-1349: + When submodules are cloned recursively, under certain circumstances + Git could be fooled into using the same Git directory twice. We now + require the directory to be empty. + + * CVE-2019-1350: + Incorrect quoting of command-line arguments allowed remote code + execution during a recursive clone in conjunction with SSH URLs. + + * CVE-2019-1351: + While the only permitted drive letters for physical drives on + Windows are letters of the US-English alphabet, this restriction + does not apply to virtual drives assigned via subst <letter>: + <path>. Git mistook such paths for relative paths, allowing writing + outside of the worktree while cloning. + + * CVE-2019-1352: + Git was unaware of NTFS Alternate Data Streams, allowing files + inside the .git/ directory to be overwritten during a clone. + + * CVE-2019-1353: + When running Git in the Windows Subsystem for Linux (also known as + "WSL") while accessing a working directory on a regular Windows + drive, none of the NTFS protections were active. + + * CVE-2019-1354: + Filenames on Linux/Unix can contain backslashes. On Windows, + backslashes are directory separators. Git did not use to refuse to + write out tracked files with such filenames. + + * CVE-2019-1387: + Recursive clones are currently affected by a vulnerability that is + caused by too-lax validation of submodule names, allowing very + targeted attacks via remote code execution in recursive clones. + +Credit for finding these vulnerabilities goes to Microsoft Security +Response Center, in particular to Nicolas Joly. The `fast-import` +fixes were provided by Jeff King, the other fixes by Johannes +Schindelin with help from Garima Singh. diff --git a/Documentation/RelNotes/2.15.0.txt b/Documentation/RelNotes/2.15.0.txt new file mode 100644 index 0000000000..cdd761bcc2 --- /dev/null +++ b/Documentation/RelNotes/2.15.0.txt @@ -0,0 +1,508 @@ +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/Documentation/RelNotes/2.15.1.txt b/Documentation/RelNotes/2.15.1.txt new file mode 100644 index 0000000000..ec06704e63 --- /dev/null +++ b/Documentation/RelNotes/2.15.1.txt @@ -0,0 +1,88 @@ +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/Documentation/RelNotes/2.15.2.txt b/Documentation/RelNotes/2.15.2.txt new file mode 100644 index 0000000000..b480e56b68 --- /dev/null +++ b/Documentation/RelNotes/2.15.2.txt @@ -0,0 +1,50 @@ +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/Documentation/RelNotes/2.15.3.txt b/Documentation/RelNotes/2.15.3.txt new file mode 100644 index 0000000000..fd2e6f8df7 --- /dev/null +++ b/Documentation/RelNotes/2.15.3.txt @@ -0,0 +1,6 @@ +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/Documentation/RelNotes/2.15.4.txt b/Documentation/RelNotes/2.15.4.txt new file mode 100644 index 0000000000..dc241cba34 --- /dev/null +++ b/Documentation/RelNotes/2.15.4.txt @@ -0,0 +1,11 @@ +Git v2.15.4 Release Notes +========================= + +This release merges up the fixes that appear in v2.14.6 to address +the security issues CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, +CVE-2019-1351, CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, and +CVE-2019-1387; see the release notes for that version for details. + +In conjunction with a vulnerability that was fixed in v2.20.2, +`.gitmodules` is no longer allowed to contain entries of the form +`submodule.<name>.update=!command`. diff --git a/Documentation/RelNotes/2.16.0.txt b/Documentation/RelNotes/2.16.0.txt new file mode 100644 index 0000000000..b474781ed8 --- /dev/null +++ b/Documentation/RelNotes/2.16.0.txt @@ -0,0 +1,482 @@ +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 encoding 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/Documentation/RelNotes/2.16.1.txt b/Documentation/RelNotes/2.16.1.txt new file mode 100644 index 0000000000..66e64361fd --- /dev/null +++ b/Documentation/RelNotes/2.16.1.txt @@ -0,0 +1,11 @@ +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/Documentation/RelNotes/2.16.2.txt b/Documentation/RelNotes/2.16.2.txt new file mode 100644 index 0000000000..a216466d3d --- /dev/null +++ b/Documentation/RelNotes/2.16.2.txt @@ -0,0 +1,30 @@ +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/Documentation/RelNotes/2.16.3.txt b/Documentation/RelNotes/2.16.3.txt new file mode 100644 index 0000000000..f0121a8f2d --- /dev/null +++ b/Documentation/RelNotes/2.16.3.txt @@ -0,0 +1,49 @@ +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 shareable. + + * 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/Documentation/RelNotes/2.16.4.txt b/Documentation/RelNotes/2.16.4.txt new file mode 100644 index 0000000000..6be538ba30 --- /dev/null +++ b/Documentation/RelNotes/2.16.4.txt @@ -0,0 +1,5 @@ +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/Documentation/RelNotes/2.16.5.txt b/Documentation/RelNotes/2.16.5.txt new file mode 100644 index 0000000000..cb8ee02a9a --- /dev/null +++ b/Documentation/RelNotes/2.16.5.txt @@ -0,0 +1,6 @@ +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/Documentation/RelNotes/2.16.6.txt b/Documentation/RelNotes/2.16.6.txt new file mode 100644 index 0000000000..438306e60b --- /dev/null +++ b/Documentation/RelNotes/2.16.6.txt @@ -0,0 +1,8 @@ +Git v2.16.6 Release Notes +========================= + +This release merges up the fixes that appear in v2.14.6 and in +v2.15.4 addressing the security issues CVE-2019-1348, CVE-2019-1349, +CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, CVE-2019-1353, +CVE-2019-1354, and CVE-2019-1387; see the release notes for those +versions for details. diff --git a/Documentation/RelNotes/2.17.0.txt b/Documentation/RelNotes/2.17.0.txt new file mode 100644 index 0000000000..8b17c26033 --- /dev/null +++ b/Documentation/RelNotes/2.17.0.txt @@ -0,0 +1,398 @@ +Git 2.17 Release Notes +====================== + +Updates since v2.16 +------------------- + +UI, Workflows & Features + + * "diff" family of commands learned "--find-object=<object-id>" option + to limit the findings to changes that involve the named object. + + * "git format-patch" learned to give 72-cols to diffstat, which is + consistent with other line length limits the subcommand uses for + its output meant for e-mails. + + * The log from "git daemon" can be redirected with a new option; one + relevant use case is to send the log to standard error (instead of + syslog) when running it from inetd. + + * "git rebase" learned to take "--allow-empty-message" option. + + * "git am" has learned the "--quit" option, in addition to the + existing "--abort" option; having the pair mirrors a few other + commands like "rebase" and "cherry-pick". + + * "git worktree add" learned to run the post-checkout hook, just like + "git clone" runs it upon the initial checkout. + + * "git tag" learned an explicit "--edit" option that allows the + message given via "-m" and "-F" to be further edited. + + * "git fetch --prune-tags" may be used as a handy short-hand for + getting rid of stale tags that are locally held. + + * The new "--show-current-patch" option gives an end-user facing way + to get the diff being applied when "git rebase" (and "git am") + stops with a conflict. + + * "git add -p" used to offer "/" (look for a matching hunk) as a + choice, even there was only one hunk, which has been corrected. + Also the single-key help is now given only for keys that are + enabled (e.g. help for '/' won't be shown when there is only one + hunk). + + * Since Git 1.7.9, "git merge" defaulted to --no-ff (i.e. even when + the side branch being merged is a descendant of the current commit, + create a merge commit instead of fast-forwarding) when merging a + tag object. This was appropriate default for integrators who pull + signed tags from their downstream contributors, but caused an + unnecessary merges when used by downstream contributors who + habitually "catch up" their topic branches with tagged releases + from the upstream. Update "git merge" to default to --no-ff only + when merging a tag object that does *not* sit at its usual place in + refs/tags/ hierarchy, and allow fast-forwarding otherwise, to + mitigate the problem. + + * "git status" can spend a lot of cycles to compute the relation + between the current branch and its upstream, which can now be + disabled with "--no-ahead-behind" option. + + * "git diff" and friends learned funcname patterns for Go language + source files. + + * "git send-email" learned "--reply-to=<address>" option. + + * Funcname pattern used for C# now recognizes "async" keyword. + + * In a way similar to how "git tag" learned to honor the pager + setting only in the list mode, "git config" learned to ignore the + pager setting when it is used for setting values (i.e. when the + purpose of the operation is not to "show"). + + +Performance, Internal Implementation, Development Support etc. + + * More perf tests for threaded grep + + * "perf" test output can be sent to codespeed server. + + * The build procedure for perl/ part has been greatly simplified by + weaning ourselves off of MakeMaker. + + * Perl 5.8 or greater has been required since Git 1.7.4 released in + 2010, but we continued to assume some core modules may not exist and + used a conditional "eval { require <<module>> }"; we no longer do + this. Some platforms (Fedora/RedHat/CentOS, for example) ship Perl + without all core modules by default (e.g. Digest::MD5, File::Temp, + File::Spec, Net::Domain, Net::SMTP). Users on such platforms may + need to install these additional modules. + + * As a convenience, we install copies of Perl modules we require which + are not part of the core Perl distribution (e.g. Error and + Mail::Address). Users and packagers whose operating system provides + these modules can set NO_PERL_CPAN_FALLBACKS to avoid installing the + bundled modules. + + * In preparation for implementing narrow/partial clone, the machinery + for checking object connectivity used by gc and fsck has been + taught that a missing object is OK when it is referenced by a + packfile specially marked as coming from trusted repository that + promises to make them available on-demand and lazily. + + * The machinery to clone & fetch, which in turn involves packing and + unpacking objects, has been told how to omit certain objects using + the filtering mechanism introduced by another topic. It now knows + to mark the resulting pack as a promisor pack to tolerate missing + objects, laying foundation for "narrow" clones. + + * The first step to getting rid of mru API and using the + doubly-linked list API directly instead. + + * Retire mru API as it does not give enough abstraction over + underlying list API to be worth it. + + * Rewrite two more "git submodule" subcommands in C. + + * The tracing machinery learned to report tweaking of environment + variables as well. + + * Update Coccinelle rules to catch and optimize strbuf_addf(&buf, "%s", str) + + * Prevent "clang-format" from breaking line after function return type. + + * The sequencer infrastructure is shared across "git cherry-pick", + "git rebase -i", etc., and has always spawned "git commit" when it + needs to create a commit. It has been taught to do so internally, + when able, by reusing the codepath "git commit" itself uses, which + gives performance boost for a few tens of percents in some sample + scenarios. + + * Push the submodule version of collision-detecting SHA-1 hash + implementation a bit harder on builders. + + * Avoid mmapping small files while using packed refs (especially ones + with zero size, which would cause later munmap() to fail). + + * Conversion from uchar[20] to struct object_id continues. + + * More tests for wildmatch functions. + + * The code to binary search starting from a fan-out table (which is + how the packfile is indexed with object names) has been refactored + into a reusable helper. + + * We now avoid using identifiers that clash with C++ keywords. Even + though it is not a goal to compile Git with C++ compilers, changes + like this help use of code analysis tools that targets C++ on our + codebase. + + * The executable is now built in 'script' phase in Travis CI integration, + to follow the established practice, rather than during 'before_script' + phase. This allows the CI categorize the failures better ('failed' + is project's fault, 'errored' is build environment's). + (merge 3c93b82920 sg/travis-build-during-script-phase later to maint). + + * Writing out the index file when the only thing that changed in it + is the untracked cache information is often wasteful, and this has + been optimized out. + + * Various pieces of Perl code we have have been cleaned up. + + * Internal API clean-up to allow write_locked_index() optionally skip + writing the in-core index when it is not modified. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.16 +----------------- + + * An old regression in "git describe --all $annotated_tag^0" has been + fixed. + + * "git status" after moving a path in the working tree (hence making + it appear "removed") and then adding with the -N option (hence + making that appear "added") detected it as a rename, but did not + report the old and new pathnames correctly. + + * "git svn dcommit" did not take into account the fact that a + svn+ssh:// URL with a username@ (typically used for pushing) refers + to the same SVN repository without the username@ and failed when + svn.pushmergeinfo option is set. + + * API clean-up around revision traversal. + + * "git merge -Xours/-Xtheirs" learned to use our/their version when + resolving a conflicting updates to a symbolic link. + + * "git clone $there $here" is allowed even when here directory exists + as long as it is an empty directory, but the command incorrectly + removed it upon a failure of the operation. + + * "git commit --fixup" did not allow "-m<message>" option to be used + at the same time; allow it to annotate resulting commit with more + text. + + * When resetting the working tree files recursively, the working tree + of submodules are now also reset to match. + + * "git stash -- <pathspec>" incorrectly blew away untracked files in + the directory that matched the pathspec, which has been corrected. + + * Instead of maintaining home-grown email address parsing code, ship + a copy of reasonably recent Mail::Address to be used as a fallback + in 'git send-email' when the platform lacks it. + (merge d60be8acab mm/send-email-fallback-to-local-mail-address later to maint). + + * "git add -p" was taught to ignore local changes to submodules as + they do not interfere with the partial addition of regular changes + anyway. + + * Avoid showing a warning message in the middle of a line of "git + diff" output. + (merge 4e056c989f nd/diff-flush-before-warning later to maint). + + * The http tracing code, often used to debug connection issues, + learned to redact potentially sensitive information from its output + so that it can be more safely shareable. + (merge 8ba18e6fa4 jt/http-redact-cookies later to maint). + + * Crash fix for a corner case where an error codepath tried to unlock + what it did not acquire lock on. + (merge 81fcb698e0 mr/packed-ref-store-fix later to maint). + + * The split-index mode had a few corner case bugs fixed. + (merge ae59a4e44f tg/split-index-fixes later to maint). + + * Assorted fixes to "git daemon". + (merge ed15e58efe jk/daemon-fixes later to maint). + + * Completion of "git merge -s<strategy>" (in contrib/) did not work + well in non-C locale. + (merge 7cc763aaa3 nd/list-merge-strategy later to maint). + + * Workaround for segfault with more recent versions of SVN. + (merge 7f6f75e97a ew/svn-branch-segfault-fix later to maint). + + * Plug recently introduced leaks in fsck. + (merge ba3a08ca0e jt/fsck-code-cleanup later to maint). + + * "git pull --rebase" did not pass verbosity setting down when + recursing into a submodule. + (merge a56771a668 sb/pull-rebase-submodule later to maint). + + * The way "git reset --hard" reports the commit the updated HEAD + points at is made consistent with the way how the commit title is + generated by the other parts of the system. This matters when the + title is spread across physically multiple lines. + (merge 1cf823fb68 tg/reset-hard-show-head-with-pretty later to maint). + + * Test fixes. + (merge 63b1a175ee sg/test-i18ngrep later to maint). + + * Some bugs around "untracked cache" feature have been fixed. This + will notice corrupt data in the untracked cache left by old and + buggy code and issue a warning---the index can be fixed by clearing + the untracked cache from it. + (merge 0cacebf099 nd/fix-untracked-cache-invalidation later to maint). + (merge 7bf0be7501 ab/untracked-cache-invalidation-docs later to maint). + + * "git blame HEAD COPYING" in a bare repository failed to run, while + "git blame HEAD -- COPYING" run just fine. This has been corrected. + + * "git add" files in the same directory, but spelling the directory + path in different cases on case insensitive filesystem, corrupted + the name hash data structure and led to unexpected results. This + has been corrected. + (merge c95525e90d bp/name-hash-dirname-fix later to maint). + + * "git rebase -p" mangled log messages of a merge commit, which is + now fixed. + (merge ed5144d7eb js/fix-merge-arg-quoting-in-rebase-p later to maint). + + * Some low level protocol codepath could crash when they get an + unexpected flush packet, which is now fixed. + (merge bb1356dc64 js/packet-read-line-check-null later to maint). + + * "git check-ignore" with multiple paths got confused when one is a + file and the other is a directory, which has been fixed. + (merge d60771e930 rs/check-ignore-multi later to maint). + + * "git describe $garbage" stopped giving any errors when the garbage + happens to be a string with 40 hexadecimal letters. + (merge a8e7a2bf0f sb/describe-blob later to maint). + + * Code to unquote single-quoted string (used in the parser for + configuration files, etc.) did not diagnose bogus input correctly + and produced bogus results instead. + (merge ddbbf8eb25 jk/sq-dequote-on-bogus-input later to maint). + + * Many places in "git apply" knew that "/dev/null" that signals + "there is no such file on this side of the diff" can be followed by + whitespace and garbage when parsing a patch, except for one, which + made an otherwise valid patch (e.g. ones from subversion) rejected. + (merge e454ad4bec tk/apply-dev-null-verify-name-fix later to maint). + + * We no longer create any *.spec file, so "make clean" should not + remove it. + (merge 4321bdcabb tz/do-not-clean-spec-file later to maint). + + * "git push" over http transport did not unquote the push-options + correctly. + (merge 90dce21eb0 jk/push-options-via-transport-fix later to maint). + + * "git send-email" learned to complain when the batch-size option is + not defined when the relogin-delay option is, since these two are + mutually required. + (merge 9caa70697b xz/send-email-batch-size later to maint). + + * Y2k20 fix ;-) for our perl scripts. + (merge a40e06ee33 bw/perl-timegm-timelocal-fix later to maint). + + * Threaded "git grep" has been optimized to avoid allocation in code + section that is covered under a mutex. + (merge 38ef24dccf rv/grep-cleanup later to maint). + + * "git subtree" script (in contrib/) scripted around "git log", whose + output got affected by end-user configuration like log.showsignature + (merge 8841b5222c sg/subtree-signed-commits later to maint). + + * While finding unique object name abbreviation, the code may + accidentally have read beyond the end of the array of object names + in a pack. + (merge 21abed500c ds/find-unique-abbrev-optim later to maint). + + * Micro optimization in revision traversal code. + (merge ebbed3ba04 ds/mark-parents-uninteresting-optim later to maint). + + * "git commit" used to run "gc --auto" near the end, which was lost + when the command was reimplemented in C by mistake. + (merge 095c741edd ab/gc-auto-in-commit later to maint). + + * Allow running a couple of tests with "sh -x". + (merge c20bf94abc sg/cvs-tests-with-x later to maint). + + * The codepath to replace an existing entry in the index had a bug in + updating the name hash structure, which has been fixed. + (merge 0e267b7a24 bp/refresh-cache-ent-rehash-fix later to maint). + + * The transfer.fsckobjects configuration tells "git fetch" to + validate the data and connected-ness of objects in the received + pack; the code to perform this check has been taught about the + narrow clone's convention that missing objects that are reachable + from objects in a pack that came from a promisor remote is OK. + + * There was an unused file-scope static variable left in http.c when + building for versions of libCURL that is older than 7.19.4, which + has been fixed. + (merge b8fd6008ec rj/http-code-cleanup later to maint). + + * Shell script portability fix. + (merge 206a6ae013 ml/filter-branch-portability-fix later to maint). + + * Other minor doc, test and build updates and code cleanups. + (merge e2a5a028c7 bw/oidmap-autoinit later to maint). + (merge ec3b4b06f8 cl/t9001-cleanup later to maint). + (merge e1b3f3dd38 ks/submodule-doc-updates later to maint). + (merge fbac558a9b rs/describe-unique-abbrev later to maint). + (merge 8462ff43e4 tb/crlf-conv-flags later to maint). + (merge 7d68bb0766 rb/hashmap-h-compilation-fix later to maint). + (merge 3449847168 cc/sha1-file-name later to maint). + (merge ad622a256f ds/use-get-be64 later to maint). + (merge f919ffebed sg/cocci-move-array later to maint). + (merge 4e801463c7 jc/mailinfo-cleanup-fix later to maint). + (merge ef5b3a6c5e nd/shared-index-fix later to maint). + (merge 9f5258cbb8 tz/doc-show-defaults-to-head later to maint). + (merge b780e4407d jc/worktree-add-short-help later to maint). + (merge ae239fc8e5 rs/cocci-strbuf-addf-to-addstr later to maint). + (merge 2e22a85e5c nd/ignore-glob-doc-update later to maint). + (merge 3738031581 jk/gettext-poison later to maint). + (merge 54360a1956 rj/sparse-updates later to maint). + (merge 12e31a6b12 sg/doc-test-must-fail-args later to maint). + (merge 760f1ad101 bc/doc-interpret-trailers-grammofix later to maint). + (merge 4ccf461f56 bp/fsmonitor later to maint). + (merge a6119f82b1 jk/test-hashmap-updates later to maint). + (merge 5aea9fe6cc rd/typofix later to maint). + (merge e4e5da2796 sb/status-doc-fix later to maint). + (merge 7976e901c8 gs/test-unset-xdg-cache-home later to maint). + (merge d023df1ee6 tg/worktree-create-tracking later to maint). + (merge 4cbe92fd41 sm/mv-dry-run-update later to maint). + (merge 75e5e9c3f7 sb/color-h-cleanup later to maint). + (merge 2708ef4af6 sg/t6300-modernize later to maint). + (merge d88e92d4e0 bw/doc-submodule-recurse-config-with-clone later to maint). + (merge f74bbc8dd2 jk/cached-commit-buffer later to maint). + (merge 1316416903 ms/non-ascii-ticks later to maint). + (merge 878056005e rs/strbuf-read-file-or-whine later to maint). + (merge 79f0ba1547 jk/strbuf-read-file-close-error later to maint). + (merge edfb8ba068 ot/ref-filter-cleanup later to maint). + (merge 11395a3b4b jc/test-must-be-empty later to maint). + (merge 768b9d6db7 mk/doc-pretty-fill later to maint). + (merge 2caa7b8d27 ab/man-sec-list later to maint). + (merge 40c17eb184 ks/t3200-typofix later to maint). + (merge bd9958c358 dp/merge-strategy-doc-fix later to maint). + (merge 9ee0540a40 js/ming-strftime later to maint). + (merge 1775e990f7 tz/complete-tag-delete-tagname later to maint). + (merge 00a4b03501 rj/warning-uninitialized-fix later to maint). + (merge b635ed97a0 jk/attributes-path-doc later to maint). diff --git a/Documentation/RelNotes/2.17.1.txt b/Documentation/RelNotes/2.17.1.txt new file mode 100644 index 0000000000..e01384fe8e --- /dev/null +++ b/Documentation/RelNotes/2.17.1.txt @@ -0,0 +1,16 @@ +Git v2.17.1 Release Notes +========================= + +Fixes since v2.17 +----------------- + + * This release contains the same fixes made in the v2.13.7 version of + Git, covering CVE-2018-11233 and 11235, and forward-ported to + v2.14.4, v2.15.2 and v2.16.4 releases. See release notes to + v2.13.7 for details. + + * In addition to the above fixes, this release has support on the + server side to reject pushes to repositories that attempt to create + such problematic .gitmodules file etc. as tracked contents, to help + hosting sites protect their customers by preventing malicious + contents from spreading. diff --git a/Documentation/RelNotes/2.17.2.txt b/Documentation/RelNotes/2.17.2.txt new file mode 100644 index 0000000000..ef021be870 --- /dev/null +++ b/Documentation/RelNotes/2.17.2.txt @@ -0,0 +1,12 @@ +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/Documentation/RelNotes/2.17.3.txt b/Documentation/RelNotes/2.17.3.txt new file mode 100644 index 0000000000..5a46c94271 --- /dev/null +++ b/Documentation/RelNotes/2.17.3.txt @@ -0,0 +1,12 @@ +Git v2.17.3 Release Notes +========================= + +This release merges up the fixes that appear in v2.14.6 and in +v2.15.4 addressing the security issues CVE-2019-1348, CVE-2019-1349, +CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, CVE-2019-1353, +CVE-2019-1354, and CVE-2019-1387; see the release notes for those +versions for details. + +In addition, `git fsck` was taught to identify `.gitmodules` entries +of the form `submodule.<name>.update=!command`, which have been +disallowed in v2.15.4. diff --git a/Documentation/RelNotes/2.17.4.txt b/Documentation/RelNotes/2.17.4.txt new file mode 100644 index 0000000000..7d794ca01a --- /dev/null +++ b/Documentation/RelNotes/2.17.4.txt @@ -0,0 +1,16 @@ +Git v2.17.4 Release Notes +========================= + +This release is to address the security issue: CVE-2020-5260 + +Fixes since v2.17.3 +------------------- + + * With a crafted URL that contains a newline in it, the credential + helper machinery can be fooled to give credential information for + a wrong host. The attack has been made impossible by forbidding + a newline character in any value passed via the credential + protocol. + +Credit for finding the vulnerability goes to Felix Wilhelm of Google +Project Zero. diff --git a/Documentation/RelNotes/2.17.5.txt b/Documentation/RelNotes/2.17.5.txt new file mode 100644 index 0000000000..2abb821a73 --- /dev/null +++ b/Documentation/RelNotes/2.17.5.txt @@ -0,0 +1,22 @@ +Git v2.17.5 Release Notes +========================= + +This release is to address a security issue: CVE-2020-11008 + +Fixes since v2.17.4 +------------------- + + * With a crafted URL that contains a newline or empty host, or lacks + a scheme, the credential helper machinery can be fooled into + providing credential information that is not appropriate for the + protocol in use and host being contacted. + + Unlike the vulnerability CVE-2020-5260 fixed in v2.17.4, the + credentials are not for a host of the attacker's choosing; instead, + they are for some unspecified host (based on how the configured + credential helper handles an absent "host" parameter). + + The attack has been made impossible by refusing to work with + under-specified credential patterns. + +Credit for finding the vulnerability goes to Carlo Arenas. diff --git a/Documentation/RelNotes/2.18.0.txt b/Documentation/RelNotes/2.18.0.txt new file mode 100644 index 0000000000..6c8a0e97c1 --- /dev/null +++ b/Documentation/RelNotes/2.18.0.txt @@ -0,0 +1,583 @@ +Git 2.18 Release Notes +====================== + +Updates since v2.17 +------------------- + +UI, Workflows & Features + + * Rename detection logic that is used in "merge" and "cherry-pick" has + learned to guess when all of x/a, x/b and x/c have moved to z/a, + z/b and z/c, it is likely that x/d added in the meantime would also + want to move to z/d by taking the hint that the entire directory + 'x' moved to 'z'. A bug causing dirty files involved in a rename + to be overwritten during merge has also been fixed as part of this + work. Incidentally, this also avoids updating a file in the + working tree after a (non-trivial) merge whose result matches what + our side originally had. + + * "git filter-branch" learned to use a different exit code to allow + the callers to tell the case where there was no new commits to + rewrite from other error cases. + + * When built with more recent cURL, GIT_SSL_VERSION can now specify + "tlsv1.3" as its value. + + * "git gui" learned that "~/.ssh/id_ecdsa.pub" and + "~/.ssh/id_ed25519.pub" are also possible SSH key files. + (merge 2e2f0288ef bb/git-gui-ssh-key-files later to maint). + + * "git gui" performs commit upon CTRL/CMD+ENTER but the + CTRL/CMD+KP_ENTER (i.e. enter key on the numpad) did not have the + same key binding. It now does. + (merge 28a1d94a06 bp/git-gui-bind-kp-enter later to maint). + + * "git gui" has been taught to work with old versions of tk (like + 8.5.7) that do not support "ttk::style theme use" as a way to query + the current theme. + (merge 4891961105 cb/git-gui-ttk-style later to maint). + + * "git rebase" has learned to honor "--signoff" option when using + backends other than "am" (but not "--preserve-merges"). + + * "git branch --list" during an interrupted "rebase -i" now lets + users distinguish the case where a detached HEAD is being rebased + and a normal branch is being rebased. + + * "git mergetools" learned talking to guiffy. + + * The scripts in contrib/emacs/ have outlived their usefulness and + have been replaced with a stub that errors out and tells the user + there are replacements. + + * The new "working-tree-encoding" attribute can ask Git to convert the + contents to the specified encoding when checking out to the working + tree (and the other way around when checking in). + + * The "git config" command uses separate options e.g. "--int", + "--bool", etc. to specify what type the caller wants the value to + be interpreted as. A new "--type=<typename>" option has been + introduced, which would make it cleaner to define new types. + + * "git config --get" learned the "--default" option, to help the + calling script. Building on top of the above changes, the + "git config" learns "--type=color" type. Taken together, you can + do things like "git config --get foo.color --default blue" and get + the ANSI color sequence for the color given to foo.color variable, + or "blue" if the variable does not exist. + + * "git ls-remote" learned an option to allow sorting its output based + on the refnames being shown. + + * The command line completion (in contrib/) has been taught that "git + stash save" has been deprecated ("git stash push" is the preferred + spelling in the new world) and does not offer it as a possible + completion candidate when "git stash push" can be. + + * "git gc --prune=nonsense" spent long time repacking and then + silently failed when underlying "git prune --expire=nonsense" + failed to parse its command line. This has been corrected. + + * Error messages from "git push" can be painted for more visibility. + + * "git http-fetch" (deprecated) had an optional and experimental + "feature" to fetch only commits and/or trees, which nobody used. + This has been removed. + + * The functionality of "$GIT_DIR/info/grafts" has been superseded by + the "refs/replace/" mechanism for some time now, but the internal + code had support for it in many places, which has been cleaned up + in order to drop support of the "grafts" mechanism. + + * "git worktree add" learned to check out an existing branch. + + * "git --no-pager cmd" did not have short-and-sweet single letter + option. Now it does as "-P". + (merge 7213c28818 js/no-pager-shorthand later to maint). + + * "git rebase" learned "--rebase-merges" to transplant the whole + topology of commit graph elsewhere. + + * "git status" learned to pay attention to UI related diff + configuration variables such as diff.renames. + + * The command line completion mechanism (in contrib/) learned to load + custom completion file for "git $command" where $command is a + custom "git-$command" that the end user has on the $PATH when using + newer version of bash-completion. + + * "git send-email" can sometimes offer confirmation dialog "Send this + email?" with choices 'Yes', 'No', 'Quit', and 'All'. A new action + 'Edit' has been added to this dialog's choice. + + * With merge.renames configuration set to false, the recursive merge + strategy can be told not to spend cycles trying to find renamed + paths and merge them accordingly. + + * "git status" learned to honor a new status.renames configuration to + skip rename detection, which could be useful for those who want to + do so without disabling the default rename detection done by the + "git diff" command. + + * Command line completion (in contrib/) learned to complete pathnames + for various commands better. + + * "git blame" learns to unhighlight uninteresting metadata from the + originating commit on lines that are the same as the previous one, + and also paint lines in different colors depending on the age of + the commit. + + * Transfer protocol v2 learned to support the partial clone. + + * When a short hexadecimal string is used to name an object but there + are multiple objects that share the string as the prefix of their + names, the code lists these ambiguous candidates in a help message. + These object names are now sorted according to their types for + easier eyeballing. + + * "git fetch $there $refspec" that talks over protocol v2 can take + advantage of server-side ref filtering; the code has been extended + so that this mechanism triggers also when fetching with configured + refspec. + + * Our HTTP client code used to advertise that we accept gzip encoding + from the other side; instead, just let cURL library to advertise + and negotiate the best one. + + * "git p4" learned to "unshelve" shelved commit from P4. + (merge 123f631761 ld/p4-unshelve later to maint). + + +Performance, Internal Implementation, Development Support etc. + + * A "git fetch" from a repository with insane number of refs into a + repository that is already up-to-date still wasted too many cycles + making many lstat(2) calls to see if these objects at the tips + exist as loose objects locally. These lstat(2) calls are optimized + away by enumerating all loose objects beforehand. + It is unknown if the new strategy negatively affects existing use + cases, fetching into a repository with many loose objects from a + repository with small number of refs. + + * Git can be built to use either v1 or v2 of the PCRE library, and so + far, the build-time configuration USE_LIBPCRE=YesPlease instructed + the build procedure to use v1, but now it means v2. USE_LIBPCRE1 + and USE_LIBPCRE2 can be used to explicitly choose which version to + use, as before. + + * The build procedure learned to optionally use symbolic links + (instead of hardlinks and copies) to install "git-foo" for built-in + commands, whose binaries are all identical. + + * Conversion from uchar[20] to struct object_id continues. + + * The way "git worktree prune" worked internally has been simplified, + by assuming how "git worktree move" moves an existing worktree to a + different place. + + * Code clean-up for the "repository" abstraction. + (merge 00a3da2a13 nd/remove-ignore-env-field later to maint). + + * Code to find the length to uniquely abbreviate object names based + on packfile content, which is a relatively recent addition, has been + optimized to use the same fan-out table. + + * The mechanism to use parse-options API to automate the command line + completion continues to get extended and polished. + + * Copies of old scripted Porcelain commands in contrib/examples/ have + been removed. + + * Some tests that rely on the exact hardcoded values of object names + have been updated in preparation for hash function migration. + + * Perf-test update. + + * Test helper update. + + * The effort continues to refactor the internal global data structure + to make it possible to open multiple repositories, work with and + then close them, + + * Small test-helper programs have been consolidated into a single + binary. + + * API clean-up around ref-filter code. + + * Shell completion (in contrib) that gives list of paths have been + optimized somewhat. + + * The index file is updated to record the fsmonitor section after a + full scan was made, to avoid wasting the effort that has already + spent. + + * Performance measuring framework in t/perf learned to help bisecting + performance regressions. + + * Some multi-word source filenames are being renamed to separate + words with dashes instead of underscores. + + * An reusable "memory pool" implementation has been extracted from + fast-import.c, which in turn has become the first user of the + mem-pool API. + + * A build-time option has been added to allow Git to be told to refer + to its associated files relative to the main binary, in the same + way that has been possible on Windows for quite some time, for + Linux, BSDs and Darwin. + + * Precompute and store information necessary for ancestry traversal + in a separate file to optimize graph walking. + + * The effort to pass the repository in-core structure throughout the + API continues. This round deals with the code that implements the + refs/replace/ mechanism. + + * The build procedure "make DEVELOPER=YesPlease" learned to enable a + bit more warning options depending on the compiler used to help + developers more. There also is "make DEVOPTS=tokens" knob + available now, for those who want to help fixing warnings we + usually ignore, for example. + + * A new version of the transport protocol is being worked on. + + * The code to interface to GPG has been restructured somewhat to make + it cleaner to integrate with other types of signature systems later. + + * The code has been taught to use the duplicated information stored + in the commit-graph file to learn the tree object name for a commit + to avoid opening and parsing the commit object when it makes sense + to do so. + + * "git gc" in a large repository takes a lot of time as it considers + to repack all objects into one pack by default. The command has + been taught to pretend as if the largest existing packfile is + marked with ".keep" so that it is left untouched while objects in + other packs and loose ones are repacked. + + * The transport protocol v2 is getting updated further. + + * The codepath around object-info API has been taught to take the + repository object (which in turn tells the API which object store + the objects are to be located). + + * "git pack-objects" needs to allocate tons of "struct object_entry" + while doing its work, and shrinking its size helps the performance + quite a bit. + + * The implementation of "git rebase -i --root" has been updated to use + the sequencer machinery more. + + * Developer support update, by using BUG() macro instead of die() to + mark codepaths that should not happen more clearly. + + * Developer support. Use newer GCC on one of the builds done at + TravisCI.org to get more warnings and errors diagnosed. + + * Conversion from uchar[20] to struct object_id continues. + + * By code restructuring of submodule merge in merge-recursive, + informational messages from the codepath are now given using the + same mechanism as other output, and honor the merge.verbosity + configuration. The code also learned to give a few new messages + when a submodule three-way merge resolves cleanly when one side + records a descendant of the commit chosen by the other side. + + * Avoid unchecked snprintf() to make future code auditing easier. + (merge ac4896f007 jk/snprintf-truncation later to maint). + + * Many tests hardcode the raw object names, which would change once + we migrate away from SHA-1. While some of them must test against + exact object names, most of them do not have to use hardcoded + constants in the test. The latter kind of tests have been updated + to test the moral equivalent of the original without hardcoding the + actual object names. + + * The list of commands with their various attributes were spread + across a few places in the build procedure, but it now is getting a + bit more consolidated to allow more automation. + + * Quite a many tests assumed that newly created refs are made as + loose refs using the files backend, which have been updated to use + proper plumbing like rev-parse and update-ref, to avoid breakage + once we start using different ref backends. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.17 +----------------- + + * "git shortlog cruft" aborted with a BUG message when run outside a + Git repository. The command has been taught to complain about + extra and unwanted arguments on its command line instead in such a + case. + (merge 4aa0161e83 ma/shortlog-revparse later to maint). + + * "git stash push -u -- <pathspec>" gave an unnecessary and confusing + error message when there was no tracked files that match the + <pathspec>, which has been fixed. + (merge 353278687e tg/stash-untracked-with-pathspec-fix later to maint). + + * "git tag --contains no-such-commit" gave a full list of options + after giving an error message. + (merge 3bb0923f06 ps/contains-id-error-message later to maint). + + * "diff-highlight" filter (in contrib/) learned to understand "git log + --graph" output better. + (merge 4551fbba14 jk/diff-highlight-graph-fix later to maint). + + * when refs that do not point at committish are given, "git + filter-branch" gave a misleading error messages. This has been + corrected. + (merge f78ab355e7 yk/filter-branch-non-committish-refs later to maint). + + * "git submodule status" misbehaved on a submodule that has been + removed from the working tree. + (merge 74b6bda32f rs/status-with-removed-submodule later to maint). + + * When credential helper exits very quickly without reading its + input, it used to cause Git to die with SIGPIPE, which has been + fixed. + (merge a0d51e8d0e eb/cred-helper-ignore-sigpipe later to maint). + + * "git rebase --keep-empty" still removed an empty commit if the + other side contained an empty commit (due to the "does an + equivalent patch exist already?" check), which has been corrected. + (merge 3d946165e1 pw/rebase-keep-empty-fixes later to maint). + + * Some codepaths, including the refs API, get and keep relative + paths, that go out of sync when the process does chdir(2). The + chdir-notify API is introduced to let these codepaths adjust these + cached paths to the new current directory. + (merge fb9c2d2703 jk/relative-directory-fix later to maint). + + * "cd sub/dir && git commit ../path" ought to record the changes to + the file "sub/path", but this regressed long time ago. + (merge 86238e07ef bw/commit-partial-from-subdirectory-fix later to maint). + + * Recent introduction of "--log-destination" option to "git daemon" + did not work well when the daemon was run under "--inetd" mode. + (merge e67d906d73 lw/daemon-log-destination later to maint). + + * Small fix to the autoconf build procedure. + (merge 249482daf0 es/fread-reads-dir-autoconf-fix later to maint). + + * Fix an unexploitable (because the oversized contents are not under + attacker's control) buffer overflow. + (merge d8579accfa bp/fsmonitor-bufsize-fix later to maint). + + * Recent simplification of build procedure forgot a bit of tweak to + the build procedure of contrib/mw-to-git/ + (merge d8698987f3 ab/simplify-perl-makefile later to maint). + + * Moving a submodule that itself has submodule in it with "git mv" + forgot to make necessary adjustment to the nested sub-submodules; + now the codepath learned to recurse into the submodules. + + * "git config --unset a.b", when "a.b" is the last variable in an + otherwise empty section "a", left an empty section "a" behind, and + worse yet, a subsequent "git config a.c value" did not reuse that + empty shell and instead created a new one. These have been + (partially) corrected. + (merge c71d8bb38a js/empty-config-section-fix later to maint). + + * "git worktree remove" learned that "-f" is a shorthand for + "--force" option, just like for "git worktree add". + (merge d228eea514 sb/worktree-remove-opt-force later to maint). + + * The completion script (in contrib/) learned to clear cached list of + command line options upon dot-sourcing it again in a more efficient + way. + (merge 94408dc71c sg/completion-clear-cached later to maint). + + * "git svn" had a minor thinko/typo which has been fixed. + (merge 51db271587 ab/git-svn-get-record-typofix later to maint). + + * During a "rebase -i" session, the code could give older timestamp + to commits created by later "pick" than an earlier "reword", which + has been corrected. + (merge 12f7babd6b js/ident-date-fix later to maint). + + * "git submodule status" did not check the symbolic revision name it + computed for the submodule HEAD is not the NULL, and threw it at + printf routines, which has been corrected. + (merge 0b5e2ea7cf nd/submodule-status-fix later to maint). + + * When fed input that already has In-Reply-To: and/or References: + headers and told to add the same information, "git send-email" + added these headers separately, instead of appending to an existing + one, which is a violation of the RFC. This has been corrected. + (merge 256be1d3f0 sa/send-email-dedup-some-headers later to maint). + + * "git fast-export" had a regression in v2.15.0 era where it skipped + some merge commits in certain cases, which has been corrected. + (merge be011bbe00 ma/fast-export-skip-merge-fix later to maint). + + * The code did not propagate the terminal width to subprocesses via + COLUMNS environment variable, which it now does. This caused + trouble to "git column" helper subprocess when "git tag --column=row" + tried to list the existing tags on a display with non-default width. + (merge b5d5a567fb nd/term-columns later to maint). + + * We learned that our source files with ".pl" and ".py" extensions + are Perl and Python files respectively and changes to them are + better viewed as such with appropriate diff drivers. + (merge 7818b619e2 ab/perl-python-attrs later to maint). + + * "git rebase -i" sometimes left intermediate "# This is a + combination of N commits" message meant for the human consumption + inside an editor in the final result in certain corner cases, which + has been fixed. + (merge 15ef69314d js/rebase-i-clean-msg-after-fixup-continue later to maint). + + * A test to see if the filesystem normalizes UTF-8 filename has been + updated to check what we need to know in a more direct way, i.e. a + path created in NFC form can be accessed with NFD form (or vice + versa) to cope with APFS as well as HFS. + (merge 742ae10e35 tb/test-apfs-utf8-normalization later to maint). + + * "git format-patch --cover --attach" created a broken MIME multipart + message for the cover letter, which has been fixed by keeping the + cover letter as plain text file. + (merge 50cd54ef4e bc/format-patch-cover-no-attach later to maint). + + * The split-index feature had a long-standing and dormant bug in + certain use of the in-core merge machinery, which has been fixed. + (merge 7db118303a en/unpack-trees-split-index-fix later to maint). + + * Asciidoctor gives a reasonable imitation for AsciiDoc, but does not + render illustration in a literal block correctly when indented with + HT by default. The problem is fixed by forcing 8-space tabs. + (merge 379805051d bc/asciidoctor-tab-width later to maint). + + * Code clean-up to adjust to a more recent lockfile API convention that + allows lockfile instances kept on the stack. + (merge 0fa5a2ed8d ma/lockfile-cleanup later to maint). + + * the_repository->index is not a allocated piece of memory but + repo_clear() indiscriminately attempted to free(3) it, which has + been corrected. + (merge 74373b5f10 nd/repo-clear-keep-the-index later to maint). + + * Code clean-up to avoid non-standard-conformant pointer arithmetic. + (merge c112084af9 rs/no-null-ptr-arith-in-fast-export later to maint). + + * Code clean-up to turn history traversal more robust in a + semi-corrupt repository. + (merge 8702b30fd7 jk/unavailable-can-be-missing later to maint). + + * "git update-ref A B" is supposed to ensure that ref A does not yet + exist when B is a NULL OID, but this check was not done correctly + for pseudo-refs outside refs/ hierarchy, e.g. MERGE_HEAD. + + * "git submodule update" and "git submodule add" supported the + "--reference" option to borrow objects from a neighbouring local + repository like "git clone" does, but lacked the more recent + invention "--dissociate". Also "git submodule add" has been taught + to take the "--progress" option. + (merge a0ef29341a cf/submodule-progress-dissociate later to maint). + + * Update credential-netrc helper (in contrib/) to allow customizing + the GPG used to decrypt the encrypted .netrc file. + (merge 786ef50a23 lm/credential-netrc later to maint). + + * "git submodule update" attempts two different kinds of "git fetch" + against the upstream repository to grab a commit bound at the + submodule's path, but it incorrectly gave up if the first kind + (i.e. a normal fetch) failed, making the second "last resort" one + (i.e. fetching an exact commit object by object name) ineffective. + This has been corrected. + (merge e30d833671 sb/submodule-update-try-harder later to maint). + + * Error behaviour of "git grep" when it cannot read the index was + inconsistent with other commands that uses the index, which has + been corrected to error out early. + (merge b2aa84c789 sb/grep-die-on-unreadable-index later to maint). + + * We used to call regfree() after regcomp() failed in some codepaths, + which have been corrected. + (merge 17154b1576 ma/regex-no-regfree-after-comp-fail later to maint). + + * The import-tars script (in contrib/) has been taught to handle + tarballs with overly long paths that use PAX extended headers. + (merge 12ecea46e3 pa/import-tars-long-names later to maint). + + * "git rev-parse Y..." etc. misbehaved when given endpoints were + not committishes. + (merge 0ed556d38f en/rev-parse-invalid-range later to maint). + + * "git pull --recurse-submodules --rebase", when the submodule + repository's history did not have anything common between ours and + the upstream's, failed to execute. We need to fetch from them to + continue even in such a case. + (merge 4d36f88be7 jt/submodule-pull-recurse-rebase later to maint). + + * "git remote update" can take both a single remote nickname and a + nickname for remote groups, but only one of them was documented. + (merge a97447a42a nd/remote-update-doc later to maint). + + * "index-pack --strict" has been taught to make sure that it runs the + final object integrity checks after making the freshly indexed + packfile available to itself. + (merge 3737746120 jk/index-pack-maint later to maint). + + * Make zlib inflate codepath more robust against versions of zlib + that clobber unused portion of outbuf. + (merge b611396e97 jl/zlib-restore-nul-termination later to maint). + + * Fix old merge glitch in Documentation during v2.13-rc0 era. + (merge 28cb06020b mw/doc-merge-enumfix later to maint). + + * The code to read compressed bitmap was not careful to avoid reading + past the end of the file, which has been corrected. + (merge 1140bf01ec jk/ewah-bounds-check later to maint). + + * "make NO_ICONV=NoThanks" did not override NEEDS_LIBICONV + (i.e. linkage of -lintl, -liconv, etc. that are platform-specific + tweaks), which has been corrected. + (merge fdb1fbbc7d es/make-no-iconv later to maint). + + * Other minor doc, test and build updates and code cleanups. + (merge 248f66ed8e nd/trace-with-env later to maint). + (merge 14ced5562c ys/bisect-object-id-missing-conversion-fix later to maint). + (merge 5988eb631a ab/doc-hash-brokenness later to maint). + (merge a4d4e32a70 pk/test-avoid-pipe-hiding-exit-status later to maint). + (merge 05e293c1ac jk/flockfile-stdio later to maint). + (merge e9184b0789 jk/t5561-missing-curl later to maint). + (merge b1801b85a3 nd/worktree-move later to maint). + (merge bbd374dd20 ak/bisect-doc-typofix later to maint). + (merge 4855f06fb3 mn/send-email-credential-doc later to maint). + (merge 8523b1e355 en/doc-typoes later to maint). + (merge 43b44ccfe7 js/t5404-path-fix later to maint). + (merge decf711fc1 ps/test-chmtime-get later to maint). + (merge 22d11a6e8e es/worktree-docs later to maint). + (merge 92a5dbbc22 tg/use-git-contacts later to maint). + (merge adc887221f tq/t1510 later to maint). + (merge bed21a8ad6 sg/doc-gc-quote-mismatch-fix later to maint). + (merge 73364e4f10 tz/doc-git-urls-reference later to maint). + (merge cd1e606bad bc/mailmap-self later to maint). + (merge f7997e3682 ao/config-api-doc later to maint). + (merge ee930754d8 jk/apply-p-doc later to maint). + (merge 011b648646 nd/pack-format-doc later to maint). + (merge 87a6bb701a sg/t5310-jgit-bitmap-test later to maint). + (merge f6b82970aa sg/t5516-fixes later to maint). + (merge 4362da078e sg/t7005-spaces-in-filenames-cleanup later to maint). + (merge 7d0ee47c11 js/test-unset-prereq later to maint). + (merge 5356a3c354 ah/misc-doc-updates later to maint). + (merge 92c4a7a129 nd/completion-aliasfiletype-typofix later to maint). + (merge 58bd77b66a nd/pack-unreachable-objects-doc later to maint). + (merge 4ed79d5203 sg/t6500-no-redirect-of-stdin later to maint). + (merge 17b8a2d6cd jk/config-blob-sans-repo later to maint). + (merge 590551ca2c rd/tag-doc-lightweight later to maint). + (merge 44f560fc16 rd/init-typo later to maint). + (merge f156a0934a rd/p4-doc-markup-env later to maint). + (merge 2a00502b14 tg/doc-sec-list later to maint). + (merge 47cc91310a jk/submodule-fsck-loose-fixup later to maint). + (merge efde7b725c rd/comment-typofix-in-sha1-file later to maint). + (merge 7eedad15df rd/diff-options-typofix later to maint). + (merge 58ebd936cc km/doc-workflows-typofix later to maint). + (merge 30aa96cdf8 rd/doc-remote-tracking-with-hyphen later to maint). + (merge cf317877e3 ks/branch-set-upstream later to maint). + (merge 8de19d6be8 sg/t7406-chain-fix later to maint). diff --git a/Documentation/RelNotes/2.18.1.txt b/Documentation/RelNotes/2.18.1.txt new file mode 100644 index 0000000000..2098cdd776 --- /dev/null +++ b/Documentation/RelNotes/2.18.1.txt @@ -0,0 +1,6 @@ +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/Documentation/RelNotes/2.18.2.txt b/Documentation/RelNotes/2.18.2.txt new file mode 100644 index 0000000000..98b168aade --- /dev/null +++ b/Documentation/RelNotes/2.18.2.txt @@ -0,0 +1,8 @@ +Git v2.18.2 Release Notes +========================= + +This release merges up the fixes that appear in v2.14.6, v2.15.4 +and in v2.17.3, addressing the security issues CVE-2019-1348, +CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, +CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes +for those versions for details. diff --git a/Documentation/RelNotes/2.18.3.txt b/Documentation/RelNotes/2.18.3.txt new file mode 100644 index 0000000000..25143f0cec --- /dev/null +++ b/Documentation/RelNotes/2.18.3.txt @@ -0,0 +1,5 @@ +Git v2.18.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.18.4.txt b/Documentation/RelNotes/2.18.4.txt new file mode 100644 index 0000000000..e8ef858a00 --- /dev/null +++ b/Documentation/RelNotes/2.18.4.txt @@ -0,0 +1,5 @@ +Git v2.18.4 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.19.0.txt b/Documentation/RelNotes/2.19.0.txt new file mode 100644 index 0000000000..891c79b9cb --- /dev/null +++ b/Documentation/RelNotes/2.19.0.txt @@ -0,0 +1,615 @@ +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 programmatically 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/Documentation/RelNotes/2.19.1.txt b/Documentation/RelNotes/2.19.1.txt new file mode 100644 index 0000000000..da7672674e --- /dev/null +++ b/Documentation/RelNotes/2.19.1.txt @@ -0,0 +1,6 @@ +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/Documentation/RelNotes/2.19.2.txt b/Documentation/RelNotes/2.19.2.txt new file mode 100644 index 0000000000..759e6ca957 --- /dev/null +++ b/Documentation/RelNotes/2.19.2.txt @@ -0,0 +1,108 @@ +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/Documentation/RelNotes/2.19.3.txt b/Documentation/RelNotes/2.19.3.txt new file mode 100644 index 0000000000..92d7f89de6 --- /dev/null +++ b/Documentation/RelNotes/2.19.3.txt @@ -0,0 +1,8 @@ +Git v2.19.3 Release Notes +========================= + +This release merges up the fixes that appear in v2.14.6, v2.15.4 +and in v2.17.3, addressing the security issues CVE-2019-1348, +CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, +CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes +for those versions for details. diff --git a/Documentation/RelNotes/2.19.4.txt b/Documentation/RelNotes/2.19.4.txt new file mode 100644 index 0000000000..35d0ae561b --- /dev/null +++ b/Documentation/RelNotes/2.19.4.txt @@ -0,0 +1,5 @@ +Git v2.19.4 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.19.5.txt b/Documentation/RelNotes/2.19.5.txt new file mode 100644 index 0000000000..18a4dcbfd6 --- /dev/null +++ b/Documentation/RelNotes/2.19.5.txt @@ -0,0 +1,5 @@ +Git v2.19.5 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.2.0.txt b/Documentation/RelNotes/2.2.0.txt new file mode 100644 index 0000000000..e98ecbcff6 --- /dev/null +++ b/Documentation/RelNotes/2.2.0.txt @@ -0,0 +1,313 @@ +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/Documentation/RelNotes/2.2.1.txt b/Documentation/RelNotes/2.2.1.txt new file mode 100644 index 0000000000..d5a3cd9e73 --- /dev/null +++ b/Documentation/RelNotes/2.2.1.txt @@ -0,0 +1,34 @@ +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/Documentation/RelNotes/2.2.2.txt b/Documentation/RelNotes/2.2.2.txt new file mode 100644 index 0000000000..b19a35d94f --- /dev/null +++ b/Documentation/RelNotes/2.2.2.txt @@ -0,0 +1,63 @@ +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/Documentation/RelNotes/2.2.3.txt b/Documentation/RelNotes/2.2.3.txt new file mode 100644 index 0000000000..5bfffa4106 --- /dev/null +++ b/Documentation/RelNotes/2.2.3.txt @@ -0,0 +1,9 @@ +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/Documentation/RelNotes/2.20.0.txt b/Documentation/RelNotes/2.20.0.txt new file mode 100644 index 0000000000..3dd7e6e1fc --- /dev/null +++ b/Documentation/RelNotes/2.20.0.txt @@ -0,0 +1,700 @@ +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 cruft" 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/Documentation/RelNotes/2.20.1.txt b/Documentation/RelNotes/2.20.1.txt new file mode 100644 index 0000000000..dcba888dba --- /dev/null +++ b/Documentation/RelNotes/2.20.1.txt @@ -0,0 +1,20 @@ +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/Documentation/RelNotes/2.20.2.txt b/Documentation/RelNotes/2.20.2.txt new file mode 100644 index 0000000000..8e680cb9fb --- /dev/null +++ b/Documentation/RelNotes/2.20.2.txt @@ -0,0 +1,18 @@ +Git v2.20.2 Release Notes +========================= + +This release merges up the fixes that appear in v2.14.6, v2.15.4 +and in v2.17.3, addressing the security issues CVE-2019-1348, +CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, +CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes +for those versions for details. + +The change to disallow `submodule.<name>.update=!command` entries in +`.gitmodules` which was introduced v2.15.4 (and for which v2.17.3 +added explicit fsck checks) fixes the vulnerability in v2.20.x where a +recursive clone followed by a submodule update could execute code +contained within the repository without the user explicitly having +asked for that (CVE-2019-19604). + +Credit for finding this vulnerability goes to Joern Schneeweisz, +credit for the fixes goes to Jonathan Nieder. diff --git a/Documentation/RelNotes/2.20.3.txt b/Documentation/RelNotes/2.20.3.txt new file mode 100644 index 0000000000..f6eccd103b --- /dev/null +++ b/Documentation/RelNotes/2.20.3.txt @@ -0,0 +1,5 @@ +Git v2.20.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.20.4.txt b/Documentation/RelNotes/2.20.4.txt new file mode 100644 index 0000000000..5a9e24e470 --- /dev/null +++ b/Documentation/RelNotes/2.20.4.txt @@ -0,0 +1,5 @@ +Git v2.20.4 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.21.0.txt b/Documentation/RelNotes/2.21.0.txt new file mode 100644 index 0000000000..7a49deddf3 --- /dev/null +++ b/Documentation/RelNotes/2.21.0.txt @@ -0,0 +1,451 @@ +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/Documentation/RelNotes/2.21.1.txt b/Documentation/RelNotes/2.21.1.txt new file mode 100644 index 0000000000..b7594151e4 --- /dev/null +++ b/Documentation/RelNotes/2.21.1.txt @@ -0,0 +1,12 @@ +Git v2.21.1 Release Notes +========================= + +This release merges up the fixes that appear in v2.14.6, v2.15.4, +v2.17.3 and in v2.20.2, addressing the security issues CVE-2019-1348, +CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, +CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and CVE-2019-19604; +see the release notes for those versions for details. + +Additionally, this version also includes a couple of fixes for the +Windows-specific quoting of command-line arguments when Git executes +a Unix shell on Windows. diff --git a/Documentation/RelNotes/2.21.2.txt b/Documentation/RelNotes/2.21.2.txt new file mode 100644 index 0000000000..a0fb83bb53 --- /dev/null +++ b/Documentation/RelNotes/2.21.2.txt @@ -0,0 +1,5 @@ +Git v2.21.2 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.21.3.txt b/Documentation/RelNotes/2.21.3.txt new file mode 100644 index 0000000000..2ca0aa5c62 --- /dev/null +++ b/Documentation/RelNotes/2.21.3.txt @@ -0,0 +1,5 @@ +Git v2.21.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.22.0.txt b/Documentation/RelNotes/2.22.0.txt new file mode 100644 index 0000000000..91e6ae9887 --- /dev/null +++ b/Documentation/RelNotes/2.22.0.txt @@ -0,0 +1,597 @@ +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/Documentation/RelNotes/2.22.1.txt b/Documentation/RelNotes/2.22.1.txt new file mode 100644 index 0000000000..432762f270 --- /dev/null +++ b/Documentation/RelNotes/2.22.1.txt @@ -0,0 +1,150 @@ +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/Documentation/RelNotes/2.22.2.txt b/Documentation/RelNotes/2.22.2.txt new file mode 100644 index 0000000000..940a23f0d9 --- /dev/null +++ b/Documentation/RelNotes/2.22.2.txt @@ -0,0 +1,8 @@ +Git v2.22.2 Release Notes +========================= + +This release merges up the fixes that appear in v2.14.6, v2.15.4, +v2.17.3, v2.20.2 and in v2.21.1, addressing the security issues +CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, +CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and +CVE-2019-19604; see the release notes for those versions for details. diff --git a/Documentation/RelNotes/2.22.3.txt b/Documentation/RelNotes/2.22.3.txt new file mode 100644 index 0000000000..57296f6d17 --- /dev/null +++ b/Documentation/RelNotes/2.22.3.txt @@ -0,0 +1,5 @@ +Git v2.22.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.22.4.txt b/Documentation/RelNotes/2.22.4.txt new file mode 100644 index 0000000000..8b5f3e3f37 --- /dev/null +++ b/Documentation/RelNotes/2.22.4.txt @@ -0,0 +1,5 @@ +Git v2.22.4 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.23.0.txt b/Documentation/RelNotes/2.23.0.txt new file mode 100644 index 0000000000..e3c4e78265 --- /dev/null +++ b/Documentation/RelNotes/2.23.0.txt @@ -0,0 +1,348 @@ +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/Documentation/RelNotes/2.23.1.txt b/Documentation/RelNotes/2.23.1.txt new file mode 100644 index 0000000000..2083b492ce --- /dev/null +++ b/Documentation/RelNotes/2.23.1.txt @@ -0,0 +1,8 @@ +Git v2.23.1 Release Notes +========================= + +This release merges up the fixes that appear in v2.14.6, v2.15.4, +v2.17.3, v2.20.2 and in v2.21.1, addressing the security issues +CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, +CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and +CVE-2019-19604; see the release notes for those versions for details. diff --git a/Documentation/RelNotes/2.23.2.txt b/Documentation/RelNotes/2.23.2.txt new file mode 100644 index 0000000000..b697cbe0e3 --- /dev/null +++ b/Documentation/RelNotes/2.23.2.txt @@ -0,0 +1,5 @@ +Git v2.23.2 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.23.3.txt b/Documentation/RelNotes/2.23.3.txt new file mode 100644 index 0000000000..2e35490137 --- /dev/null +++ b/Documentation/RelNotes/2.23.3.txt @@ -0,0 +1,5 @@ +Git v2.23.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.24.0.txt b/Documentation/RelNotes/2.24.0.txt new file mode 100644 index 0000000000..bde154124c --- /dev/null +++ b/Documentation/RelNotes/2.24.0.txt @@ -0,0 +1,398 @@ +Git 2.24 Release Notes +====================== + +Updates since v2.23 +------------------- + +Backward compatibility note + + * "filter-branch" is showing its age and alternatives are available. + From this release, we started to discourage its use and hint + people about filter-repo. + +UI, Workflows & Features + + * We now have an active interim maintainer for the Git-Gui part of + the system. Praise and thank Pratyush Yadav for volunteering. + + * The command line parser learned "--end-of-options" notation; the + standard convention for scripters to have hardcoded set of options + first on the command line, and force the command to treat end-user + input as non-options, has been to use "--" as the delimiter, but + that would not work for commands that use "--" as a delimiter + between revs and pathspec. + + * A mechanism to affect the default setting for a (related) group of + configuration variables is introduced. + + * "git fetch" learned "--set-upstream" option to help those who first + clone from their private fork they intend to push to, add the true + upstream via "git remote add" and then "git fetch" from it. + + * Device-tree files learned their own userdiff patterns. + (merge 3c81760bc6 sb/userdiff-dts later to maint). + + * "git rebase --rebase-merges" learned to drive different merge + strategies and pass strategy specific options to them. + + * A new "pre-merge-commit" hook has been introduced. + + * Command line completion updates for "git -c var.name=val" have been + added. + + * The lazy clone machinery has been taught that there can be more + than one promisor remote and consult them in order when downloading + missing objects on demand. + + * The list-objects-filter API (used to create a sparse/lazy clone) + learned to take a combined filter specification. + + * The documentation and tests for "git format-patch" have been + cleaned up. + + * On Windows, the root level of UNC share is now allowed to be used + just like any other directory. + + * The command line completion support (in contrib/) learned about the + "--skip" option of "git revert" and "git cherry-pick". + + * "git rebase --keep-base <upstream>" tries to find the original base + of the topic being rebased and rebase on top of that same base, + which is useful when running the "git rebase -i" (and its limited + variant "git rebase -x"). + + The command also has learned to fast-forward in more cases where it + can instead of replaying to recreate identical commits. + + * A configuration variable tells "git fetch" to write the commit + graph after finishing. + + * "git add -i" has been taught to show the total number of hunks and + the hunks that has been processed so far when showing prompts. + + * "git fetch --jobs=<n>" allowed <n> parallel jobs when fetching + submodules, but this did not apply to "git fetch --multiple" that + fetches from multiple remote repositories. It now does. + + * The installation instruction for zsh completion script (in + contrib/) has been a bit improved. + + +Performance, Internal Implementation, Development Support etc. + + * The code to write commit-graph over given commit object names has + been made a bit more robust. + + * The first line of verbose output from each test piece now carries + the test name and number to help scanning with eyeballs. + + * Further clean-up of the initialization code. + + * xmalloc() used to have a mechanism to ditch memory and address + space resources as the last resort upon seeing an allocation + failure from the underlying malloc(), which made the code complex + and thread-unsafe with dubious benefit, as major memory resource + users already do limit their uses with various other mechanisms. + It has been simplified away. + + * Unnecessary full-tree diff in "git log -L" machinery has been + optimized away. + + * The http transport lacked some optimization the native transports + learned to avoid unnecessary ref advertisement, which has been + corrected. + + * Preparation for SHA-256 upgrade continues in the test department. + (merge 0c37c41d13 bc/hash-independent-tests-part-5 later to maint). + + * The memory ownership model of the "git fast-import" got + straightened out. + + * Output from trace2 subsystem is formatted more prettily now. + + * The internal code originally invented for ".gitignore" processing + got reshuffled and renamed to make it less tied to "excluding" and + stress more that it is about "matching", as it has been reused for + things like sparse checkout specification that want to check if a + path is "included". + + * "git stash" learned to write refreshed index back to disk. + + * Coccinelle checks are done on more source files than before now. + + * The cache-tree code has been taught to be less aggressive in + attempting to see if a tree object it computed already exists in + the repository. + + * The code to parse and use the commit-graph file has been made more + robust against corrupted input. + + * The hg-to-git script (in contrib/) has been updated to work with + Python 3. + + * Update the way build artifacts in t/helper/ directory are ignored. + + * Preparation for SHA-256 upgrade continues. + + * "git log --graph" for an octopus merge is sometimes colored + incorrectly, which is demonstrated and documented but not yet + fixed. + + * The trace2 output, when sending them to files in a designated + directory, can populate the directory with too many files; a + mechanism is introduced to set the maximum number of files and + discard further logs when the maximum is reached. + + * We have adopted a Code-of-conduct document. + (merge 3f9ef874a7 jk/coc later to maint). + + +Fixes since v2.23 +----------------- + + * "git grep --recurse-submodules" that looks at the working tree + files looked at the contents in the index in submodules, instead of + files in the working tree. + (merge 6a289d45c0 mt/grep-submodules-working-tree later to maint). + + * Codepaths to walk tree objects have been audited for integer + overflows and hardened. + (merge 5aa02f9868 jk/tree-walk-overflow later to maint). + + * "git pack-refs" can lose refs that are created while running, which + is getting corrected. + (merge a613d4f817 sc/pack-refs-deletion-racefix later to maint). + + * "git checkout" and "git restore" to re-populate the index from a + tree-ish (typically HEAD) did not work correctly for a path that + was removed and then added again with the intent-to-add bit, when + the corresponding working tree file was empty. This has been + corrected. + + * Compilation fix. + (merge 70597e8386 rs/nedalloc-fixlets later to maint). + + * "git gui" learned to call the clean-up procedure before exiting. + (merge 0d88f3d2c5 py/git-gui-do-quit later to maint). + + * We promoted the "indent heuristics" that decides where to split + diff hunks from experimental to the default a few years ago, but + some stale documentation still marked it as experimental, which has + been corrected. + (merge 64e5e1fba1 sg/diff-indent-heuristic-non-experimental later to maint). + + * Fix a mismerge that happened in 2.22 timeframe. + (merge acb7da05ac en/checkout-mismerge-fix later to maint). + + * "git archive" recorded incorrect length in extended pax header in + some corner cases, which has been corrected. + (merge 71d41ff651 rs/pax-extended-header-length-fix later to maint). + + * On-demand object fetching in lazy clone incorrectly tried to fetch + commits from submodule projects, while still working in the + superproject, which has been corrected. + (merge a63694f523 jt/diff-lazy-fetch-submodule-fix later to maint). + + * Prepare get_short_oid() codepath to be thread-safe. + (merge 7cfcb16b0e rs/sort-oid-array-thread-safe later to maint). + + * "for-each-ref" and friends that show refs did not protect themselves + against ancient tags that did not record tagger names when asked to + show "%(taggername)", which have been corrected. + (merge 8b3f33ef11 mp/for-each-ref-missing-name-or-email later to maint). + + * The "git am" based backend of "git rebase" ignored the result of + updating ".gitattributes" done in one step when replaying + subsequent steps. + (merge 2c65d90f75 bc/reread-attributes-during-rebase later to maint). + + * Tell cURL library to use the same malloc() implementation, with the + xmalloc() wrapper, as the rest of the system, for consistency. + (merge 93b980e58f cb/curl-use-xmalloc later to maint). + + * Build fix to adjust .gitignore to unignore a path that we started to track. + (merge aac6ff7b5b js/visual-studio later to maint). + + * A few implementation fixes in the notes API. + (merge 60fe477a0b mh/notes-duplicate-entries later to maint). + + * Fix an earlier regression to "git push --all" which should have + been forbidden when the target remote repository is set to be a + mirror. + (merge 8e4c8af058 tg/push-all-in-mirror-forbidden later to maint). + + * Fix an earlier regression in the test suite, which mistakenly + stopped running HTTPD tests. + (merge 3960290675 sg/git-test-boolean later to maint). + + * "git rebase --autostash <upstream> <branch>", when <branch> is + different from the current branch, incorrectly moved the tip of the + current branch, which has been corrected. + (merge bf1e28e0ad bw/rebase-autostash-keep-current-branch later to maint). + + * Update support for Asciidoctor documentation toolchain. + (merge 83b0b8953e ma/asciidoctor-refmiscinfo later to maint). + + * Start using DocBook 5 (instead of DocBook 4.5) as Asciidoctor 2.0 + no longer works with the older one. + (merge f6461b82b9 bc/doc-use-docbook-5 later to maint). + + * The markup used in user-manual has been updated to work better with + asciidoctor. + (merge c4d2f6143a ma/user-manual-markup-update later to maint). + + * Make sure the grep machinery does not abort when seeing a payload + that is not UTF-8 even when JIT is not in use with PCRE1. + (merge ad7c543e3b cb/skip-utf8-check-with-pcre1 later to maint). + + * The name of the blob object that stores the filter specification + for sparse cloning/fetching was interpreted in a wrong place in the + code, causing Git to abort. + + * "git log --decorate-refs-exclude=<pattern>" was incorrectly + overruled when the "--simplify-by-decoration" option is used, which + has been corrected. + (merge 0cc7380d88 rs/simplify-by-deco-with-deco-refs-exclude later to maint). + + * The "upload-pack" (the counterpart of "git fetch") needs to disable + commit-graph when responding to a shallow clone/fetch request, but + the way this was done made Git panic, which has been corrected. + + * The object traversal machinery has been optimized not to load tree + objects when we are only interested in commit history. + (merge 72ed80c784 jk/list-objects-optim-wo-trees later to maint). + + * The object name parser for "Nth parent" syntax has been made more + robust against integer overflows. + (merge 59fa5f5a25 rs/nth-parent-parse later to maint). + + * The code used in following tags in "git fetch" has been optimized. + (merge b7e2d8bca5 ms/fetch-follow-tag-optim later to maint). + + * Regression fix for progress output. + (merge 2bb74b53a4 sg/progress-fix later to maint). + + * A bug in merge-recursive code that triggers when a branch with a + symbolic link is merged with a branch that replaces it with a + directory has been fixed. + (merge 83e3ad3b12 jt/merge-recursive-symlink-is-not-a-dir-in-way later to maint). + + * The rename detection logic sorts a list of rename source candidates + by similarity to pick the best candidate, which means that a tie + between sources with the same similarity is broken by the original + location in the original candidate list (which is sorted by path). + Force the sorting by similarity done with a stable sort, which is + not promised by system supplied qsort(3), to ensure consistent + results across platforms. + (merge 2049b8dc65 js/diff-rename-force-stable-sort later to maint). + + * The code to skip "UTF" and "UTF-" prefix, when computing an advice + message, did not work correctly when the prefix was "UTF", which + has been fixed. + (merge b181676ce9 rs/convert-fix-utf-without-dash later to maint). + + * The author names taken from SVN repositories may have extra leading + or trailing whitespaces, which are now munged away. + (merge 4ddd4bddb1 tk/git-svn-trim-author-name later to maint). + + * "git rebase -i" showed a wrong HEAD while "reword" open the editor. + (merge b0a3186140 pw/rebase-i-show-HEAD-to-reword later to maint). + + * A few simplification and bugfixes to PCRE interface. + (merge c581e4a749 ab/pcre-jit-fixes later to maint). + + * PCRE fixes. + (merge ff61681b46 cb/pcre1-cleanup later to maint). + + * "git range-diff" segfaulted when diff.noprefix configuration was + used, as it blindly expected the patch it internally generates to + have the standard a/ and b/ prefixes. The command now forces the + internal patch to be built without any prefix, not to be affected + by any end-user configuration. + (merge 937b76ed49 js/range-diff-noprefix later to maint). + + * "git stash apply" in a subdirectory of a secondary worktree failed + to access the worktree correctly, which has been corrected. + (merge dfd557c978 js/stash-apply-in-secondary-worktree later to maint). + + * The merge-recursive machinery is one of the most complex parts of + the system that accumulated cruft over time. This large series + cleans up the implementation quite a bit. + (merge b657047719 en/merge-recursive-cleanup later to maint). + + * Pretty-printed command line formatter (used in e.g. reporting the + command being run by the tracing API) had a bug that lost an + argument that is an empty string, which has been corrected. + (merge ce2d7ed2fd gs/sq-quote-buf-pretty later to maint). + + * "git range-diff" failed to handle mode-only change, which has been + corrected. + (merge 2b6a9b13ca tg/range-diff-output-update later to maint). + + * Dev support update. + (merge 4f3c1dc5d6 dl/allow-running-cocci-verbosely later to maint). + + * "git format-patch -o <outdir>" did an equivalent of "mkdir <outdir>" + not "mkdir -p <outdir>", which was corrected. + + * "git stash save" lost local changes to submodules, which has been + corrected. + (merge 556895d0c8 jj/stash-reset-only-toplevel later to maint). + + * The atomic push over smart HTTP transport did not work, which has + been corrected. + (merge 6f1194246a bc/smart-http-atomic-push later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge d1387d3895 en/fast-import-merge-doc later to maint). + (merge 1c24a54ea4 bm/repository-layout-typofix later to maint). + (merge 415b770b88 ds/midx-expire-repack later to maint). + (merge 19800bdc3f nd/diff-parseopt later to maint). + (merge 58166c2e9d tg/t0021-racefix later to maint). + (merge 7027f508c7 dl/compat-cleanup later to maint). + (merge e770fbfeff jc/test-cleanup later to maint). + (merge 1fd881d404 rs/trace2-dst-warning later to maint). + (merge 7e92756751 mh/http-urlmatch-cleanup later to maint). + (merge 9784f97321 mh/release-commit-memory-fix later to maint). + (merge 60d198d022 tb/banned-vsprintf-namefix later to maint). + (merge 80e3658647 rs/help-unknown-ref-does-not-return later to maint). + (merge 0a8bc7068f dt/remote-helper-doc-re-lock-option later to maint). + (merge 27fd1e4ea7 en/merge-options-ff-and-friends later to maint). + (merge 502c386ff9 sg/clean-nested-repo-with-ignored later to maint). + (merge 26e3d1cbea am/mailmap-andrey-mazo later to maint). + (merge 47b27c96fa ss/get-time-cleanup later to maint). + (merge dd2e50a84e jk/commit-graph-cleanup later to maint). + (merge 4fd39c76e6 cs/pretty-formats-doc-typofix later to maint). + (merge 40e747e89d dl/submodule-set-branch later to maint). + (merge 689a146c91 rs/commit-graph-use-list-count later to maint). + (merge 0eb7c37a8a js/doc-patch-text later to maint). + (merge 4b3aa170d1 rs/nth-switch-code-simplification later to maint). + (merge 0d4304c124 ah/doc-submodule-ignore-submodules later to maint). + (merge af78249463 cc/svn-fe-py-shebang later to maint). + (merge 7bd97d6dff rs/alias-use-copy-array later to maint). + (merge c46ebc2496 sg/travis-help-debug later to maint). + (merge 24c681794f ps/my-first-contribution-alphasort later to maint). + (merge 75b2c15435 cb/do-not-use-test-cmp-with-a later to maint). + (merge cda0d497e3 bw/submodule-helper-usage-fix later to maint). + (merge fe0ed5d5e9 am/visual-studio-config-fix later to maint). + (merge 2e09c01232 sg/name-rev-cutoff-underflow-fix later to maint). + (merge ddb3c856f3 as/shallow-slab-use-fix later to maint). + (merge 71f4960b91 js/mingw-spawn-with-spaces-in-path later to maint). + (merge 53d687bf5f ah/cleanups later to maint). + (merge f537485fa5 rs/test-remove-useless-debugging-cat later to maint). + (merge 11a3d3aadd dl/rev-list-doc-cleanup later to maint). + (merge d928a8388a am/t0028-utf16-tests later to maint). + (merge b05b40930e dl/t0000-skip-test-test later to maint). + (merge 03d3b1297c js/xdiffi-comment-updates later to maint). + (merge 57d8f4b4c7 js/doc-stash-save later to maint). + (merge 8c1cfd58e3 ta/t1308-typofix later to maint). + (merge fa364ad790 bb/utf8-wcwidth-cleanup later to maint). + (merge 68b69211b2 bb/compat-util-comment-fix later to maint). + (merge 5cc6a4be11 rs/http-push-simplify later to maint). + (merge a81e42d235 rs/column-use-utf8-strnwidth later to maint). + (merge 062a309d36 rs/remote-curl-use-argv-array later to maint). + (merge 3b3c79f6c9 nr/diff-highlight-indent-fix later to maint). + (merge 3444ec2eb2 wb/fsmonitor-bitmap-fix later to maint). + (merge 10da030ab7 cb/pcre2-chartables-leakfix later to maint). + (merge 60e6569a12 js/mingw-needs-hiding-fix later to maint). + (merge 52bd3e4657 rl/gitweb-blame-prev-fix later to maint). diff --git a/Documentation/RelNotes/2.24.1.txt b/Documentation/RelNotes/2.24.1.txt new file mode 100644 index 0000000000..18104850fe --- /dev/null +++ b/Documentation/RelNotes/2.24.1.txt @@ -0,0 +1,8 @@ +Git v2.24.1 Release Notes +========================= + +This release merges up the fixes that appear in v2.14.6, v2.15.4, +v2.17.3, v2.20.2 and in v2.21.1, addressing the security issues +CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, +CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and +CVE-2019-19604; see the release notes for those versions for details. diff --git a/Documentation/RelNotes/2.24.2.txt b/Documentation/RelNotes/2.24.2.txt new file mode 100644 index 0000000000..0049f65503 --- /dev/null +++ b/Documentation/RelNotes/2.24.2.txt @@ -0,0 +1,5 @@ +Git v2.24.2 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.24.3.txt b/Documentation/RelNotes/2.24.3.txt new file mode 100644 index 0000000000..5302e0f73b --- /dev/null +++ b/Documentation/RelNotes/2.24.3.txt @@ -0,0 +1,5 @@ +Git v2.24.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.25.0.txt b/Documentation/RelNotes/2.25.0.txt new file mode 100644 index 0000000000..91ceb34927 --- /dev/null +++ b/Documentation/RelNotes/2.25.0.txt @@ -0,0 +1,370 @@ +Git 2.25 Release Notes +====================== + +Updates since v2.24 +------------------- + +Backward compatibility notes + + +UI, Workflows & Features + + * A tutorial on object enumeration has been added. + + * The branch description ("git branch --edit-description") has been + used to fill the body of the cover letters by the format-patch + command; this has been enhanced so that the subject can also be + filled. + + * "git rebase --preserve-merges" has been marked as deprecated; this + release stops advertising it in the "git rebase -h" output. + + * The code to generate multi-pack index learned to show (or not to + show) progress indicators. + + * "git apply --3way" learned to honor merge.conflictStyle + configuration variable, like merges would. + + * The custom format for "git log --format=<format>" learned the l/L + placeholder that is similar to e/E that fills in the e-mail + address, but only the local part on the left side of '@'. + + * Documentation pages for "git shortlog" now list commit limiting + options explicitly. + + * The patterns to detect function boundary for Elixir language has + been added. + + * The completion script (in contrib/) learned that the "--onto" + option of "git rebase" can take its argument as the value of the + option. + + * The userdiff machinery has been taught that "async def" is another + way to begin a "function" in Python. + + * "git range-diff" learned to take the "--notes=<ref>" and the + "--no-notes" options to control the commit notes included in the + log message that gets compared. + + * "git rev-parse --show-toplevel" run outside of any working tree did + not error out, which has been corrected. + + * A few commands learned to take the pathspec from the standard input + or a named file, instead of taking it as the command line + arguments, with the "--pathspec-from-file" option. + + * "git submodule" learned a subcommand "set-url". + + * "git log" family learned "--pretty=reference" that gives the name + of a commit in the format that is often used to refer to it in log + messages. + + * The interaction between "git clone --recurse-submodules" and + alternate object store was ill-designed. The documentation and + code have been taught to make more clear recommendations when the + users see failures. + + * Management of sparsely checked-out working tree has gained a + dedicated "sparse-checkout" command. + + * Miscellaneous small UX improvements on "git-p4". + + * "git sparse-checkout list" subcommand learned to give its output in + a more concise form when the "cone" mode is in effect. + + +Performance, Internal Implementation, Development Support etc. + + * Debugging support for lazy cloning has been a bit improved. + + * Move the definition of a set of bitmask constants from 0ctal + literal to (1U<<count) notation. + + * Test updates to prepare for SHA-2 transition continues. + + * Crufty code and logic accumulated over time around the object + parsing and low-level object access used in "git fsck" have been + cleaned up. + + * The implementation of "git log --graph" got refactored and then its + output got simplified. + + * Follow recent push to move API docs from Documentation/ to header + files and update config.h + + * "git bundle" has been taught to use the parse options API. "git + bundle verify" learned "--quiet" and "git bundle create" learned + options to control the progress output. + + * Handling of commit objects that use non UTF-8 encoding during + "rebase -i" has been improved. + + * The beginning of rewriting "git add -i" in C. + + * A label used in the todo list that are generated by "git rebase + --rebase-merges" is used as a part of a refname; the logic to come + up with the label has been tightened to avoid names that cannot be + used as such. + + * The logic to avoid duplicate label names generated by "git rebase + --rebase-merges" forgot that the machinery itself uses "onto" as a + label name, which must be avoided by auto-generated labels, which + has been corrected. + + * We have had compatibility fallback macro definitions for "PRIuMAX", + "PRIu32", etc. but did not for "PRIdMAX", while the code used the + last one apparently without any hiccup reported recently. The + fallback macro definitions for these <inttypes.h> macros that must + appear in C99 systems have been removed. + + * Recently we have declared that GIT_TEST_* variables take the + usual boolean values (it used to be that some used "non-empty + means true" and taking GIT_TEST_VAR=YesPlease as true); make + sure we notice and fail when non-bool strings are given to + these variables. + + * Users of oneway_merge() (like "reset --hard") learned to take + advantage of fsmonitor to avoid unnecessary lstat(2) calls. + + * Performance tweak on "git push" into a repository with many refs + that point at objects we have never heard of. + + * PerfTest fix to avoid stale result mixed up with the latest round + of test results. + + * Hide lower-level verify_signed-buffer() API as a pure helper to + implement the public check_signature() function, in order to + encourage new callers to use the correct and more strict + validation. + + * Unnecessary reading of state variables back from the disk during + sequencer operation has been reduced. + + * The code has been made to avoid gmtime() and localtime() and prefer + their reentrant counterparts. + + * In a repository with many packfiles, the cost of the procedure that + avoids registering the same packfile twice was unnecessarily high + by using an inefficient search algorithm, which has been corrected. + + * Redo "git name-rev" to avoid recursive calls. + + * FreeBSD CI support via Cirrus-CI has been added. + + +Fixes since v2.24 +----------------- + + * "rebase -i" ceased to run post-commit hook by mistake in an earlier + update, which has been corrected. + + * "git notes copy $original" ought to copy the notes attached to the + original object to HEAD, but a mistaken tightening to command line + parameter validation made earlier disabled that feature by mistake. + + * When all files from some subdirectory were renamed to the root + directory, the directory rename heuristics would fail to detect that + as a rename/merge of the subdirectory to the root directory, which has + been corrected. + + * Code clean-up and a bugfix in the logic used to tell worktree local + and repository global refs apart. + (merge f45f88b2e4 sg/dir-trie-fixes later to maint). + + * "git stash save" in a working tree that is sparsely checked out + mistakenly removed paths that are outside the area of interest. + (merge 4a58c3d7f7 js/update-index-ignore-removal-for-skip-worktree later to maint). + + * "git rev-parse --git-path HEAD.lock" did not give the right path + when run in a secondary worktree. + (merge 76a53d640f js/git-path-head-dot-lock-fix later to maint). + + * "git merge --no-commit" needs "--no-ff" if you do not want to move + HEAD, which has been corrected in the manual page for "git bisect". + (merge 8dd327b246 ma/bisect-doc-sample-update later to maint). + + * "git worktree add" internally calls "reset --hard" that should not + descend into submodules, even when submodule.recurse configuration + is set, but it was affected. This has been corrected. + (merge 4782cf2ab6 pb/no-recursive-reset-hard-in-worktree-add later to maint). + + * Messages from die() etc. can be mixed up from multiple processes + without even line buffering on Windows, which has been worked + around. + (merge 116d1fa6c6 js/vreportf-wo-buffering later to maint). + + * HTTP transport had possible allocator/deallocator mismatch, which + has been corrected. + + * The watchman integration for fsmonitor was racy, which has been + corrected to be more conservative. + (merge dd0b61f577 kw/fsmonitor-watchman-fix later to maint). + + * Fetching from multiple remotes into the same repository in parallel + had a bad interaction with the recent change to (optionally) update + the commit-graph after a fetch job finishes, as these parallel + fetches compete with each other. Which has been corrected. + + * Recent update to "git stash pop" made the command empty the index + when run with the "--quiet" option, which has been corrected. + + * "git fetch" codepath had a big "do not lazily fetch missing objects + when I ask if something exists" switch. This has been corrected by + marking the "does this thing exist?" calls with "if not please do not + lazily fetch it" flag. + + * Test update to avoid wasted cycles. + (merge e0316695ec sg/skip-skipped-prereq later to maint). + + * Error handling after "git push" finishes sending the packdata and + waits for the response to the remote side has been improved. + (merge ad7a403268 jk/send-pack-remote-failure later to maint). + + * Some codepaths in "gitweb" that forgot to escape URLs generated + based on end-user input have been corrected. + (merge a376e37b2c jk/gitweb-anti-xss later to maint). + + * CI jobs for macOS has been made less chatty when updating perforce + package used during testing. + (merge 0dbc4a0edf jc/azure-ci-osx-fix-fix later to maint). + + * "git unpack-objects" used to show progress based only on the number + of received and unpacked objects, which stalled when it has to + handle an unusually large object. It now shows the throughput as + well. + (merge bae60ba7e9 sg/unpack-progress-throughput later to maint). + + * The sequencer machinery compared the HEAD and the state it is + attempting to commit to decide if the result would be a no-op + commit, even when amending a commit, which was incorrect, and + has been corrected. + + * The code to parse GPG output used to assume incorrectly that the + finterprint for the primary key would always be present for a valid + signature, which has been corrected. + (merge 67a6ea6300 hi/gpg-optional-pkfp-fix later to maint). + + * "git submodule status" and "git submodule status --cached" show + different things, but the documentation did not cover them + correctly, which has been corrected. + (merge 8d483c8408 mg/doc-submodule-status-cached later to maint). + + * "git reset --patch $object" without any pathspec should allow a + tree object to be given, but incorrectly required a committish, + which has been corrected. + + * "git submodule status" that is run from a subdirectory of the + superproject did not work well, which has been corrected. + (merge 1f3aea22c7 mg/submodule-status-from-a-subdirectory later to maint). + + * The revision walking machinery uses resources like per-object flag + bits that need to be reset before a new iteration of walking + begins, but the resources related to topological walk were not + cleared correctly, which has been corrected. + (merge 0aa0c2b2ec mh/clear-topo-walk-upon-reset later to maint). + + * TravisCI update. + (merge 176441bfb5 sg/osx-force-gcc-9 later to maint). + + * While running "revert" or "cherry-pick --edit" for multiple + commits, a recent regression incorrectly detected "nothing to + commit, working tree clean", instead of replaying the commits, + which has been corrected. + (merge befd4f6a81 sg/assume-no-todo-update-in-cherry-pick later to maint). + + * Work around a issue where a FD that is left open when spawning a + child process and is kept open in the child can interfere with the + operation in the parent process on Windows. + + * One kind of progress messages were always given during commit-graph + generation, instead of following the "if it takes more than two + seconds, show progress" pattern, which has been corrected. + + * "git rebase" did not work well when format.useAutoBase + configuration variable is set, which has been corrected. + + * The "diff" machinery learned not to lose added/removed blank lines + in the context when --ignore-blank-lines and --function-context are + used at the same time. + (merge 0bb313a552 rs/xdiff-ignore-ws-w-func-context later to maint). + + * The test on "fast-import" used to get stuck when "fast-import" died + in the middle. + (merge 0d9b0d7885 sg/t9300-robustify later to maint). + + * "git format-patch" can take a set of configured format.notes values + to specify which notes refs to use in the log message part of the + output. The behaviour of this was not consistent with multiple + --notes command line options, which has been corrected. + (merge e0f9095aaa dl/format-patch-notes-config-fixup later to maint). + + * "git p4" used to ignore lfs.storage configuration variable, which + has been corrected. + (merge ea94b16fb8 rb/p4-lfs later to maint). + + * Assorted fixes to the directory traversal API. + (merge 6836d2fe06 en/fill-directory-fixes later to maint). + + * Forbid pathnames that the platform's filesystem cannot represent on + MinGW. + (merge 4dc42c6c18 js/mingw-reserved-filenames later to maint). + + * "git rebase --signoff" stopped working when the command was written + in C, which has been corrected. + (merge 4fe7e43c53 en/rebase-signoff-fix later to maint). + + * An earlier update to Git for Windows declared that a tree object is + invalid if it has a path component with backslash in it, which was + overly strict, which has been corrected. The only protection the + Windows users need is to prevent such path (or any path that their + filesystem cannot check out) from entering the index. + (merge 224c7d70fa js/mingw-loosen-overstrict-tree-entry-checks later to maint). + + * The code to write split commit-graph file(s) upon fetching computed + bogus value for the parameter used in splitting the resulting + files, which has been corrected. + (merge 63020f175f ds/commit-graph-set-size-mult later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge 80736d7c5e jc/am-show-current-patch-docfix later to maint). + (merge 8b656572ca sg/commit-graph-usage-fix later to maint). + (merge 6c02042139 mr/clone-dir-exists-to-path-exists later to maint). + (merge 44ae131e38 sg/blame-indent-heuristics-is-now-the-default later to maint). + (merge 0115e5d929 dl/doc-diff-no-index-implies-exit-code later to maint). + (merge 270de6acbe en/t6024-style later to maint). + (merge 14c4776d75 ns/test-desc-typofix later to maint). + (merge 68d40f30c4 dj/typofix-merge-strat later to maint). + (merge f66e0401ab jk/optim-in-pack-idx-conversion later to maint). + (merge 169bed7421 rs/parse-options-dup-null-fix later to maint). + (merge 51bd6be32d rs/use-copy-array-in-mingw-shell-command-preparation later to maint). + (merge b018719927 ma/t7004 later to maint). + (merge 932757b0cc ar/install-doc-update-cmds-needing-the-shell later to maint). + (merge 46efd28be1 ep/guard-kset-tar-headers later to maint). + (merge 9e5afdf997 ec/fetch-mark-common-refs-trace2 later to maint). + (merge f0e58b3fe8 pb/submodule-update-fetches later to maint). + (merge 2a02262078 dl/t5520-cleanup later to maint). + (merge a4fb016ba1 js/pkt-line-h-typofix later to maint). + (merge 54a7a64613 rs/simplify-prepare-cmd later to maint). + (merge 3eae30e464 jk/lore-is-the-archive later to maint). + (merge 14b7664df8 dl/lore-is-the-archive later to maint). + (merge 0e40a73a4c po/bundle-doc-clonable later to maint). + (merge e714b898c6 as/t7812-missing-redirects-fix later to maint). + (merge 528d9e6d01 jk/perf-wo-git-dot-pm later to maint). + (merge fc42f20e24 sg/test-squelch-noise-in-commit-bulk later to maint). + (merge c64368e3a2 bc/t9001-zsh-in-posix-emulation-mode later to maint). + (merge 11de8dd7ef dr/branch-usage-casefix later to maint). + (merge e05e8cf074 rs/archive-zip-code-cleanup later to maint). + (merge 147ee35558 rs/commit-export-env-simplify later to maint). + (merge 4507ecc771 rs/patch-id-use-oid-to-hex later to maint). + (merge 51a0a4ed95 mr/bisect-use-after-free later to maint). + (merge cc2bd5c45d pb/submodule-doc-xref later to maint). + (merge df5be01669 ja/doc-markup-cleanup later to maint). + (merge 7c5cea7242 mr/bisect-save-pointer-to-const-string later to maint). + (merge 20a67e8ce9 js/use-test-tool-on-path later to maint). + (merge 4e61b2214d ew/packfile-syscall-optim later to maint). + (merge ace0f86c7f pb/clarify-line-log-doc later to maint). + (merge 763a59e71c en/merge-recursive-oid-eq-simplify later to maint). + (merge 4e2c4c0d4f do/gitweb-typofix-in-comments later to maint). + (merge 421c0ffb02 jb/doc-multi-pack-idx-fix later to maint). + (merge f8740c586b pm/am-in-body-header-doc-update later to maint). + (merge 5814d44d9b tm/doc-submodule-absorb-fix later to maint). diff --git a/Documentation/RelNotes/2.25.1.txt b/Documentation/RelNotes/2.25.1.txt new file mode 100644 index 0000000000..cd869b02bb --- /dev/null +++ b/Documentation/RelNotes/2.25.1.txt @@ -0,0 +1,55 @@ +Git 2.25.1 Release Notes +======================== + +Fixes since v2.25 +----------------- + + * "git commit" gives output similar to "git status" when there is + nothing to commit, but without honoring the advise.statusHints + configuration variable, which has been corrected. + + * has_object_file() said "no" given an object registered to the + system via pretend_object_file(), making it inconsistent with + read_object_file(), causing lazy fetch to attempt fetching an + empty tree from promisor remotes. + + * The code that tries to skip over the entries for the paths in a + single directory using the cache-tree was not careful enough + against corrupt index file. + + * Complete an update to tutorial that encourages "git switch" over + "git checkout" that was done only half-way. + + * Reduce unnecessary round-trip when running "ls-remote" over the + stateless RPC mechanism. + + * "git restore --staged" did not correctly update the cache-tree + structure, resulting in bogus trees to be written afterwards, which + has been corrected. + + * The code recently added to move to the entry beyond the ones in the + same directory in the index in the sparse-cone mode did not count + the number of entries to skip over incorrectly, which has been + corrected. + + * Work around test breakages caused by custom regex engine used in + libasan, when address sanitizer is used with more recent versions + of gcc and clang. + + * "git fetch --refmap=" option has got a better documentation. + + * Corner case bugs in "git clean" that stems from a (necessarily for + performance reasons) awkward calling convention in the directory + enumeration API has been corrected. + + * "git grep --no-index" should not get affected by the contents of + the .gitmodules file but when "--recurse-submodules" is given or + the "submodule.recurse" variable is set, it did. Now these + settings are ignored in the "--no-index" mode. + + * Technical details of the bundle format has been documented. + + * Unhelpful warning messages during documentation build have been + squelched. + +Also contains various documentation updates, code clean-ups and minor fixups. diff --git a/Documentation/RelNotes/2.25.2.txt b/Documentation/RelNotes/2.25.2.txt new file mode 100644 index 0000000000..303c53a17f --- /dev/null +++ b/Documentation/RelNotes/2.25.2.txt @@ -0,0 +1,60 @@ +Git 2.25.2 Release Notes +======================== + +Fixes since v2.25.1 +------------------- + + * Minor bugfixes to "git add -i" that has recently been rewritten in C. + + * An earlier update to show the location of working tree in the error + message did not consider the possibility that a git command may be + run in a bare repository, which has been corrected. + + * The "--recurse-submodules" option of various subcommands did not + work well when run in an alternate worktree, which has been + corrected. + + * Running "git rm" on a submodule failed unnecessarily when + .gitmodules is only cache-dirty, which has been corrected. + + * "git rebase -i" identifies existing commits in its todo file with + their abbreviated object name, which could become ambigous as it + goes to create new commits, and has a mechanism to avoid ambiguity + in the main part of its execution. A few other cases however were + not covered by the protection against ambiguity, which has been + corrected. + + * The index-pack code now diagnoses a bad input packstream that + records the same object twice when it is used as delta base; the + code used to declare a software bug when encountering such an + input, but it is an input error. + + * The code to automatically shrink the fan-out in the notes tree had + an off-by-one bug, which has been killed. + + * "git check-ignore" did not work when the given path is explicitly + marked as not ignored with a negative entry in the .gitignore file. + + * The merge-recursive machinery failed to refresh the cache entry for + a merge result in a couple of places, resulting in an unnecessary + merge failure, which has been fixed. + + * Fix for a bug revealed by a recent change to make the protocol v2 + the default. + + * "git merge signed-tag" while lacking the public key started to say + "No signature", which was utterly wrong. This regression has been + reverted. + + * MinGW's poll() emulation has been improved. + + * "git show" and others gave an object name in raw format in its + error output, which has been corrected to give it in hex. + + * Both "git ls-remote -h" and "git grep -h" give short usage help, + like any other Git subcommand, but it is not unreasonable to expect + that the former would behave the same as "git ls-remote --head" + (there is no other sensible behaviour for the latter). The + documentation has been updated in an attempt to clarify this. + +Also contains various documentation updates, code clean-ups and minor fixups. diff --git a/Documentation/RelNotes/2.25.3.txt b/Documentation/RelNotes/2.25.3.txt new file mode 100644 index 0000000000..15f7f21f10 --- /dev/null +++ b/Documentation/RelNotes/2.25.3.txt @@ -0,0 +1,5 @@ +Git v2.25.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.25.4.txt b/Documentation/RelNotes/2.25.4.txt new file mode 100644 index 0000000000..0dbb5daeec --- /dev/null +++ b/Documentation/RelNotes/2.25.4.txt @@ -0,0 +1,5 @@ +Git v2.25.4 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.26.0.txt b/Documentation/RelNotes/2.26.0.txt new file mode 100644 index 0000000000..3a7a734c26 --- /dev/null +++ b/Documentation/RelNotes/2.26.0.txt @@ -0,0 +1,341 @@ +Git 2.26 Release Notes +====================== + +Updates since v2.25 +------------------- + +Backward compatibility notes + + * "git rebase" uses a different backend that is based on the 'merge' + machinery by default. There are a few known differences in the + behaviour from the traditional machinery based on patch+apply. + + If your workflow is negatively affected by this change, please + report it to git@vger.kernel.org so that we can take a look into + it. After doing so, you can set the 'rebase.backend' configuration + variable to 'apply', in order to use the old default behaviour in + the meantime. + + +UI, Workflows & Features + + * Sample credential helper for using .netrc has been updated to work + out of the box. + + * gpg.minTrustLevel configuration variable has been introduced to + tell various signature verification codepaths the required minimum + trust level. + + * The command line completion (in contrib/) learned to complete + subcommands and arguments to "git worktree". + + * Disambiguation logic to tell revisions and pathspec apart has been + tweaked so that backslash-escaped glob special characters do not + count in the "wildcards are pathspec" rule. + + * One effect of specifying where the GIT_DIR is (either with the + environment variable, or with the "git --git-dir=<where> cmd" + option) is to disable the repository discovery. This has been + placed a bit more stress in the documentation, as new users often + get confused. + + * Two help messages given when "git add" notices the user gave it + nothing to add have been updated to use advise() API. + + * A new version of fsmonitor-watchman hook has been introduced, to + avoid races. + + * "git config" learned to show in which "scope", in addition to in + which file, each config setting comes from. + + * The basic 7 colors learned the brighter counterparts + (e.g. "brightred"). + + * "git sparse-checkout" learned a new "add" subcommand. + + * A configuration element used for credential subsystem can now use + wildcard pattern to specify for which set of URLs the entry + applies. + + * "git clone --recurse-submodules --single-branch" now uses the same + single-branch option when cloning the submodules. + + * "git rm" and "git stash" learns the new "--pathspec-from-file" + option. + + * "git am --show-current-patch" is a way to show the piece of e-mail + for the stopped step, which is not suitable to directly feed "git + apply" (it is designed to be a good "git am" input). It learned a + new option to show only the patch part. + + * Handling of conflicting renames in merge-recursive have further + been made consistent with how existing codepaths try to mimic what + is done to add/add conflicts. + + +Performance, Internal Implementation, Development Support etc. + + * Tell .editorconfig that in this project, *.txt files are indented + with tabs. + + * The test-lint machinery knew to check "VAR=VAL shell_function" + construct, but did not check "VAR= shell_function", which has been + corrected. + + * Replace "git config --bool" calls with "git config --type=bool" in + sample templates. + + * The effort to move "git-add--interactive" to C continues. + + * Improve error message generation for "git submodule add". + + * Preparation of test scripts for the day when the object names will + use SHA-256 continues. + + * Warn programmers about pretend_object_file() that allows the code + to tentatively use in-core objects. + + * The way "git pack-objects" reuses objects stored in existing pack + to generate its result has been improved. + + * The transport protocol version 2 becomes the default one. + + * Traditionally, we avoided threaded grep while searching in objects + (as opposed to files in the working tree) as accesses to the object + layer is not thread-safe. This limitation is getting lifted. + + * "git rebase -i" (and friends) used to unnecessarily check out the + tip of the branch to be rebased, which has been corrected. + + * A low-level API function get_oid(), that accepts various ways to + name an object, used to issue end-user facing error messages + without l10n, which has been updated to be translatable. + + * Unneeded connectivity check is now disabled in a partial clone when + fetching into it. + + * Some rough edges in the sparse-checkout feature, especially around + the cone mode, have been cleaned up. + + * The diff-* plumbing family of subcommands now pay attention to the + diff.wsErrorHighlight configuration, which has been ignored before; + this allows "git add -p" to also show the whitespace problems to + the end user. + + * Some codepaths were given a repository instance as a parameter to + work in the repository, but passed the_repository instance to its + callees, which has been cleaned up (somewhat). + + * Memory footprint and performance of "git name-rev" has been + improved. + + * The object reachability bitmap machinery and the partial cloning + machinery were not prepared to work well together, because some + object-filtering criteria that partial clones use inherently rely + on object traversal, but the bitmap machinery is an optimization + to bypass that object traversal. There however are some cases + where they can work together, and they were taught about them. + + * "git rebase" has learned to use the merge backend (i.e. the + machinery that drives "rebase -i") by default, while allowing + "--apply" option to use the "apply" backend (e.g. the moral + equivalent of "format-patch piped to am"). The rebase.backend + configuration variable can be set to customize. + + * Underlying machinery of "git bisect--helper" is being refactored + into pieces that are more easily reused. + + +Fixes since v2.25 +----------------- + + * "git commit" gives output similar to "git status" when there is + nothing to commit, but without honoring the advise.statusHints + configuration variable, which has been corrected. + + * has_object_file() said "no" given an object registered to the + system via pretend_object_file(), making it inconsistent with + read_object_file(), causing lazy fetch to attempt fetching an + empty tree from promisor remotes. + + * Complete an update to tutorial that encourages "git switch" over + "git checkout" that was done only half-way. + + * C pedantry ;-) fix. + + * The code that tries to skip over the entries for the paths in a + single directory using the cache-tree was not careful enough + against corrupt index file. + + * Reduce unnecessary round-trip when running "ls-remote" over the + stateless RPC mechanism. + + * "git restore --staged" did not correctly update the cache-tree + structure, resulting in bogus trees to be written afterwards, which + has been corrected. + + * The code recently added to move to the entry beyond the ones in the + same directory in the index in the sparse-cone mode did not count + the number of entries to skip over incorrectly, which has been + corrected. + + * Rendering by "git log --graph" of ancestry lines leading to a merge + commit were made suboptimal to waste vertical space a bit with a + recent update, which has been corrected. + + * Work around test breakages caused by custom regex engine used in + libasan, when address sanitizer is used with more recent versions + of gcc and clang. + + * Minor bugfixes to "git add -i" that has recently been rewritten in C. + + * "git fetch --refmap=" option has got a better documentation. + + * "git checkout X" did not correctly fail when X is not a local + branch but could name more than one remote-tracking branches + (i.e. to be dwimmed as the starting point to create a corresponding + local branch), which has been corrected. + (merge fa74180d08 am/checkout-file-and-ref-ref-ambiguity later to maint). + + * Corner case bugs in "git clean" that stems from a (necessarily for + performance reasons) awkward calling convention in the directory + enumeration API has been corrected. + + * A fetch that is told to recursively fetch updates in submodules + inevitably produces reams of output, and it becomes hard to spot + error messages. The command has been taught to enumerate + submodules that had errors at the end of the operation. + (merge 0222540827 es/fetch-show-failed-submodules-atend later to maint). + + * The "--recurse-submodules" option of various subcommands did not + work well when run in an alternate worktree, which has been + corrected. + + * Futureproofing a test not to depend on the current implementation + detail. + + * Running "git rm" on a submodule failed unnecessarily when + .gitmodules is only cache-dirty, which has been corrected. + + * C pedantry ;-) fix. + + * "git grep --no-index" should not get affected by the contents of + the .gitmodules file but when "--recurse-submodules" is given or + the "submodule.recurse" variable is set, it did. Now these + settings are ignored in the "--no-index" mode. + + * Technical details of the bundle format has been documented. + + * Unhelpful warning messages during documentation build have been squelched. + + * "git rebase -i" identifies existing commits in its todo file with + their abbreviated object name, which could become ambiguous as it + goes to create new commits, and has a mechanism to avoid ambiguity + in the main part of its execution. A few other cases however were + not covered by the protection against ambiguity, which has been + corrected. + + * Allow the rebase.missingCommitsCheck configuration to kick in when + "rebase --edit-todo" and "rebase --continue" restarts the procedure. + (merge 5a5445d878 ag/edit-todo-drop-check later to maint). + + * The way "git submodule status" reports an initialized but not yet + populated submodule has not been reimplemented correctly when a + part of the "git submodule" command was rewritten in C, which has + been corrected. + (merge f38c92452d pk/status-of-uncloned-submodule later to maint). + + * The code to automatically shrink the fan-out in the notes tree had + an off-by-one bug, which has been killed. + + * The index-pack code now diagnoses a bad input packstream that + records the same object twice when it is used as delta base; the + code used to declare a software bug when encountering such an + input, but it is an input error. + + + * The code to compute the commit-graph has been taught to use a more + robust way to tell if two object directories refer to the same + thing. + (merge a7df60cac8 tb/commit-graph-object-dir later to maint). + + * "git remote rename X Y" needs to adjust configuration variables + (e.g. branch.<name>.remote) whose value used to be X to Y. + branch.<name>.pushRemote is now also updated. + + * Update to doc-diff. + + * Doc markup fix. + + * "git check-ignore" did not work when the given path is explicitly + marked as not ignored with a negative entry in the .gitignore file. + + * The merge-recursive machinery failed to refresh the cache entry for + a merge result in a couple of places, resulting in an unnecessary + merge failure, which has been fixed. + + * Fix for a bug revealed by a recent change to make the protocol v2 + the default. + + * In rare cases "git worktree add <path>" could think that <path> + was already a registered worktree even when it wasn't and refuse + to add the new worktree. This has been corrected. + (merge bb69b3b009 es/worktree-avoid-duplication-fix later to maint). + + * "git push" should stop from updating a branch that is checked out + when receive.denyCurrentBranch configuration is set, but it failed + to pay attention to checkouts in secondary worktrees. This has + been corrected. + (merge 4d864895a2 hv/receive-denycurrent-everywhere later to maint). + + * "git rebase BASE BRANCH" rebased/updated the tip of BRANCH and + checked it out, even when the BRANCH is checked out in a different + worktree. This has been corrected. + (merge b5cabb4a96 es/do-not-let-rebase-switch-to-protected-branch later to maint). + + * "git describe" in a repository with multiple root commits sometimes + gave up looking for the best tag to describe a given commit with + too early, which has been adjusted. + + * "git merge signed-tag" while lacking the public key started to say + "No signature", which was utterly wrong. This regression has been + reverted. + + * MinGW's poll() emulation has been improved. + + * "git show" and others gave an object name in raw format in its + error output, which has been corrected to give it in hex. + + * "git fetch" over HTTP walker protocol did not show any progress + output. We inherently do not know how much work remains, but still + we can show something not to bore users. + (merge 7655b4119d rs/show-progress-in-dumb-http-fetch later to maint). + + * Both "git ls-remote -h" and "git grep -h" give short usage help, + like any other Git subcommand, but it is not unreasonable to expect + that the former would behave the same as "git ls-remote --head" + (there is no other sensible behaviour for the latter). The + documentation has been updated in an attempt to clarify this. + + * Other code cleanup, docfix, build fix, etc. + (merge d0d0a357a1 am/update-pathspec-f-f-tests later to maint). + (merge f94f7bd00d am/test-pathspec-f-f-error-cases later to maint). + (merge c513a958b6 ss/t6025-modernize later to maint). + (merge b441717256 dl/test-must-fail-fixes later to maint). + (merge d031049da3 mt/sparse-checkout-doc-update later to maint). + (merge 145136a95a jc/skip-prefix later to maint). + (merge 5290d45134 jk/alloc-cleanups later to maint). + (merge 7a9f8ca805 rs/parse-options-concat-dup later to maint). + (merge 517b60564e rs/strbuf-insertstr later to maint). + (merge f696a2b1c8 jk/mailinfo-cleanup later to maint). + (merge de26f02db1 js/test-avoid-pipe later to maint). + (merge a2dc43414c es/doc-mentoring later to maint). + (merge 02bbbe9df9 es/worktree-cleanup later to maint). + (merge 2ce6d075fa rs/micro-cleanups later to maint). + (merge 27f182b3fc rs/blame-typefix-for-fingerprint later to maint). + (merge 3c29e21eb0 ma/test-cleanup later to maint). + (merge 240fc04f81 ag/rebase-remove-redundant-code later to maint). + (merge d68ce906c7 rs/commit-graph-code-simplification later to maint). + (merge a51d9e8f07 rj/t1050-use-test-path-is-file later to maint). + (merge fd0bc17557 kk/complete-diff-color-moved later to maint). + (merge 65bf820d0e en/test-cleanup later to maint). diff --git a/Documentation/RelNotes/2.26.1.txt b/Documentation/RelNotes/2.26.1.txt new file mode 100644 index 0000000000..1b4ecb3fdc --- /dev/null +++ b/Documentation/RelNotes/2.26.1.txt @@ -0,0 +1,5 @@ +Git v2.26.1 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.26.2.txt b/Documentation/RelNotes/2.26.2.txt new file mode 100644 index 0000000000..d434d0c695 --- /dev/null +++ b/Documentation/RelNotes/2.26.2.txt @@ -0,0 +1,5 @@ +Git v2.26.2 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.27.0.txt b/Documentation/RelNotes/2.27.0.txt new file mode 100644 index 0000000000..15518d06c1 --- /dev/null +++ b/Documentation/RelNotes/2.27.0.txt @@ -0,0 +1,525 @@ +Git 2.27 Release Notes +====================== + +Updates since v2.26 +------------------- + +Backward compatibility notes + + * When "git describe C" finds that commit C is pointed by a signed or + annotated tag, which records T as its tagname in the object, the + command gives T as its answer. Even if the user renames or moves + such a tag from its natural location in the "refs/tags/" hierarchy, + "git describe C" would still give T as the answer, but in such a + case "git show T^0" would no longer work as expected. There may be + nothing at "refs/tags/T" or even worse there may be a different tag + instead. + + Starting from this version, "git describe" will always use the + "long" version, as if the "--long" option were given, when giving + its output based on such a misplaced tag to work around the problem. + + * "git pull" issues a warning message until the pull.rebase + configuration variable is explicitly given, which some existing + users may find annoying---those who prefer not to rebase need to + set the variable to false to squelch the warning. + + * The transport protocol version 2, which was promoted to the default + in Git 2.26 release, turned out to have some remaining rough edges, + so it has been demoted from the default. + + +UI, Workflows & Features + + * A handful of options to configure SSL when talking to proxies have + been added. + + * Smudge/clean conversion filters are now given more information + (e.g. the object of the tree-ish in which the blob being converted + appears, in addition to its path, which has already been given). + + * When "git describe C" finds an annotated tag with tagname A to be + the best name to explain commit C, and the tag is stored in a + "wrong" place in the refs/tags hierarchy, e.g. refs/tags/B, the + command gave a warning message but used A (not B) to describe C. + If C is exactly at the tag, the describe output would be "A", but + "git rev-parse A^0" would not be equal as "git rev-parse C^0". The + behavior of the command has been changed to use the "long" form + i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse. + + * "git pull" learned to warn when no pull.rebase configuration + exists, and neither --[no-]rebase nor --ff-only is given (which + would result a merge). + + * "git p4" learned four new hooks and also "--no-verify" option to + bypass them (and the existing "p4-pre-submit" hook). + + * "git pull" shares many options with underlying "git fetch", but + some of them were not documented and some of those that would make + sense to pass down were not passed down. + + * "git rebase" learned the "--no-gpg-sign" option to countermand + commit.gpgSign the user may have. + + * The output from "git format-patch" uses RFC 2047 encoding for + non-ASCII letters on From: and Subject: headers, so that it can + directly be fed to e-mail programs. A new option has been added + to produce these headers in raw. + + * "git log" learned "--show-pulls" that helps pathspec limited + history views; a merge commit that takes the whole change from a + side branch, which is normally omitted from the output, is shown + in addition to the commits that introduce real changes. + + * The interactive input from various codepaths are consolidated and + any prompt possibly issued earlier are fflush()ed before we read. + + * Allow "git rebase" to reapply all local commits, even if the may be + already in the upstream, without checking first. + + * The 'pack.useSparse' configuration variable now defaults to 'true', + enabling an optimization that has been experimental since Git 2.21. + + * "git rebase" happens to call some hooks meant for "checkout" and + "commit" by this was not a designed behaviour than historical + accident. This has been documented. + + * "git merge" learns the "--autostash" option. + + * "sparse-checkout" UI improvements. + + * "git update-ref --stdin" learned a handful of new verbs to let the + user control ref update transactions more explicitly, which helps + as an ingredient to implement two-phase commit-style atomic + ref-updates across multiple repositories. + + * "git commit-graph write" learned different ways to write out split + files. + + * Introduce an extension to the commit-graph to make it efficient to + check for the paths that were modified at each commit using Bloom + filters. + + * The approxidate parser learns to parse seconds with fraction and + ignore fractional part. + + * The userdiff patterns for Markdown documents have been added. + + * The sparse-checkout patterns have been forbidden from excluding all + paths, leaving an empty working tree, for a long time. This + limitation has been lifted. + + * "git restore --staged --worktree" now defaults to take the contents + out of "HEAD", instead of erring out. + + * "git p4" learned to recover from a (broken) state where a directory + and a file are recorded at the same path in the Perforce repository + the same way as their clients do. + + * "git multi-pack-index repack" has been taught to honor some + repack.* configuration variables. + + +Performance, Internal Implementation, Development Support etc. + + * The advise API has been revamped to allow more systematic enumeration of + advice knobs in the future. + + * SHA-256 transition continues. + + * The code to interface with GnuPG has been refactored. + + * "git stash" has kept an escape hatch to use the scripted version + for a few releases, which got stale. It has been removed. + + * Enable tests that require GnuPG on Windows. + + * Minor test usability improvement. + + * Trace2 enhancement to allow logging of the environment variables. + + * Test clean-up continues. + + * Perf-test update. + + * A Windows-specific test element has been made more robust against + misuse from both user's environment and programmer's errors. + + * Various tests have been updated to work around issues found with + shell utilities that come with busybox etc. + + * The config API made mixed uses of int and size_t types to represent + length of various pieces of text it parsed, which has been updated + to use the correct type (i.e. size_t) throughout. + + * The "--decorate-refs" and "--decorate-refs-exclude" options "git + log" takes have learned a companion configuration variable + log.excludeDecoration that sits at the lowest priority in the + family. + + * A new CI job to build and run test suite on linux with musl libc + has been added. + + * Update the CI configuration to use GitHub Actions, retiring the one + based on Azure Pipelines. + + * The directory traversal code had redundant recursive calls which + made its performance characteristics exponential with respect to + the depth of the tree, which was corrected. + + * "git blame" learns to take advantage of the "changed-paths" Bloom + filter stored in the commit-graph file. + + * The "bugreport" tool has been added. + + * The object walk with object filter "--filter=tree:0" can now take + advantage of the pack bitmap when available. + + * Instead of always building all branches at GitHub via Actions, + users can specify which branches to build. + + * Codepaths that show progress meter have been taught to also use the + start_progress() and the stop_progress() calls as a "region" to be + traced. + + * Instead of downloading Windows SDK for CI jobs for windows builds + from an external site (wingit.blob.core.windows.net), use the one + created in the windows-build job, to work around quota issues at + the external site. + + +Fixes since v2.26 +----------------- + + * The real_path() convenience function can easily be misused; with a + bit of code refactoring in the callers' side, its use has been + eliminated. + (merge 49d3c4b481 am/real-path-fix later to maint). + + * Update "git p4" to work with Python 3. + (merge 6bb40ed20a yz/p4-py3 later to maint). + + * The mechanism to prevent "git commit" from making an empty commit + or amending during an interrupted cherry-pick was broken during the + rewrite of "git rebase" in C, which has been corrected. + (merge 430b75f720 pw/advise-rebase-skip later to maint). + + * Fix "git checkout --recurse-submodules" of a nested submodule + hierarchy. + (merge 846f34d351 pb/recurse-submodules-fix later to maint). + + * The "--fork-point" mode of "git rebase" regressed when the command + was rewritten in C back in 2.20 era, which has been corrected. + (merge f08132f889 at/rebase-fork-point-regression-fix later to maint). + + * The import-tars importer (in contrib/fast-import/) used to create + phony files at the top-level of the repository when the archive + contains global PAX headers, which made its own logic to detect and + omit the common leading directory ineffective, which has been + corrected. + (merge c839fcff65 js/import-tars-do-not-make-phony-files-from-pax-headers later to maint). + + * Simplify the commit ancestry connectedness check in a partial clone + repository in which "promised" objects are assumed to be obtainable + lazily on-demand from promisor remote repositories. + (merge 2b98478c6f jt/connectivity-check-optim-in-partial-clone later to maint). + + * The server-end of the v2 protocol to serve "git clone" and "git + fetch" was not prepared to see a delim packets at unexpected + places, which led to a crash. + (merge cacae4329f jk/harden-protocol-v2-delim-handling later to maint). + + * When fed a midx that records no objects, some codepaths tried to + loop from 0 through (num_objects-1), which, due to integer + arithmetic wrapping around, made it nonsense operation with out of + bounds array accesses. The code has been corrected to reject such + an midx file. + (merge 796d61cdc0 dr/midx-avoid-int-underflow later to maint). + + * Utitiles run via the run_command() API were not spawned correctly + on Cygwin, when the paths to them are given as a full path with + backslashes. + (merge 05ac8582bc ak/run-command-on-cygwin-fix later to maint). + + * "git pull --rebase" tried to run a rebase even after noticing that + the pull results in a fast-forward and no rebase is needed nor + sensible, for the past few years due to a mistake nobody noticed. + (merge fbae70ddc6 en/pull-do-not-rebase-after-fast-forwarding later to maint). + + * "git rebase" with the merge backend did not work well when the + rebase.abbreviateCommands configuration was set. + (merge de9f1d3ef4 ag/rebase-merge-allow-ff-under-abbrev-command later to maint). + + * The logic to auto-follow tags by "git clone --single-branch" was + not careful to avoid lazy-fetching unnecessary tags, which has been + corrected. + (merge 167a575e2d jk/use-quick-lookup-in-clone-for-tag-following later to maint). + + * "git rebase -i" did not leave the reflog entries correctly. + (merge 1f6965f994 en/sequencer-reflog-action later to maint). + + * The more aggressive updates to remote-tracking branches we had for + the past 7 years or so were not reflected in the documentation, + which has been corrected. + (merge a44088435c pb/pull-fetch-doc later to maint). + + * We've left the command line parsing of "git log :/a/b/" broken for + about a full year without anybody noticing, which has been + corrected. + (merge 0220461071 jc/missing-ref-store-fix later to maint). + + * Misc fixes for Windows. + (merge 3efc128cd5 js/mingw-fixes later to maint). + + * "git rebase" (again) learns to honor "--no-keep-empty", which lets + the user to discard commits that are empty from the beginning (as + opposed to the ones that become empty because of rebasing). The + interactive rebase also marks commits that are empty in the todo. + (merge 50ed76148a en/rebase-no-keep-empty later to maint). + + * Parsing the host part out of URL for the credential helper has been corrected. + (merge 4c5971e18a jk/credential-parsing-end-of-host-in-URL later to maint). + + * Document the recommended way to abort a failing test early (e.g. by + exiting a loop), which is to say "return 1". + (merge 7cc112dc95 jc/doc-test-leaving-early later to maint). + + * The code that refreshes the last access and modified time of + on-disk packfiles and loose object files have been updated. + (merge 312cd76130 lr/freshen-file-fix later to maint). + + * Validation of push certificate has been made more robust against + timing attacks. + (merge 719483e547 bc/constant-memequal later to maint). + + * The custom hash function used by "git fast-import" has been + replaced with the one from hashmap.c, which gave us a nice + performance boost. + (merge d8410a816b jk/fast-import-use-hashmap later to maint). + + * The "git submodule" command did not initialize a few variables it + internally uses and was affected by variable settings leaked from + the environment. + (merge 65d100c4dd lx/submodule-clear-variables later to maint). + + * Raise the minimum required version of docbook-xsl package to 1.74, + as 1.74.0 was from late 2008, which is more than 10 years old, and + drop compatibility cruft from our documentation suite. + (merge 3c255ad660 ma/doc-discard-docbook-xsl-1.73 later to maint). + + * "git log" learns "--[no-]mailmap" as a synonym to "--[no-]use-mailmap" + (merge 88acccda38 jc/log-no-mailmap later to maint). + + * "git commit-graph write --expire-time=<timestamp>" did not use the + given timestamp correctly, which has been corrected. + (merge b09b785c78 ds/commit-graph-expiry-fix later to maint). + + * Tests update to use "test-chmtime" instead of "touch -t". + (merge e892a56845 ds/t5319-touch-fix later to maint). + + * "git diff" in a partial clone learned to avoid lazy loading blob + objects in more casese when they are not needed. + (merge 95acf11a3d jt/avoid-prefetch-when-able-in-diff later to maint). + + * "git push --atomic" used to show failures for refs that weren't + even pushed, which has been corrected. + (merge dfe1b7f19c jx/atomic-push later to maint). + + * Code in builtin/*, i.e. those can only be called from within + built-in subcommands, that implements bulk of a couple of + subcommands have been moved to libgit.a so that they could be used + by others. + (merge 9460fd48b5 dl/libify-a-few later to maint). + + * Allowing the user to split a patch hunk while "git stash -p" does + not work well; a band-aid has been added to make this (partially) + work better. + + * "git diff-tree --pretty --notes" used to hit an assertion failure, + as it forgot to initialize the notes subsystem. + (merge 5778b22b3d tb/diff-tree-with-notes later to maint). + + * "git range-diff" fixes. + (merge 8d1675eb7f vd/range-diff-with-custom-pretty-format-fix later to maint). + + * "git grep" did not quote a path with unusual character like other + commands (like "git diff", "git status") do, but did quote when run + from a subdirectory, both of which has been corrected. + (merge 45115d8490 mt/grep-cquote-path later to maint). + + * GNU/Hurd is also among the ones that need the fopen() wrapper. + (merge 274a1328fb jc/gnu-hurd-lets-fread-read-dirs later to maint). + + * Those fetching over protocol v2 from linux-next and other kernel + repositories are reporting that v2 often fetches way too much than + needed. + (merge 11c7f2a30b jn/demote-proto2-from-default later to maint). + + * The upload-pack protocol v2 gave up too early before finding a + common ancestor, resulting in a wasteful fetch from a fork of a + project. This has been corrected to match the behaviour of v0 + protocol. + (merge 2f0a093dd6 jt/v2-fetch-nego-fix later to maint). + + * The build procedure did not use the libcurl library and its include + files correctly for a custom-built installation. + (merge 0573831950 jk/build-with-right-curl later to maint). + + * Tighten "git mailinfo" to notice and error out when decoded result + contains NUL in it. + (merge 3919997447 dd/mailinfo-with-nul later to maint). + + * Fix in-core inconsistency after fetching into a shallow repository + that broke the code to write out commit-graph. + (merge 37b9dcabfc tb/reset-shallow later to maint). + + * The commit-graph code exhausted file descriptors easily when it + does not have to. + (merge c8828530b7 tb/commit-graph-fd-exhaustion-fix later to maint). + + * The multi-pack-index left mmapped file descriptors open when it + does not have to. + (merge 6c7ff7cf7f ds/multi-pack-index later to maint). + + * Recent update to Homebrew used by macOS folks breaks build by + moving gettext library and necessary headers. + (merge a0b3108618 ds/build-homebrew-gettext-fix later to maint). + + * Incompatible options "--root" and "--fork-point" of "git rebase" + have been marked and documented as being incompatible. + (merge a35413c378 en/rebase-root-and-fork-point-are-incompatible later to maint). + + * Error and verbose trace messages from "git push" did not redact + credential material embedded in URLs. + (merge d192fa5006 js/anonymise-push-url-in-errors later to maint). + + * Update the parser used for credential.<URL>.<variable> + configuration, to handle <URL>s with '/' in them correctly. + (merge b44d0118ac bc/wildcard-credential later to maint). + + * Recent updates broke parsing of "credential.<url>.<key>" where + <url> is not a full URL (e.g. [credential "https://"] helper = ...) + stopped working, which has been corrected. + (merge 9a121b0d22 js/partial-urlmatch-2.17 later to maint). + (merge cd93e6c029 js/partial-urlmatch later to maint). + + * Some of the files commit-graph subsystem keeps on disk did not + correctly honor the core.sharedRepository settings and some were + left read-write. + + * In error messages that "git switch" mentions its option to create a + new branch, "-b/-B" options were shown, where "-c/-C" options + should be, which has been corrected. + (merge 7c16ef7577 dl/switch-c-option-in-error-message later to maint). + + * With the recent tightening of the code that is used to parse + various parts of a URL for use in the credential subsystem, a + hand-edited credential-store file causes the credential helper to + die, which is a bit too harsh to the users. Demote the error + behaviour to just ignore and keep using well-formed lines instead. + (merge c03859a665 cb/credential-store-ignore-bogus-lines later to maint). + + * The samples in the credential documentation has been updated to + make it clear that we depict what would appear in the .git/config + file, by adding appropriate quotes as needed.. + (merge 177681a07e jk/credential-sample-update later to maint). + + * "git branch" and other "for-each-ref" variants accepted multiple + --sort=<key> options in the increasing order of precedence, but it + had a few breakages around "--ignore-case" handling, and tie-breaking + with the refname, which have been fixed. + (merge 7c5045fc18 jk/for-each-ref-multi-key-sort-fix later to maint). + + * The coding guideline for shell scripts instructed to refer to a + variable with dollar-sign inside arithmetic expansion to work + around a bug in old versions of dash, which is a thing of the past. + Now we are not forbidden from writing $((var+1)). + (merge 32b5fe7f0e jk/arith-expansion-coding-guidelines later to maint). + + * The <stdlib.h> header on NetBSD brings in its own definition of + hmac() function (eek), which conflicts with our own and unrelated + function with the same name. Our function has been renamed to work + around the issue. + (merge 3013118eb8 cb/avoid-colliding-with-netbsd-hmac later to maint). + + * The basic test did not honor $TEST_SHELL_PATH setting, which has + been corrected. + (merge 0555e4af58 cb/t0000-use-the-configured-shell later to maint). + + * Minor in-code comments and documentation updates around credential + API. + (merge 1aed817f99 cb/credential-doc-fixes later to maint). + + * Teach "am", "commit", "merge" and "rebase", when they are run with + the "--quiet" option, to pass "--quiet" down to "gc --auto". + (merge 7c3e9e8cfb jc/auto-gc-quiet later to maint). + + * The code to skip unmerged paths in the index when sparse checkout + is in use would have made out-of-bound access of the in-core index + when the last path was unmerged, which has been corrected. + + * Serving a "git fetch" client over "git://" and "ssh://" protocols + using the on-wire protocol version 2 was buggy on the server end + when the client needs to make a follow-up request to + e.g. auto-follow tags. + (merge 08450ef791 cc/upload-pack-v2-fetch-fix later to maint). + + * "git bisect replay" had trouble with input files when they used + CRLF line ending, which has been corrected. + (merge 6c722cbe5a cw/bisect-replay-with-dos later to maint). + + * "rebase -i" segfaulted when rearranging a sequence that has a + fix-up that applies another fix-up (which may or may not be a + fix-up of yet another step). + (merge 02471e7e20 js/rebase-autosquash-double-fixup-fix later to maint). + + * "git fsck" ensures that the paths recorded in tree objects are + sorted and without duplicates, but it failed to notice a case where + a blob is followed by entries that sort before a tree with the same + name. This has been corrected. + (merge 9068cfb20f rs/fsck-duplicate-names-in-trees later to maint). + + * Code clean-up by removing a compatibility implementation of a + function we no longer use. + (merge 84b0115f0d cb/no-more-gmtime later to maint). + + * When a binary file gets modified and renamed on both sides of history + to different locations, both files would be written to the working + tree but both would have the contents from "ours". This has been + corrected so that the path from each side gets their original content. + + * Fix for a copy-and-paste error introduced during 2.20 era. + (merge e68a5272b1 ds/multi-pack-verify later to maint). + + * Update an unconditional use of "grep -a" with a perl script in a test. + (merge 1eb7371236 dd/t5703-grep-a-fix later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge 564956f358 jc/maintain-doc later to maint). + (merge 7422b2a0a1 sg/commit-slab-clarify-peek later to maint). + (merge 9c688735f6 rs/doc-passthru-fetch-options later to maint). + (merge 757c2ba3e2 en/oidset-uninclude-hashmap later to maint). + (merge 8312aa7d74 jc/config-tar later to maint). + (merge d00a5bdd50 ss/submodule-foreach-cb later to maint). + (merge 64d1022e14 ar/test-style-fixes later to maint). + (merge 4a465443a6 ds/doc-clone-filter later to maint). + (merge bb2dbe301b jk/t3419-drop-expensive-tests later to maint). + (merge d3507cc712 js/test-junit-finalization-fix later to maint). + (merge 2149b6748f bc/faq later to maint). + (merge 12dc0879f1 jk/test-cleanup later to maint). + (merge 344420bf0f pb/rebase-doc-typofix later to maint). + (merge 7cd54d37dc dl/wrapper-fix-indentation later to maint). + (merge 78725ebda9 jc/allow-strlen-substitution-in-shell-scripts later to maint). + (merge 2ecfcdecc6 jm/gitweb-fastcgi-utf8 later to maint). + (merge 0740d0a5d3 jk/oid-array-cleanups later to maint). + (merge a1aba0c95c js/t0007-typofix later to maint). + (merge 76ba7fa225 ma/config-doc-fix later to maint). + (merge 826f0c0df2 js/subtree-doc-update-to-asciidoctor-2 later to maint). + (merge 88eaf361e0 eb/mboxrd-doc later to maint). + (merge 051cc54941 tm/zsh-complete-switch-restore later to maint). + (merge 39102cf4fe ms/doc-revision-illustration-fix later to maint). + (merge 4d9378bfad eb/gitweb-more-trailers later to maint). + (merge bdccbf7047 mt/doc-worktree-ref later to maint). + (merge ce9baf234f dl/push-recurse-submodules-fix later to maint). + (merge 4153274052 bc/doc-credential-helper-value later to maint). + (merge 5c7bb0146e jc/codingstyle-compare-with-null later to maint). diff --git a/Documentation/RelNotes/2.28.0.txt b/Documentation/RelNotes/2.28.0.txt new file mode 100644 index 0000000000..6baf781380 --- /dev/null +++ b/Documentation/RelNotes/2.28.0.txt @@ -0,0 +1,236 @@ +Git 2.28 Release Notes +====================== + +Updates since v2.27 +------------------- + +Backward compatibility notes + + * "fetch.writeCommitGraph" is deemed to be still a bit too risky and + is no longer part of the "feature.experimental" set. + + +UI, Workflows & Features + + * The commands in the "diff" family learned to honor "diff.relative" + configuration variable. + + * The check in "git fsck" to ensure that the tree objects are sorted + still had corner cases it missed unsorted entries. + + * The interface to redact sensitive information in the trace output + has been simplified. + + * The command line completion (in contrib/) learned to complete + options that the "git switch" command takes. + + * "git diff" used to take arguments in random and nonsense range + notation, e.g. "git diff A..B C", "git diff A..B C...D", etc., + which has been cleaned up. + + * "git diff-files" has been taught to say paths that are marked as + intent-to-add are new files, not modified from an empty blob. + + * "git status" learned to report the status of sparse checkout. + + * "git difftool" has trouble dealing with paths added to the index + with the intent-to-add bit. + + * "git fast-export --anonymize" learned to take customized mapping to + allow its users to tweak its output more usable for debugging. + + * The command line completion support (in contrib/) used to be + prepared to work with "set -u" but recent changes got a bit more + sloppy. This has been corrected. + + * "git gui" now allows opening work trees from the start-up dialog. + + +Performance, Internal Implementation, Development Support etc. + + * Code optimization for a common case. + (merge 8777616e4d an/merge-single-strategy-optim later to maint). + + * We've adopted a convention that any on-stack structure can be + initialized to have zero values in all fields with "= { 0 }", + even when the first field happens to be a pointer, but sparse + complained that a null pointer should be spelled NULL for a long + time. Start using -Wno-universal-initializer option to squelch + it (the latest sparse has it on by default). + + * "git log -L..." now takes advantage of the "which paths are touched + by this commit?" info stored in the commit-graph system. + + * As FreeBSD is not the only platform whose regexp library reports + a REG_ILLSEQ error when fed invalid UTF-8, add logic to detect that + automatically and skip the affected tests. + + * "git bugreport" learns to report what shell is in use. + + * Support for GIT_CURL_VERBOSE has been rewritten in terms of + GIT_TRACE_CURL. + + * Preliminary clean-ups around refs API, plus file format + specification documentation for the reftable backend. + + * Workaround breakage in MSVC build, where "curl-config --cflags" + gives settings appropriate for GCC build. + + * Code clean-up of "git clean" resulted in a fix of recent + performance regression. + + * Code clean-up in the codepath that serves "git fetch" continues. + + * "git merge-base --is-ancestor" is taught to take advantage of the + commit graph. + + * Rewrite of parts of the scripted "git submodule" Porcelain command + continues; this time it is "git submodule set-branch" subcommand's + turn. + + * The "fetch/clone" protocol has been updated to allow the server to + instruct the clients to grab pre-packaged packfile(s) in addition + to the packed object data coming over the wire. + + * A misdesigned strbuf_write_fd() function has been retired. + + * SHA-256 migration work continues, including CVS/SVN interface. + + * A few fields in "struct commit" that do not have to always be + present have been moved to commit slabs. + + * API cleanup for get_worktrees() + + * By renumbering object flag bits, "struct object" managed to lose + bloated inter-field padding. + + * The name of the primary branch in existing repositories, and the + default name used for the first branch in newly created + repositories, is made configurable, so that we can eventually wean + ourselves off of the hardcoded 'master'. + + * The effort to avoid using test_must_fail on non-git command continues. + + * In 2.28-rc0, we corrected a bug that some repository extensions are + honored by mistake even in a version 0 repositories (these + configuration variables in extensions.* namespace were supposed to + have special meaning in repositories whose version numbers are 1 or + higher), but this was a bit too big a change. The behaviour in + recent versions of Git where certain extensions.* were honored by + mistake even in version 0 repositories has been restored. + + +Fixes since v2.27 +----------------- + + * The "--prepare-p4-only" option of "git p4" is supposed to stop + after replaying one changeset, but kept going (by mistake?) + + * The error message from "git checkout -b foo -t bar baz" was + confusing. + + * Some repositories in the wild have commits that record nonsense + committer timezone (e.g. rails.git); "git fast-import" learned an + option to pass these nonsense timestamps intact to allow recreating + existing repositories as-is. + (merge d42a2fb72f en/fast-import-looser-date later to maint). + + * The command line completion script (in contrib/) tried to complete + "git stash -p" as if it were "git stash push -p", but it was too + aggressive and also affected "git stash show -p", which has been + corrected. + (merge fffd0cf520 vs/complete-stash-show-p-fix later to maint). + + * On-the-wire protocol v2 easily falls into a deadlock between the + remote-curl helper and the fetch-pack process when the server side + prematurely throws an error and disconnects. The communication has + been updated to make it more robust. + + * "git checkout -p" did not handle a newly added path at all. + (merge 2c8bd8471a js/checkout-p-new-file later to maint). + + * The code to parse "git bisect start" command line was lax in + validating the arguments. + (merge 4d9005ff5d cb/bisect-helper-parser-fix later to maint). + + * Reduce memory usage during "diff --quiet" in a worktree with too + many stat-unmatched paths. + (merge d2d7fbe129 jk/diff-memuse-optim-with-stat-unmatch later to maint). + + * The reflog entries for "git clone" and "git fetch" did not + anonymize the URL they operated on. + (merge 46da295a77 js/reflog-anonymize-for-clone-and-fetch later to maint). + + * The behaviour of "sparse-checkout" in the state "git clone + --no-checkout" left was changed accidentally in 2.27, which has + been corrected. + + * Use of negative pathspec, while collecting paths including + untracked ones in the working tree, was broken. + + * The same worktree directory must be registered only once, but + "git worktree move" allowed this invariant to be violated, which + has been corrected. + (merge 810382ed37 es/worktree-duplicate-paths later to maint). + + * The effect of sparse checkout settings on submodules is documented. + (merge e7d7c73249 en/sparse-with-submodule-doc later to maint). + + * Code clean-up around "git branch" with a minor bugfix. + (merge dc44639904 dl/branch-cleanup later to maint). + + * A branch name used in a test has been clarified to match what is + going on. + (merge 08dc26061f pb/t4014-unslave later to maint). + + * An in-code comment in "git diff" has been updated. + (merge c592fd4c83 dl/diff-usage-comment-update later to maint). + + * The documentation and some tests have been adjusted for the recent + renaming of "pu" branch to "seen". + (merge 6dca5dbf93 js/pu-to-seen later to maint). + + * The code to push changes over "dumb" HTTP had a bad interaction + with the commit reachability code due to incorrect allocation of + object flag bits, which has been corrected. + (merge 64472d15e9 bc/http-push-flagsfix later to maint). + + * "git send-email --in-reply-to=<msg>" did not use the In-Reply-To: + header with the value given from the command line, and let it be + overridden by the value on In-Reply-To: header in the messages + being sent out (if exists). + (merge f9f60d7066 ra/send-email-in-reply-to-from-command-line-wins later to maint). + + * "git log -Lx,y:path --before=date" lost track of where the range + should be because it didn't take the changes made by the youngest + commits that are omitted from the output into account. + + * When "fetch.writeCommitGraph" configuration is set in a shallow + repository and a fetch moves the shallow boundary, we wrote out + broken commit-graph files that do not match the reality, which has + been corrected. + + * "git checkout" failed to catch an error from fstat() after updating + a path in the working tree. + (merge 35e6e212fd mt/entry-fstat-fallback-fix later to maint). + + * When an aliased command, whose output is piped to a pager by git, + gets killed by a signal, the pager got into a funny state, which + has been corrected (again). + (merge c0d73a59c9 ta/wait-on-aliased-commands-upon-signal later to maint). + + * The code to produce progress output from "git commit-graph --write" + had a few breakages, which have been fixed. + + * Other code cleanup, docfix, build fix, etc. + (merge 2c31a7aa44 jx/pkt-line-doc-count-fix later to maint). + (merge d63ae31962 cb/t5608-cleanup later to maint). + (merge 788db145c7 dl/t-readme-spell-git-correctly later to maint). + (merge 45a87a83bb dl/python-2.7-is-the-floor-version later to maint). + (merge b75a219904 es/advertise-contribution-doc later to maint). + (merge 0c9a4f638a rs/pull-leakfix later to maint). + (merge d546fe2874 rs/commit-reach-leakfix later to maint). + (merge 087bf5409c mk/pb-pretty-email-without-domain-part-fix later to maint). + (merge 5f4ee57ad9 es/worktree-code-cleanup later to maint). + (merge 0172f7834a cc/cat-file-usage-update later to maint). + (merge 81de0c01cf ma/rebase-doc-typofix later to maint). diff --git a/Documentation/RelNotes/2.29.0.txt b/Documentation/RelNotes/2.29.0.txt new file mode 100644 index 0000000000..72e6682dd6 --- /dev/null +++ b/Documentation/RelNotes/2.29.0.txt @@ -0,0 +1,67 @@ +Git 2.29 Release Notes +====================== + +Updates since v2.28 +------------------- + +UI, Workflows & Features + + * "git help log" has been enhanced by sharing more material from the + documentation for the underlying "git rev-list" command. + + * "git for-each-ref --format=<>" learned %(contents:size). + + +Performance, Internal Implementation, Development Support etc. + + * The changed-path Bloom filter is improved using ideas from an + independent implementation. + + * Updates to the changed-paths bloom filter. + + * The test framework has been updated so that most tests will run + with predictable (artificial) timestamps. + + * Preliminary clean-up of the refs API in preparation for adding a + new refs backend "reftable". + + * Dev support to limit the use of test_must_fail to only git commands. + + +Fixes since v2.28 +----------------- + + * "git clone --separate-git-dir=$elsewhere" used to stomp on the + contents of the existing directory $elsewhere, which has been + taught to fail when $elsewhere is not an empty directory. + (merge dfaa209a79 bw/fail-cloning-into-non-empty later to maint). + + + * With the base fix to 2.27 regresion, any new extensions in a v0 + repository would still be silently honored, which is not quite + right. Instead, complain and die loudly. + (merge ec91ffca04 jk/reject-newer-extensions-in-v0 later to maint). + + * Fetching from a lazily cloned repository resulted at the server + side in attempts to lazy fetch objects that the client side has, + many of which will not be available from the third-party anyway. + (merge 77aa0941ce jt/avoid-lazy-fetching-upon-have-check later to maint). + + * Fix to an ancient bug caused by an over-eager attempt for + optimization. + (merge a98f7fb366 rs/add-index-entry-optim-fix later to maint). + + * Pushing a ref whose name contains non-ASCII character with the + "--force-with-lease" option did not work over smart HTTP protocol, + which has been corrected. + (merge cd85b447bf bc/push-cas-cquoted-refname later to maint). + + * "git mv src dst", when src is an unmerged path, errored out + correctly but with an incorrect error message to claim that src is + not tracked, which has been clarified. + (merge 9b906af657 ct/mv-unmerged-path-error later to maint). + + * Fix to a regression introduced during 2.27 cycle. + (merge cada7308ad en/fill-directory-exponential later to maint). + + * Other code cleanup, docfix, build fix, etc. diff --git a/Documentation/RelNotes/2.3.0.txt b/Documentation/RelNotes/2.3.0.txt new file mode 100644 index 0000000000..e3c639c840 --- /dev/null +++ b/Documentation/RelNotes/2.3.0.txt @@ -0,0 +1,300 @@ +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/Documentation/RelNotes/2.3.1.txt b/Documentation/RelNotes/2.3.1.txt new file mode 100644 index 0000000000..cf96186288 --- /dev/null +++ b/Documentation/RelNotes/2.3.1.txt @@ -0,0 +1,52 @@ +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/Documentation/RelNotes/2.3.10.txt b/Documentation/RelNotes/2.3.10.txt new file mode 100644 index 0000000000..20c2d2cacc --- /dev/null +++ b/Documentation/RelNotes/2.3.10.txt @@ -0,0 +1,18 @@ +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/Documentation/RelNotes/2.3.2.txt b/Documentation/RelNotes/2.3.2.txt new file mode 100644 index 0000000000..93462e45c2 --- /dev/null +++ b/Documentation/RelNotes/2.3.2.txt @@ -0,0 +1,79 @@ +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/Documentation/RelNotes/2.3.3.txt b/Documentation/RelNotes/2.3.3.txt new file mode 100644 index 0000000000..850dc68ede --- /dev/null +++ b/Documentation/RelNotes/2.3.3.txt @@ -0,0 +1,39 @@ +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. + + * Documentation 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/Documentation/RelNotes/2.3.4.txt b/Documentation/RelNotes/2.3.4.txt new file mode 100644 index 0000000000..094c7b853b --- /dev/null +++ b/Documentation/RelNotes/2.3.4.txt @@ -0,0 +1,32 @@ +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/Documentation/RelNotes/2.3.5.txt b/Documentation/RelNotes/2.3.5.txt new file mode 100644 index 0000000000..5b309db689 --- /dev/null +++ b/Documentation/RelNotes/2.3.5.txt @@ -0,0 +1,44 @@ +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/Documentation/RelNotes/2.3.6.txt b/Documentation/RelNotes/2.3.6.txt new file mode 100644 index 0000000000..432f770ef3 --- /dev/null +++ b/Documentation/RelNotes/2.3.6.txt @@ -0,0 +1,13 @@ +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/Documentation/RelNotes/2.3.7.txt b/Documentation/RelNotes/2.3.7.txt new file mode 100644 index 0000000000..5769184081 --- /dev/null +++ b/Documentation/RelNotes/2.3.7.txt @@ -0,0 +1,21 @@ +Git v2.3.7 Release Notes +======================== + +Fixes since v2.3.6 +------------------ + + * An earlier update to the parser that dissects 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/Documentation/RelNotes/2.3.8.txt b/Documentation/RelNotes/2.3.8.txt new file mode 100644 index 0000000000..0b67268a96 --- /dev/null +++ b/Documentation/RelNotes/2.3.8.txt @@ -0,0 +1,22 @@ +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/Documentation/RelNotes/2.3.9.txt b/Documentation/RelNotes/2.3.9.txt new file mode 100644 index 0000000000..1a2ad3235a --- /dev/null +++ b/Documentation/RelNotes/2.3.9.txt @@ -0,0 +1,9 @@ +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/Documentation/RelNotes/2.4.0.txt b/Documentation/RelNotes/2.4.0.txt new file mode 100644 index 0000000000..cde64be535 --- /dev/null +++ b/Documentation/RelNotes/2.4.0.txt @@ -0,0 +1,514 @@ +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/Documentation/RelNotes/2.4.1.txt b/Documentation/RelNotes/2.4.1.txt new file mode 100644 index 0000000000..a65a6c5829 --- /dev/null +++ b/Documentation/RelNotes/2.4.1.txt @@ -0,0 +1,40 @@ +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/Documentation/RelNotes/2.4.10.txt b/Documentation/RelNotes/2.4.10.txt new file mode 100644 index 0000000000..702d8d4e22 --- /dev/null +++ b/Documentation/RelNotes/2.4.10.txt @@ -0,0 +1,18 @@ +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/Documentation/RelNotes/2.4.11.txt b/Documentation/RelNotes/2.4.11.txt new file mode 100644 index 0000000000..723360295c --- /dev/null +++ b/Documentation/RelNotes/2.4.11.txt @@ -0,0 +1,11 @@ +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/Documentation/RelNotes/2.4.12.txt b/Documentation/RelNotes/2.4.12.txt new file mode 100644 index 0000000000..7d15f94725 --- /dev/null +++ b/Documentation/RelNotes/2.4.12.txt @@ -0,0 +1,12 @@ +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/Documentation/RelNotes/2.4.2.txt b/Documentation/RelNotes/2.4.2.txt new file mode 100644 index 0000000000..250cdc423c --- /dev/null +++ b/Documentation/RelNotes/2.4.2.txt @@ -0,0 +1,45 @@ +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/Documentation/RelNotes/2.4.3.txt b/Documentation/RelNotes/2.4.3.txt new file mode 100644 index 0000000000..422e930aa2 --- /dev/null +++ b/Documentation/RelNotes/2.4.3.txt @@ -0,0 +1,76 @@ +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 portable 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/Documentation/RelNotes/2.4.4.txt b/Documentation/RelNotes/2.4.4.txt new file mode 100644 index 0000000000..f1ccd001be --- /dev/null +++ b/Documentation/RelNotes/2.4.4.txt @@ -0,0 +1,35 @@ +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/Documentation/RelNotes/2.4.5.txt b/Documentation/RelNotes/2.4.5.txt new file mode 100644 index 0000000000..568297ccb7 --- /dev/null +++ b/Documentation/RelNotes/2.4.5.txt @@ -0,0 +1,28 @@ +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/Documentation/RelNotes/2.4.6.txt b/Documentation/RelNotes/2.4.6.txt new file mode 100644 index 0000000000..b53f353939 --- /dev/null +++ b/Documentation/RelNotes/2.4.6.txt @@ -0,0 +1,23 @@ +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/Documentation/RelNotes/2.4.7.txt b/Documentation/RelNotes/2.4.7.txt new file mode 100644 index 0000000000..b3ac412b82 --- /dev/null +++ b/Documentation/RelNotes/2.4.7.txt @@ -0,0 +1,53 @@ +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/Documentation/RelNotes/2.4.8.txt b/Documentation/RelNotes/2.4.8.txt new file mode 100644 index 0000000000..ad946b2673 --- /dev/null +++ b/Documentation/RelNotes/2.4.8.txt @@ -0,0 +1,21 @@ +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/Documentation/RelNotes/2.4.9.txt b/Documentation/RelNotes/2.4.9.txt new file mode 100644 index 0000000000..09af9ddbc7 --- /dev/null +++ b/Documentation/RelNotes/2.4.9.txt @@ -0,0 +1,9 @@ +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/Documentation/RelNotes/2.5.0.txt b/Documentation/RelNotes/2.5.0.txt new file mode 100644 index 0000000000..84723f912a --- /dev/null +++ b/Documentation/RelNotes/2.5.0.txt @@ -0,0 +1,564 @@ +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 + cf. <7vtzf77wjp.fsf@gitster.siamese.dyndns.org> 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/Documentation/RelNotes/2.5.1.txt b/Documentation/RelNotes/2.5.1.txt new file mode 100644 index 0000000000..b70553308a --- /dev/null +++ b/Documentation/RelNotes/2.5.1.txt @@ -0,0 +1,65 @@ +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/Documentation/RelNotes/2.5.2.txt b/Documentation/RelNotes/2.5.2.txt new file mode 100644 index 0000000000..3f749398bb --- /dev/null +++ b/Documentation/RelNotes/2.5.2.txt @@ -0,0 +1,63 @@ +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/Documentation/RelNotes/2.5.3.txt b/Documentation/RelNotes/2.5.3.txt new file mode 100644 index 0000000000..d1436857cb --- /dev/null +++ b/Documentation/RelNotes/2.5.3.txt @@ -0,0 +1,17 @@ +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/Documentation/RelNotes/2.5.4.txt b/Documentation/RelNotes/2.5.4.txt new file mode 100644 index 0000000000..b8a2f93ee7 --- /dev/null +++ b/Documentation/RelNotes/2.5.4.txt @@ -0,0 +1,18 @@ +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/Documentation/RelNotes/2.5.5.txt b/Documentation/RelNotes/2.5.5.txt new file mode 100644 index 0000000000..37eae9a2d9 --- /dev/null +++ b/Documentation/RelNotes/2.5.5.txt @@ -0,0 +1,11 @@ +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/Documentation/RelNotes/2.5.6.txt b/Documentation/RelNotes/2.5.6.txt new file mode 100644 index 0000000000..9cd025bb1c --- /dev/null +++ b/Documentation/RelNotes/2.5.6.txt @@ -0,0 +1,12 @@ +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/Documentation/RelNotes/2.6.0.txt b/Documentation/RelNotes/2.6.0.txt new file mode 100644 index 0000000000..7288aaf716 --- /dev/null +++ b/Documentation/RelNotes/2.6.0.txt @@ -0,0 +1,370 @@ +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/Documentation/RelNotes/2.6.1.txt b/Documentation/RelNotes/2.6.1.txt new file mode 100644 index 0000000000..f37ea89cda --- /dev/null +++ b/Documentation/RelNotes/2.6.1.txt @@ -0,0 +1,18 @@ +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/Documentation/RelNotes/2.6.2.txt b/Documentation/RelNotes/2.6.2.txt new file mode 100644 index 0000000000..5b65e35245 --- /dev/null +++ b/Documentation/RelNotes/2.6.2.txt @@ -0,0 +1,65 @@ +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/Documentation/RelNotes/2.6.3.txt b/Documentation/RelNotes/2.6.3.txt new file mode 100644 index 0000000000..fc6fe1711f --- /dev/null +++ b/Documentation/RelNotes/2.6.3.txt @@ -0,0 +1,111 @@ +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/Documentation/RelNotes/2.6.4.txt b/Documentation/RelNotes/2.6.4.txt new file mode 100644 index 0000000000..b0256a2dc9 --- /dev/null +++ b/Documentation/RelNotes/2.6.4.txt @@ -0,0 +1,63 @@ +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/Documentation/RelNotes/2.6.5.txt b/Documentation/RelNotes/2.6.5.txt new file mode 100644 index 0000000000..f0924b62e0 --- /dev/null +++ b/Documentation/RelNotes/2.6.5.txt @@ -0,0 +1,58 @@ +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/Documentation/RelNotes/2.6.6.txt b/Documentation/RelNotes/2.6.6.txt new file mode 100644 index 0000000000..023ad85ec6 --- /dev/null +++ b/Documentation/RelNotes/2.6.6.txt @@ -0,0 +1,11 @@ +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/Documentation/RelNotes/2.6.7.txt b/Documentation/RelNotes/2.6.7.txt new file mode 100644 index 0000000000..1335de49a6 --- /dev/null +++ b/Documentation/RelNotes/2.6.7.txt @@ -0,0 +1,12 @@ +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/Documentation/RelNotes/2.7.0.txt b/Documentation/RelNotes/2.7.0.txt new file mode 100644 index 0000000000..e3cbf3a73c --- /dev/null +++ b/Documentation/RelNotes/2.7.0.txt @@ -0,0 +1,414 @@ +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 re-encode 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/Documentation/RelNotes/2.7.1.txt b/Documentation/RelNotes/2.7.1.txt new file mode 100644 index 0000000000..6323feaf64 --- /dev/null +++ b/Documentation/RelNotes/2.7.1.txt @@ -0,0 +1,87 @@ +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_pattern_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/Documentation/RelNotes/2.7.2.txt b/Documentation/RelNotes/2.7.2.txt new file mode 100644 index 0000000000..4feef76704 --- /dev/null +++ b/Documentation/RelNotes/2.7.2.txt @@ -0,0 +1,41 @@ +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/Documentation/RelNotes/2.7.3.txt b/Documentation/RelNotes/2.7.3.txt new file mode 100644 index 0000000000..f618d71efd --- /dev/null +++ b/Documentation/RelNotes/2.7.3.txt @@ -0,0 +1,62 @@ +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 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/Documentation/RelNotes/2.7.4.txt b/Documentation/RelNotes/2.7.4.txt new file mode 100644 index 0000000000..883ae896fe --- /dev/null +++ b/Documentation/RelNotes/2.7.4.txt @@ -0,0 +1,11 @@ +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/Documentation/RelNotes/2.7.5.txt b/Documentation/RelNotes/2.7.5.txt new file mode 100644 index 0000000000..83559ce3b2 --- /dev/null +++ b/Documentation/RelNotes/2.7.5.txt @@ -0,0 +1,14 @@ +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/Documentation/RelNotes/2.7.6.txt b/Documentation/RelNotes/2.7.6.txt new file mode 100644 index 0000000000..4c6d1dcd4a --- /dev/null +++ b/Documentation/RelNotes/2.7.6.txt @@ -0,0 +1,25 @@ +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/Documentation/RelNotes/2.8.0.txt b/Documentation/RelNotes/2.8.0.txt new file mode 100644 index 0000000000..27320b6a9f --- /dev/null +++ b/Documentation/RelNotes/2.8.0.txt @@ -0,0 +1,439 @@ +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 programs 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_pattern_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/Documentation/RelNotes/2.8.1.txt b/Documentation/RelNotes/2.8.1.txt new file mode 100644 index 0000000000..ef6d80b008 --- /dev/null +++ b/Documentation/RelNotes/2.8.1.txt @@ -0,0 +1,9 @@ +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/Documentation/RelNotes/2.8.2.txt b/Documentation/RelNotes/2.8.2.txt new file mode 100644 index 0000000000..447b1933a8 --- /dev/null +++ b/Documentation/RelNotes/2.8.2.txt @@ -0,0 +1,70 @@ +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/Documentation/RelNotes/2.8.3.txt b/Documentation/RelNotes/2.8.3.txt new file mode 100644 index 0000000000..a63825ed87 --- /dev/null +++ b/Documentation/RelNotes/2.8.3.txt @@ -0,0 +1,101 @@ +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 https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/ + and https://lore.kernel.org/git/20150811100527.GW14466@dinwoodie.org/. + + * "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/Documentation/RelNotes/2.8.4.txt b/Documentation/RelNotes/2.8.4.txt new file mode 100644 index 0000000000..f4e2552836 --- /dev/null +++ b/Documentation/RelNotes/2.8.4.txt @@ -0,0 +1,69 @@ +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/Documentation/RelNotes/2.8.5.txt b/Documentation/RelNotes/2.8.5.txt new file mode 100644 index 0000000000..7bd179fa12 --- /dev/null +++ b/Documentation/RelNotes/2.8.5.txt @@ -0,0 +1,12 @@ +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/Documentation/RelNotes/2.8.6.txt b/Documentation/RelNotes/2.8.6.txt new file mode 100644 index 0000000000..d8db55d920 --- /dev/null +++ b/Documentation/RelNotes/2.8.6.txt @@ -0,0 +1,4 @@ +Git v2.8.6 Release Notes +======================== + +This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/Documentation/RelNotes/2.9.0.txt b/Documentation/RelNotes/2.9.0.txt new file mode 100644 index 0000000000..991640119a --- /dev/null +++ b/Documentation/RelNotes/2.9.0.txt @@ -0,0 +1,512 @@ +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 https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/ + + * "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/Documentation/RelNotes/2.9.1.txt b/Documentation/RelNotes/2.9.1.txt new file mode 100644 index 0000000000..338394097e --- /dev/null +++ b/Documentation/RelNotes/2.9.1.txt @@ -0,0 +1,117 @@ +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/Documentation/RelNotes/2.9.2.txt b/Documentation/RelNotes/2.9.2.txt new file mode 100644 index 0000000000..2620003dcf --- /dev/null +++ b/Documentation/RelNotes/2.9.2.txt @@ -0,0 +1,13 @@ +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/Documentation/RelNotes/2.9.3.txt b/Documentation/RelNotes/2.9.3.txt new file mode 100644 index 0000000000..305e08062b --- /dev/null +++ b/Documentation/RelNotes/2.9.3.txt @@ -0,0 +1,170 @@ +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 usually 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/Documentation/RelNotes/2.9.4.txt b/Documentation/RelNotes/2.9.4.txt new file mode 100644 index 0000000000..9768293831 --- /dev/null +++ b/Documentation/RelNotes/2.9.4.txt @@ -0,0 +1,90 @@ +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/Documentation/RelNotes/2.9.5.txt b/Documentation/RelNotes/2.9.5.txt new file mode 100644 index 0000000000..668313ae55 --- /dev/null +++ b/Documentation/RelNotes/2.9.5.txt @@ -0,0 +1,4 @@ +Git v2.9.5 Release Notes +======================== + +This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 705557689d..291b61e262 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -1,40 +1,48 @@ -Here are some guidelines for people who want to contribute their code -to this software. +Submitting Patches +================== -(0) Decide what to base your work on. +== Guidelines + +Here are some guidelines for people who want to contribute their code to this +software. There is also a link:MyFirstContribution.html[step-by-step tutorial] +available which covers many of these same guidelines. + +[[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 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. +* A new feature should be based on `master` in general. If the new + feature depends on a topic that is in `seen`, 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. +* 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. +* In the exceptional case that a new feature depends on several topics + not in `master`, start working on `next` or `seen` 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. +* 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 +To find the tip of a topic branch, run `git log --first-parent +master..seen` and look for the merge commit. The second parent of this commit is the tip of the topic branch. -(1) Make separate commits for logically separate changes. +[[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 @@ -51,96 +59,156 @@ 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 summarise +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. +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 behaviour when it should, and to show the -feature does not trigger when it shouldn't. Also make sure that the -test suite passes after your commit. Do not forget to update the -documentation to describe the updated behaviour. - -Speaking of the documentation, it is currently 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. - +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. +in `templates/hooks--pre-commit`. To help ensure this does not happen, +run `git diff --check` on your changes before you commit. - -(2) Describe your changes well. +[[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 git-commit(1)), and -should skip the full stop. It is also conventional in most cases to +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. - . archive: ustar header checksum is computed unsigned - . git-cherry-pick.txt: clarify the use of revision range notation +* 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 +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, iow, what is wrong - with the current code without the change. +. 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, iow, why the - result with the change is better. +. 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. +. 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 behaviour. Try to make sure your explanation can be understood +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 hash (subject, date)", 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 (with the subject enclosed in a pair of double-quotes), or this +invocation of `git show`: + +.... + git show -s --pretty=reference <commit> +.... + +or, on an older version of Git without support for --pretty=reference: + +.... + git show -s --date=short --pretty='format:%h (%s, %ad)' <commit> +.... -(3) Generate your patch using Git tools out of your commits. +[[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 +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" +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. -(4) 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, all patches should be submitted -"inline". If your log message (including your name on the +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. @@ -150,14 +218,15 @@ 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 additional markers after PATCH and -the closing bracket to mark the nature of the patch is also -encouraged. E.g. [PATCH/RFC] is often used when the patch is -not ready to be applied but it is for discussion, [PATCH v2], -[PATCH v3] etc. are often seen when you are sending an update to -what you have previously sent. - -"git format-patch" command follows the best current practice to +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, @@ -165,12 +234,20 @@ 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 lines and the diffstat. Git-notes -can also be inserted using the `--notes` option. +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 @@ -185,37 +262,43 @@ 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. -Do not PGP sign your patch, at least for now. 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. +[[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 +that starts with `-----BEGIN PGP SIGNED MESSAGE-----`. That is not a text/plain, it's something else. +:security-ml-ref: footnoteref:[security-ml] + +As mentioned at the beginning of the section, patches that may be +security relevant should not be submitted to the public mailing list +mentioned below, but should instead be sent privately to the Git +Security mailing list{security-ml-ref}. + Send your patch with "To:" set to the mailing list, with "cc:" listing -people who are involved in the area you are touching (the output from -"git blame $path" and "git shortlog --no-merges $path" would help to +people who are involved in the area you are touching (the `git +contacts` command in `contrib/contacts/` can help to identify them), to solicit comments and reviews. +:current-maintainer: footnote:[The current maintainer: gitster@pobox.com] +:git-ml: footnote:[The mailing list: git@vger.kernel.org] + After the list reached a consensus that it is a good idea to apply the -patch, re-send it with "To:" set to the maintainer [*1*] and "cc:" the -list [*2*] for inclusion. +patch, re-send it with "To:" set to the maintainer{current-maintainer} and "cc:" the +list{git-ml} for inclusion. -Do not forget to add trailers such as "Acked-by:", "Reviewed-by:" and -"Tested-by:" lines as necessary to credit people who helped your +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. - [Addresses] - *1* The current maintainer: gitster@pobox.com - *2* The mailing list: git@vger.kernel.org - - -(5) Sign your work +[[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 @@ -224,38 +307,42 @@ 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 a open-source patch. The rules are -pretty simple: if you can certify the below: - - 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. +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. @@ -266,104 +353,145 @@ 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: -1. "Reported-by:" is used to credit someone who found the bug that - the patch attempts to fix. -2. "Acked-by:" says that the person who is more familiar with the area - the patch attempts to modify liked the patch. -3. "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. -4. "Tested-by:" is used to indicate that the person applied the patch - and found it to have the desired effect. +. `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 +== 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-gui/` comes from git-gui project, maintained by Pratyush Yadav: - git://repo.or.cz/git-gui.git + https://github.com/prati0100/git-gui.git - - gitk-git/ comes from Paul Mackerras's gitk project: +- `gitk-git/` comes from Paul Mackerras's gitk project: - git://ozlabs.org/~paulus/gitk + git://ozlabs.org/~paulus/gitk - - po/ comes from the localization coordinator, Jiang Xin: +- `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. ------------------------------------------------- -An ideal patch flow +[[patch-flow]] +== An ideal patch flow Here is an ideal patch flow for this project the current maintainer suggests to the contributors: - (0) You come up with an itch. You code it up. +. You come up with an itch. You code it up. - (1) Send it to the list and cc people who may need to know about - the change. +. 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. - 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 -- $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. - (2) You get comments and suggestions for improvements. You may - even get them in a "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). - (3) 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. - (4) The list forms consensus that the last round of your patch is - good. Send it to the list and cc the maintainer. - - (5) A topic branch is created with the patch and is merged to 'next', - and cooked further and eventually graduates to 'master'. +. 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 +from the list and queue it to `seen`, in order to make it easier for people play with it without having to pick up and apply the patch to their trees themselves. ------------------------------------------------- -Know the status of your patch after submission +[[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 + 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 + tell you if your patch is merged in `seen` 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. ------------------------------------------------- -MUA specific hints +[[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 git-format-patch(1) for hints on +See the DISCUSSION section of linkgit:git-format-patch[1] for hints on checking your patch by mailing it to yourself and applying with -git-am(1). +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 @@ -375,23 +503,24 @@ should come after the three-dash line that signals the end of the commit message. -Pine ----- +=== 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 @@ -413,10 +542,11 @@ diff --git a/pico/pico.c b/pico/pico.c +#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. @@ -426,23 +556,21 @@ 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 -Thunderbird, KMail, GMail -------------------------- - -See the MUA-SPECIFIC HINTS section of git-format-patch(1). +See the MUA-SPECIFIC HINTS section of linkgit:git-format-patch[1]. -Gnus ----- +=== Gnus -'|' in the *Summary* buffer can be used to pipe the current +"|" 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 +`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 +`*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 +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/Documentation/asciidoc.conf b/Documentation/asciidoc.conf index 2c16c536ba..3e4c13971b 100644 --- a/Documentation/asciidoc.conf +++ b/Documentation/asciidoc.conf @@ -31,24 +31,6 @@ ifdef::backend-docbook[] 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] @@ -67,7 +49,6 @@ ifdef::doctype-manpage[] {title#}</para></formalpara> {title%}<simpara></simpara> endif::doctype-manpage[] -endif::git-asciidoc-no-roff[] endif::backend-docbook[] ifdef::doctype-manpage[] @@ -78,9 +59,9 @@ template::[header-declarations] <refmeta> <refentrytitle>{mantitle}</refentrytitle> <manvolnum>{manvolnum}</manvolnum> -<refmiscinfo class="source">Git</refmiscinfo> -<refmiscinfo class="version">{git_version}</refmiscinfo> -<refmiscinfo class="manual">Git Manual</refmiscinfo> +<refmiscinfo class="source">{mansource}</refmiscinfo> +<refmiscinfo class="version">{manversion}</refmiscinfo> +<refmiscinfo class="manual">{manmanual}</refmiscinfo> </refmeta> <refnamediv> <refname>{manname}</refname> diff --git a/Documentation/asciidoctor-extensions.rb b/Documentation/asciidoctor-extensions.rb new file mode 100644 index 0000000000..d906a00803 --- /dev/null +++ b/Documentation/asciidoctor-extensions.rb @@ -0,0 +1,48 @@ +require 'asciidoctor' +require 'asciidoctor/extensions' + +module Git + module Documentation + class LinkGitProcessor < Asciidoctor::Extensions::InlineMacroProcessor + use_dsl + + named :chrome + + def process(parent, target, attrs) + prefix = parent.document.attr('git-relative-html-prefix') + if parent.document.doctype == 'book' + "<ulink url=\"#{prefix}#{target}.html\">" \ + "#{target}(#{attrs[1]})</ulink>" + elsif parent.document.basebackend? 'html' + %(<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 + + class DocumentPostProcessor < Asciidoctor::Extensions::Postprocessor + def process document, output + if document.basebackend? 'docbook' + mansource = document.attributes['mansource'] + manversion = document.attributes['manversion'] + manmanual = document.attributes['manmanual'] + new_tags = "" \ + "<refmiscinfo class=\"source\">#{mansource}</refmiscinfo>\n" \ + "<refmiscinfo class=\"version\">#{manversion}</refmiscinfo>\n" \ + "<refmiscinfo class=\"manual\">#{manmanual}</refmiscinfo>\n" + output = output.sub(/<\/refmeta>/, new_tags + "</refmeta>") + end + output + end + end + end +end + +Asciidoctor::Extensions.register do + inline_macro Git::Documentation::LinkGitProcessor, :linkgit + postprocessor Git::Documentation::DocumentPostProcessor +end diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt index 0cebc4f692..5d122db6e9 100644 --- a/Documentation/blame-options.txt +++ b/Documentation/blame-options.txt @@ -4,13 +4,13 @@ --root:: Do not treat root commits as boundaries. This can also be - controlled via the `blame.showroot` config option. + controlled via the `blame.showRoot` config option. --show-stats:: Include additional statistics at the end of blame output. -L <start>,<end>:: --L :<regex>:: +-L :<funcname>:: Annotate only the given line range. May be specified multiple times. Overlapping ranges are allowed. + @@ -28,12 +28,13 @@ include::line-range-format.txt[] -S <revs-file>:: Use revisions from revs-file instead of calling linkgit:git-rev-list[1]. ---reverse:: +--reverse <rev>..<rev>:: Walk history forward instead of backward. Instead of showing the revision in which a line appeared, this shows the last revision in which a line has existed. This requires a range of revision like START..END where the path to blame exists in - START. + START. `git blame --reverse START` is taken as `git blame + --reverse START..HEAD` for convenience. -p:: --porcelain:: @@ -63,14 +64,20 @@ include::line-range-format.txt[] `-` to make the command read from the standard input). --date <format>:: - The value is one of the following alternatives: - {relative,local,default,iso,rfc,short}. If --date is not + 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 more information, See the discussion + iso format is used. For supported values, see the discussion of the --date option at linkgit:git-log[1]. --M|<num>|:: +--[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 @@ -86,7 +93,7 @@ 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>|:: +-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 @@ -103,5 +110,24 @@ 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/Documentation/cat-texi.perl b/Documentation/cat-texi.perl index 87437f8a95..14d2f83415 100755 --- a/Documentation/cat-texi.perl +++ b/Documentation/cat-texi.perl @@ -1,9 +1,12 @@ #!/usr/bin/perl -w +use strict; +use warnings; + my @menu = (); my $output = $ARGV[0]; -open TMP, '>', "$output.tmp"; +open my $tmp, '>', "$output.tmp"; while (<STDIN>) { next if (/^\\input texinfo/../\@node Top/); @@ -11,13 +14,13 @@ while (<STDIN>) { if (s/^\@top (.*)/\@node $1,,,Top/) { push @menu, $1; } - s/\(\@pxref{\[(URLS|REMOTES)\]}\)//; + s/\(\@pxref\{\[(URLS|REMOTES)\]}\)//; s/\@anchor\{[^{}]*\}//g; - print TMP; + print $tmp $_; } -close TMP; +close $tmp; -printf '\input texinfo +print '\input texinfo @setfilename gitman.info @documentencoding UTF-8 @dircategory Development @@ -28,16 +31,16 @@ printf '\input texinfo @top Git Manual Pages @documentlanguage en @menu -', $menu[0]; +'; for (@menu) { print "* ${_}::\n"; } print "\@end menu\n"; -open TMP, '<', "$output.tmp"; -while (<TMP>) { +open $tmp, '<', "$output.tmp"; +while (<$tmp>) { print; } -close TMP; +close $tmp; print "\@bye\n"; unlink "$output.tmp"; diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl index 04f99778d8..5aa73cfe45 100755 --- a/Documentation/cmd-list.perl +++ b/Documentation/cmd-list.perl @@ -38,6 +38,10 @@ sub format_one { } } +while (<>) { + last if /^### command list/; +} + my %cmds = (); for (sort <>) { next if /^#/; diff --git a/Documentation/config.txt b/Documentation/config.txt index ab26963d61..ef0768b91a 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2,11 +2,13 @@ CONFIGURATION FILE ------------------ The Git configuration file contains a number of variables that affect -the Git commands' behavior. The `.git/config` file in each repository -is 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 Git commands' behavior. The files `.git/config` and optionally +`config.worktree` (see the "CONFIGURATION FILE" section of +linkgit:git-worktree[1]) 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 @@ -14,7 +16,8 @@ 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. +variables may appear multiple times; we say then that the variable is +multivalued. Syntax ~~~~~~ @@ -25,7 +28,7 @@ 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 not case sensitive. Only alphanumeric +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. @@ -40,11 +43,13 @@ in the section header, like in the example below: -------- Subsection names are case sensitive and can contain any characters except -newline (doublequote `"` and backslash have to be escaped as `\"` and `\\`, -respectively). 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. +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 @@ -53,2304 +58,412 @@ 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'. If there is no equal sign on the line, the entire line -is taken as 'name' and the variable is recognized as boolean "true". +'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. There can be more -than one value for a given variable; we say then that the variable is -multivalued. - -Leading and trailing whitespace in a variable value is discarded. -Internal whitespace within a variable value is retained verbatim. +and `-`, and must start with an alphabetic character. -The values following the equals sign in variable assign are all either -a string, an integer, or a boolean. Boolean values may be given as yes/no, -1/0, true/false or on/off. Case is not significant in boolean values, when -converting value to the canonical form using '--bool' type specifier; -'git config' will ensure that the output is "true" or "false". +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. -String values may be entirely or partially enclosed in double quotes. -You need to enclose variable values in double quotes if you want to -preserve leading or trailing whitespace, or if the variable value contains -comment characters (i.e. it contains '#' or ';'). -Double quote `"` and backslash `\` characters in variable values must -be escaped: use `\"` for `"` and `\\` for `\`. +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). No other char escape sequence, nor octal -char sequences are valid. +and `\b` for backspace (BS). Other char escape sequences (including octal +escape sequences) are invalid. -Variable values ending in a `\` are continued on the next line in the -customary UNIX fashion. - -Some variables may require a special value format. Includes ~~~~~~~~ -You can include one config file from another by setting the special -`include.path` variable to the name of the file to be included. The -included file is expanded immediately, as if its contents had been -found at the location of the include directive. If the value of the -`include.path` variable is a relative path, the path is considered to be -relative to the configuration file in which the include directive was -found. The value of `include.path` is subject to tilde expansion: `~/` -is expanded to the value of `$HOME`, and `~user/` to the specified -user's home directory. See below for examples. +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. -Example -~~~~~~~ +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 systems) + +`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. - # Core variables - [core] - ; Don't trust file modes - filemode = false + * Note that "../" is not special and will match literally, which is + unlikely what you want. - # Our diff algorithm - [diff] - external = /usr/local/bin/diff-wrapper - renames = true +Example +~~~~~~~ - [branch "devel"] - remote = origin - merge = refs/heads/devel +---- +# 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 +~~~~~~ - # Proxy settings - [core] - gitProxy="ssh" for "kernel.org" - gitProxy=default-proxy ; for the rest +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. All the basic colors except +`normal` have a bright variant that can be speficied by prefixing the +color with `bright`, like `brightred`. ++ +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. - [include] - path = /path/to/foo.inc ; include by absolute path - path = foo ; expand "foo" relative to the current file - path = ~/foo ; expand "foo" in your $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. You will find a description of non-core -porcelain configuration variables in the respective porcelain documentation. +in the appropriate manual page. -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': -+ --- - pushUpdateRejected:: - Set this variable to 'false' if you want to disable - 'pushNonFFCurrent', 'pushNonFFDefault', - 'pushNonFFMatching', 'pushAlreadyExists', - 'pushFetchFirst', and 'pushNeedsForce' - simultaneously. - pushNonFFCurrent:: - Advice shown when linkgit:git-push[1] fails due to a - non-fast-forward update to the current branch. - pushNonFFDefault:: - Advice to set 'push.default' to 'upstream' or 'current' - when you ran linkgit:git-push[1] and pushed 'matching - refs' by default (i.e. you did not provide an explicit - refspec, and no 'push.default' configuration was set) - and it resulted in a non-fast-forward error. - pushNonFFMatching:: - Advice shown when you ran linkgit:git-push[1] and pushed - 'matching refs' explicitly (i.e. you used ':', or - 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. - 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-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. - resolveConflict:: - Advice shown by various commands when conflicts - prevent the operation from being performed. - 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-checkout[1] to - move to the detach HEAD state, to instruct how to create - a local branch after the fact. - 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. --- - -core.fileMode:: - If false, the executable bit differences between the index and - the working tree are ignored; useful on broken filesystems like FAT. - See linkgit:git-update-index[1]. -+ -The default is true, except linkgit:git-clone[1] or linkgit:git-init[1] -will probe and set core.fileMode false if appropriate when the -repository is created. - -core.ignorecase:: - If true, this option enables various workarounds to enable - Git to work better on filesystems that are not case sensitive, - like FAT. 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. - -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.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.checkstat:: - Determines which stat fields to match between the index - and work tree. The user can set this to 'default' or - 'minimal'. Default (or explicitly 'default'), is to check - all fields, including the sub-second part of mtime and ctime. - -core.quotepath:: - The commands that output paths (e.g. 'ls-files', - 'diff'), when not given the `-z` option, will quote - "unusual" characters in the pathname by enclosing the - pathname in a double-quote pair and with backslashes the - same way strings in C source code are quoted. If this - variable is set to false, the bytes higher than 0x80 are - not quoted but output as verbatim. Note that double - quote, backslash and control characters are always - quoted without `-z` regardless of the setting of this - variable. - -core.eol:: - Sets the line ending type to use in the working directory for - files that have the `text` property set. 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. - -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 almost the same as setting - the `text` attribute to "auto" on all files except that text - files are not guaranteed to be normalized: files that contain - `CRLF` in the repository will not be touched. Use this - setting if you want to have `CRLF` line endings in your - working directory even though the repository does not have - normalized line endings. This variable can be set to 'input', - in which case no output conversion is performed. - -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.ignoreStat:: - If true, commands which modify both the working tree and the index - will mark the updated paths with the "assume unchanged" bit in the - index. These marked files are then assumed to stay unchanged in the - working tree, until you mark them otherwise manually - Git will not - detect the file changes by lstat() calls. This is useful on systems - where those are very slow, such as Microsoft Windows. - See linkgit:git-update-index[1]. - 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.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. - 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. -+ -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. +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. -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 8 GiB 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 16 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. +include::config/advice.txt[] -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. -+ -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:: - In addition to '.gitignore' (per-directory) and - '.git/info/exclude', Git looks into this file for patterns - of files which are not meant to be tracked. "`~/`" is expanded - to the value of `$HOME` and "`~user/`" to the specified user's - home directory. 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. 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.editor:: - Commands such as `commit` and `tag` that lets you edit - messages by launching an editor uses 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 lets you edit - messages consider a line that begins with this character - commented, and removes them after the editor returns - (default '#'). - -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. - -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 `FRSX` -(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=FRSX less -+S`. The environment tells the command -to set the `S` option to chop long lines but the command line -resets it to the default to fold long lines. - -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"). +include::config/core.txt[] -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. With this set to 'true', Git will do the -index comparison to the filesystem data in parallel, allowing -overlapping IO's. - -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.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, - many commands abbreviate to 7 hexdigits, which may not be enough - for abbreviated object names to stay unique for sufficiently long - time. - -add.ignore-errors:: -add.ignoreErrors:: - 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]. Older versions of Git accept only - `add.ignore-errors`, which does not follow the usual naming - convention for configuration variables. Newer versions of Git - honor `add.ignoreErrors` as well. - -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. - quote pair and a backslash can be used to quote them. -+ -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]. - -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]. - -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]. - -branch.autosetupmerge:: - Tells 'git branch' 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' 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.<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 preserve, also pass `--preserve-merges` along to 'git rebase' - so that locally committed merge commits will not be flattened - by running 'git pull'. -+ -*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. - -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]). - -clean.requireForce:: - A boolean to make git-clean do nothing unless given -f, - -i or -n. Defaults to true. - -color.branch:: - A boolean to enable/disable color in the output of - linkgit:git-branch[1]. May be set to `always`, - `false` (or `never`) or `auto` (or `true`), in which case colors are used - only when the output is to a terminal. Defaults to false. - -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). -+ -The value for these configuration variables is a list of colors (at most -two) and attributes (at most one), separated by spaces. The colors -accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`, -`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`, -`blink` and `reverse`. The first color given is the foreground; the -second is the background. The position of the attribute, if any, -doesn't matter. - -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. - Defaults to false. -+ -This does not affect linkgit:git-format-patch[1] nor 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 `plain` (context text), `meta` (metainformation), `frag` - (hunk header), 'func' (function in hunk header), `old` (removed lines), - `new` (added lines), `commit` (commit headers), or `whitespace` - (highlighting whitespace errors). The values of these variables may be - specified as in color.branch.<slot>. - -color.decorate.<slot>:: - Use customized color for 'git log --decorate' output. `<slot>` is one - of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local - branches, remote-tracking branches, tags, stash and HEAD, respectively. - -color.grep:: - When set to `always`, always highlight matches. When `false` (or - `never`), never. When set to `true` or `auto`, use color only - when the output is written to the terminal. Defaults to `false`. - -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`) -`match`;; - matching text -`selected`;; - non-matching text in selected lines -`separator`;; - separators between fields on a line (`:`, `-`, and `=`) - and between hunks (`--`) --- -+ -The values of these variables may be specified as in color.branch.<slot>. - -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. Defaults to false. - -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. The values of these variables may be - specified as in color.branch.<slot>. - -color.pager:: - A boolean to enable/disable colored output when the pager is in - use (default is true). - -color.showbranch:: - A boolean to enable/disable color in the output of - linkgit:git-show-branch[1]. May be set to `always`, - `false` (or `never`) or `auto` (or `true`), in which case colors are used - only when the output is to a terminal. Defaults to false. - -color.status:: - A boolean to enable/disable color in the output of - linkgit:git-status[1]. May be set to `always`, - `false` (or `never`) or `auto` (or `true`), in which case colors are used - only when the output is to a terminal. Defaults to false. - -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), or - `nobranch` (the color the 'no branch' warning is shown in, defaulting - to red). The values of these variables may be specified as in - color.branch.<slot>. - -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. - -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. - -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.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 a file to use as the template for new commit messages. - "`~/`" is expanded to the value of `$HOME` and "`~user/`" to the - specified user's home directory. +include::config/add.txt[] -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. 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. - -include::diff-config.txt[] - -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. - -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. It will abort in the case of a malformed object or a - broken link. The result of an abort are only dangling objects. - Defaults to false. If not set, the value of `transfer.fsckObjects` - is used instead. - -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`. - -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.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.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. - -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. - -gc.aggressiveWindow:: - The window size parameter used in the delta compression - algorithm used by 'git gc --aggressive'. This defaults - to 250. - -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 it. - -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. - -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. - -gc.reflogexpire:: -gc.<pattern>.reflogexpire:: - 'git reflog expire' removes reflog entries older than - this time; defaults to 90 days. With "<pattern>" (e.g. - "refs/stash") in the middle the setting applies only to - the refs that match the <pattern>. - -gc.reflogexpireunreachable:: -gc.<ref>.reflogexpireunreachable:: - 'git reflog expire' removes reflog entries older than - this time and are not reachable from the current tip; - defaults to 30 days. With "<pattern>" (e.g. "refs/stash") - in the middle, the setting applies only to the refs that - match the <pattern>. - -gc.rerereresolved:: - Records of conflicted merge you resolved earlier are - kept for this many days when 'git rerere gc' is run. - 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. - The default is 15 days. See linkgit:git-rerere[1]. - -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. - -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. - -grep.lineNumber:: - If set to true, enable '-n' 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'. - -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 $file - <$signature" 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. - -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.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. - -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. - -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. - -http.proxy:: - Override the HTTP proxy, normally configured using the 'http_proxy', - 'https_proxy', and 'all_proxy' environment variables (see - `curl(1)`). This can be overridden on a per-remote basis; see - remote.<name>.proxy - -http.cookiefile:: - 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 linkgit:curl[1]). - NOTE that the file specified with http.cookiefile is only used 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.sslVerify:: - Whether to verify the SSL certificate when fetching or pushing - over HTTPS. 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.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.<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 exactly between the config key and the URL. - -. 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. - -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. - -imap:: - The configuration variables in the 'imap' section are described - in linkgit:git-imap-send[1]. - -init.templatedir:: - Specify the directory from which templates will be copied. - (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) - -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]. - -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-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. - -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. Possible values are `relative`, `local`, - `default`, `iso`, `rfc`, and `short`; 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. - This is the same as the log commands '--decorate' option. - -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.mailmap:: - If true, makes linkgit:git-log[1], linkgit:git-show[1], and - linkgit:git-whatchanged[1] assume `--use-mailmap`. - -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. - -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]. - -include::merge-config.txt[] - -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.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.prompt:: - Prompt before each invocation of the merge resolution program. - -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`, 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. - -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. - -pack.windowMemory:: - The window memory size limit used by linkgit:git-pack-objects[1] - when no limit is given on the command line. The value can be - suffixed with "k", "m", or "g". Defaults to 0, meaning 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.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. - -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" and "rsync") -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]. The minimum size allowed is - limited to 1 MiB. The default is unlimited. - Common unit suffixes of 'k', 'm', or 'g' are - supported. - -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`. - -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. - -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 preserve, also pass `--preserve-merges` along to 'git rebase' - so that locally committed merge commits will not be flattened - by running 'git pull'. -+ -*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. - -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: -+ --- +include::config/alias.txt[] -* `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. +include::config/am.txt[] -* `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. +include::config/apply.txt[] -* `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). +include::config/blame.txt[] -* `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 will 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 is currently the default, but Git 2.0 will change the default -to `simple`. - --- - -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 - 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. - Defaults to false. - -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.fsckObjects:: - If it is set to true, git-receive-pack will check all received - objects. It will abort in the case of a malformed object or a - broken link. The result of an abort are only dangling objects. - Defaults to false. If not set, the value of `transfer.fsckObjects` - is used instead. - -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.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". - -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:: - String(s) `receive-pack` uses to decide which refs to omit - from its initial advertisement. Use more than one - definitions to specify multiple prefix strings. A ref that - are under the hierarchies listed on the value of this - variable is excluded, and is hidden when responding to `git - push`, and 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. - -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>.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 branches which no longer exist on the - remote (as if the `--prune` option was give on the command line). - Overrides `fetch.prune` settings, if any. - -remotes.<group>:: - The list of remotes which are fetched by "git remote update - <group>". See linkgit:git-remote[1]. - -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. - -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. - -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 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 the this - identity is selected, through 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.smtpdomain:: -sendemail.smtpserver:: -sendemail.smtpserverport:: -sendemail.smtpserveroption:: -sendemail.smtpuser:: -sendemail.thread:: -sendemail.validate:: - See linkgit:git-send-email[1] for description. - -sendemail.signedoffcc:: - Deprecated alias for 'sendemail.signedoffbycc'. - -showbranch.default:: - The default set of branches for linkgit:git-show-branch[1]. - See linkgit:git-show-branch[1]. - -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.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.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 - 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`. 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. - -submodule.<name>.path:: -submodule.<name>.url:: -submodule.<name>.update:: - The path within this project, URL, and the updating strategy - for a submodule. These variables are initially populated - by 'git submodule init'; edit them to override the - URL and other values found in the `.gitmodules` file. See - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. - -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, "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. - -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]. - -transfer.fsckObjects:: - When `fetch.fsckObjects` or `receive.fsckObjects` are - not set, the value of this variable is used instead. - Defaults to false. - -transfer.hiderefs:: - This variable can be used to set both `receive.hiderefs` - and `uploadpack.hiderefs` at the same time to the same - values. See entries for these other variables. - -transfer.unpackLimit:: - When `fetch.unpackLimit` or `receive.unpackLimit` are - not set, the value of this variable is used instead. - The default value is 100. - -uploadpack.hiderefs:: - String(s) `upload-pack` uses to decide which refs to omit - from its initial advertisement. Use more than one - definitions to specify multiple prefix strings. A ref that - are under the hierarchies listed on the value of this - variable is excluded, and is hidden from `git ls-remote`, - `git fetch`, etc. 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`. - -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. - -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. - -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. - -user.email:: - Your email address to be recorded in any newly created commits. - Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and - 'EMAIL' environment variables. See linkgit:git-commit-tree[1]. - -user.name:: - Your full name to be recorded in any newly created commits. - Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME' - environment variables. See linkgit:git-commit-tree[1]. - -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. - -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. +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/feature.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/tar.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/Documentation/config/add.txt b/Documentation/config/add.txt new file mode 100644 index 0000000000..c9f748f81c --- /dev/null +++ b/Documentation/config/add.txt @@ -0,0 +1,12 @@ +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. + +add.interactive.useBuiltin:: + [EXPERIMENTAL] Set to `true` to use the experimental built-in + implementation of the interactive version of linkgit:git-add[1] + instead of the Perl script version. Is `false` by default. diff --git a/Documentation/config/advice.txt b/Documentation/config/advice.txt new file mode 100644 index 0000000000..bdd37c3eaa --- /dev/null +++ b/Documentation/config/advice.txt @@ -0,0 +1,119 @@ +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. + submoduleAlternateErrorStrategyDie:: + Advice shown when a submodule.alternateErrorStrategy option + configured to "die" causes a fatal error. + addIgnoredFile:: + Advice shown if a user attempts to add an ignored file to + the index. + addEmptyPathspec:: + Advice shown if a user runs the add command without providing + the pathspec parameter. +-- diff --git a/Documentation/config/alias.txt b/Documentation/config/alias.txt new file mode 100644 index 0000000000..f1ca739d57 --- /dev/null +++ b/Documentation/config/alias.txt @@ -0,0 +1,28 @@ +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/Documentation/config/am.txt b/Documentation/config/am.txt new file mode 100644 index 0000000000..5bcad2efb1 --- /dev/null +++ b/Documentation/config/am.txt @@ -0,0 +1,14 @@ +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/Documentation/config/apply.txt b/Documentation/config/apply.txt new file mode 100644 index 0000000000..8fb8ef763d --- /dev/null +++ b/Documentation/config/apply.txt @@ -0,0 +1,11 @@ +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/Documentation/config/blame.txt b/Documentation/config/blame.txt new file mode 100644 index 0000000000..9468e8599c --- /dev/null +++ b/Documentation/config/blame.txt @@ -0,0 +1,37 @@ +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/Documentation/config/branch.txt b/Documentation/config/branch.txt new file mode 100644 index 0000000000..cc5f3249fc --- /dev/null +++ b/Documentation/config/branch.txt @@ -0,0 +1,103 @@ +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` (or just 'm'), 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` (or just 'p', 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` (or just 'i'), 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/Documentation/config/browser.txt b/Documentation/config/browser.txt new file mode 100644 index 0000000000..195df207a6 --- /dev/null +++ b/Documentation/config/browser.txt @@ -0,0 +1,9 @@ +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/Documentation/config/checkout.txt b/Documentation/config/checkout.txt new file mode 100644 index 0000000000..6b646813ab --- /dev/null +++ b/Documentation/config/checkout.txt @@ -0,0 +1,18 @@ +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/Documentation/config/clean.txt b/Documentation/config/clean.txt new file mode 100644 index 0000000000..a807c925b9 --- /dev/null +++ b/Documentation/config/clean.txt @@ -0,0 +1,3 @@ +clean.requireForce:: + A boolean to make git-clean do nothing unless given -f, + -i or -n. Defaults to true. diff --git a/Documentation/config/color.txt b/Documentation/config/color.txt new file mode 100644 index 0000000000..d5daacb13a --- /dev/null +++ b/Documentation/config/color.txt @@ -0,0 +1,201 @@ +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/Documentation/config/column.txt b/Documentation/config/column.txt new file mode 100644 index 0000000000..76aa2f29dc --- /dev/null +++ b/Documentation/config/column.txt @@ -0,0 +1,55 @@ +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/Documentation/config/commit.txt b/Documentation/config/commit.txt new file mode 100644 index 0000000000..2c95573930 --- /dev/null +++ b/Documentation/config/commit.txt @@ -0,0 +1,29 @@ +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/Documentation/config/completion.txt b/Documentation/config/completion.txt new file mode 100644 index 0000000000..4d99bf33c9 --- /dev/null +++ b/Documentation/config/completion.txt @@ -0,0 +1,7 @@ +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/Documentation/config/core.txt b/Documentation/config/core.txt new file mode 100644 index 0000000000..74619a9c03 --- /dev/null +++ b/Documentation/config/core.txt @@ -0,0 +1,628 @@ +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.fsmonitorHookVersion:: + Sets the version of hook that is to be used when calling fsmonitor. + There are currently versions 1 and 2. When this is not set, + version 2 will be tried first and if it fails then version 1 + will be tried. Version 1 uses a timestamp as input to determine + which files have changes since that time but some monitors + like watchman have race conditions when used with a timestamp. + Version 2 uses an opaque string so that the monitor can return + something that can be used to determine what files have changed + without race conditions. + +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, unless + `feature.manyFiles` is enabled which sets this setting to + `true` 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.restrictinheritedhandles:: + Windows-only: override whether spawned processes inherit only standard + file handles (`stdin`, `stdout` and `stderr`) or all handles. Can be + `auto`, `true` or `false`. Defaults to `auto`, which means `true` on + Windows 7 and later, and `false` on older Windows versions. + +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 true. 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 linkgit:git-sparse-checkout[1] + for more information. + +core.sparseCheckoutCone:: + Enables the "cone mode" of the sparse checkout feature. When the + sparse-checkout file contains a limited set of patterns, then this + mode provides significant performance advantages. See + linkgit:git-sparse-checkout[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/Documentation/config/credential.txt b/Documentation/config/credential.txt new file mode 100644 index 0000000000..9d01641c28 --- /dev/null +++ b/Documentation/config/credential.txt @@ -0,0 +1,30 @@ +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. This is + normally the name of a credential helper with possible + arguments, but may also be an absolute path with arguments or, if + preceded by `!`, shell commands. ++ +Note that multiple helpers may be defined. See linkgit:gitcredentials[7] +for details and examples. + +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/Documentation/diff-config.txt b/Documentation/config/diff.txt index 223b9310df..c3ae136eba 100644 --- a/Documentation/diff-config.txt +++ b/Documentation/config/diff.txt @@ -1,4 +1,4 @@ -diff.autorefreshindex:: +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 @@ -10,7 +10,7 @@ diff.autorefreshindex:: diff.dirstat:: A comma separated list of `--dirstat` parameters specifying the - default behavior of the `--dirstat` option to linkgit:git-diff[1]` + 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`. @@ -60,6 +60,12 @@ 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 @@ -67,19 +73,20 @@ diff.external:: 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. + 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' also honors + 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. + 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:: +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 @@ -98,14 +105,29 @@ diff.mnemonicprefix:: diff.noprefix:: If set, 'git diff' does not show any source or destination prefix. +diff.relative:: + If set to 'true', 'git diff' does not show changes outside of the directory + and show pathnames relative to the current directory. + +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'. + detection; equivalent to the 'git diff' option `-l`. This setting + has no effect if rename detection is turned off. diff.renames:: - Tells Git to detect renames. If set to any boolean value, it - will enable basic rename detection. If set to "copies" or - "copy", it will detect copies, as well. + 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 @@ -113,10 +135,11 @@ diff.suppressBlankEmpty:: diff.submodule:: Specify the format in which differences in submodules are - shown. The "log" format lists the commits in the range like - linkgit:git-submodule[1] `summary` does. The "short" format - format just shows the names of the commits at the beginning - and end of the range. Defaults to short. + shown. The "short" format just shows the names of the commits + at the beginning and end of the range. The "log" format lists + the commits in the range like linkgit:git-submodule[1] `summary` + does. The "diff" format shows an inline diff of the changed + contents of the submodule. Defaults to "short". diff.wordRegex:: A POSIX Extended Regular Expression used to determine what is a "word" @@ -143,7 +166,7 @@ diff.<driver>.textconv:: conversion is used to generate a human-readable diff. See linkgit:gitattributes[5] for details. -diff.<driver>.wordregex:: +diff.<driver>.wordRegex:: The regular expression that the diff driver should use to split words in a line. See linkgit:gitattributes[5] for details. @@ -159,7 +182,19 @@ diff.tool:: Any other value is treated as a custom diff tool and requires that a corresponding difftool.<tool>.cmd variable is defined. -include::mergetools-diff.txt[] +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 `false` to disable the default heuristics + that shift diff hunk boundaries to make patches easier to read. diff.algorithm:: Choose a diff algorithm. The variants are as follows: @@ -177,3 +212,24 @@ diff.algorithm:: 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/Documentation/config/difftool.txt b/Documentation/config/difftool.txt new file mode 100644 index 0000000000..6762594480 --- /dev/null +++ b/Documentation/config/difftool.txt @@ -0,0 +1,14 @@ +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/Documentation/config/fastimport.txt b/Documentation/config/fastimport.txt new file mode 100644 index 0000000000..c1166e330d --- /dev/null +++ b/Documentation/config/fastimport.txt @@ -0,0 +1,8 @@ +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/Documentation/config/feature.txt b/Documentation/config/feature.txt new file mode 100644 index 0000000000..c0cbf2bb1c --- /dev/null +++ b/Documentation/config/feature.txt @@ -0,0 +1,30 @@ +feature.*:: + The config settings that start with `feature.` modify the defaults of + a group of other config settings. These groups are created by the Git + developer community as recommended defaults and are subject to change. + In particular, new config options may be added with different defaults. + +feature.experimental:: + Enable config options that are new to Git, and are being considered for + future defaults. Config settings included here may be added or removed + with each release, including minor version updates. These settings may + have unintended interactions since they are so new. Please enable this + setting if you are interested in providing feedback on experimental + features. The new default values are: ++ +* `fetch.negotiationAlgorithm=skipping` may improve fetch negotiation times by +skipping more commits at a time, reducing the number of round trips. ++ +* `protocol.version=2` speeds up fetches from repositories with many refs by +allowing the client to specify which refs to list before the server lists +them. + +feature.manyFiles:: + Enable config options that optimize for repos with many files in the + working directory. With many files, commands such as `git status` and + `git checkout` may be slow and these new defaults improve performance: ++ +* `index.version=4` enables path-prefix compression in the index. ++ +* `core.untrackedCache=true` enables the untracked cache. This setting assumes +that mtime is working on your machine. diff --git a/Documentation/config/fetch.txt b/Documentation/config/fetch.txt new file mode 100644 index 0000000000..b20394038d --- /dev/null +++ b/Documentation/config/fetch.txt @@ -0,0 +1,93 @@ +fetch.recurseSubmodules:: + This option controls whether `git fetch` (and the underlying fetch + in `git pull`) will recursively fetch into populated submodules. + This option can be set either to a boolean value or to 'on-demand'. + Setting it to a boolean changes the behavior of fetch and pull to + recurse unconditionally into submodules when set to true or to not + recurse at all when set to false. When set to 'on-demand', fetch and + pull will only recurse into a populated submodule when its + superproject retrieves a commit that updates the submodule's + reference. + Defaults to 'on-demand', or to the value of 'submodule.recurse' if set. + +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). If `feature.experimental` is enabled, then this + setting defaults to "skipping". + 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. + +fetch.parallel:: + Specifies the maximal number of fetch operations to be run in parallel + at a time (submodules, or remotes when the `--multiple` option of + linkgit:git-fetch[1] is in effect). ++ +A value of 0 will give some reasonable default. If unset, it defaults to 1. ++ +For submodules, this setting can be overridden using the `submodule.fetchJobs` +config setting. + +fetch.writeCommitGraph:: + Set to true to write a commit-graph after every `git fetch` command + that downloads a pack-file from a remote. Using the `--split` option, + most executions will create a very small commit-graph file on top of + the existing commit-graph file(s). Occasionally, these files will + merge and the write may take longer. Having an updated commit-graph + file helps performance of many Git commands, including `git merge-base`, + `git push -f`, and `git log --graph`. Defaults to false. diff --git a/Documentation/config/filter.txt b/Documentation/config/filter.txt new file mode 100644 index 0000000000..90dfe0ba5a --- /dev/null +++ b/Documentation/config/filter.txt @@ -0,0 +1,9 @@ +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/Documentation/config/fmt-merge-msg.txt b/Documentation/config/fmt-merge-msg.txt new file mode 100644 index 0000000000..c73cfa90b7 --- /dev/null +++ b/Documentation/config/fmt-merge-msg.txt @@ -0,0 +1,10 @@ +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/Documentation/config/format.txt b/Documentation/config/format.txt new file mode 100644 index 0000000000..564e8091ba --- /dev/null +++ b/Documentation/config/format.txt @@ -0,0 +1,130 @@ +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.coverFromDescription:: + The default mode for format-patch to determine which parts of + the cover letter will be populated using the branch's + description. See the `--cover-from-description` option in + linkgit:git-format-patch[1]. + +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.encodeEmailHeaders:: + Encode email headers that have non-ASCII characters with + "Q-encoding" (described in RFC 2047) for email transmission. + Defaults to true. + +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. + Default is false. + +format.outputDirectory:: + Set a custom directory to store the resulting files instead of the + current working directory. All directory components will be created. + +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. In that case, it will behave +similarly to multiple `--[no-]notes[=]` options passed in. That is, a +value of `true` will show the default notes, a value of `<ref>` will +also show notes from that notes ref and a value of `false` will negate +previous configurations and not show notes. ++ +For example, ++ +------------ +[format] + notes = true + notes = foo + notes = false + notes = bar +------------ ++ +will only show notes from `refs/notes/bar`. diff --git a/Documentation/config/fsck.txt b/Documentation/config/fsck.txt new file mode 100644 index 0000000000..450e8c38e3 --- /dev/null +++ b/Documentation/config/fsck.txt @@ -0,0 +1,67 @@ +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/Documentation/config/gc.txt b/Documentation/config/gc.txt new file mode 100644 index 0000000000..00ea0a678e --- /dev/null +++ b/Documentation/config/gc.txt @@ -0,0 +1,136 @@ +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 true. 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/Documentation/config/gitcvs.txt b/Documentation/config/gitcvs.txt new file mode 100644 index 0000000000..02da427fd9 --- /dev/null +++ b/Documentation/config/gitcvs.txt @@ -0,0 +1,67 @@ +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/Documentation/config/gitweb.txt b/Documentation/config/gitweb.txt new file mode 100644 index 0000000000..1b51475108 --- /dev/null +++ b/Documentation/config/gitweb.txt @@ -0,0 +1,16 @@ +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/Documentation/config/gpg.txt b/Documentation/config/gpg.txt new file mode 100644 index 0000000000..d94025cb36 --- /dev/null +++ b/Documentation/config/gpg.txt @@ -0,0 +1,35 @@ +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". + +gpg.minTrustLevel:: + Specifies a minimum trust level for signature verification. If + this option is unset, then signature verification for merge + operations require a key with at least `marginal` trust. Other + operations that perform signature verification require a key + with at least `undefined` trust. Setting this option overrides + the required trust-level for all operations. Supported values, + in increasing order of significance: ++ +* `undefined` +* `never` +* `marginal` +* `fully` +* `ultimate` diff --git a/Documentation/config/grep.txt b/Documentation/config/grep.txt new file mode 100644 index 0000000000..44abe45a7c --- /dev/null +++ b/Documentation/config/grep.txt @@ -0,0 +1,24 @@ +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/Documentation/config/gui.txt b/Documentation/config/gui.txt new file mode 100644 index 0000000000..d30831a130 --- /dev/null +++ b/Documentation/config/gui.txt @@ -0,0 +1,57 @@ +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/Documentation/config/guitool.txt b/Documentation/config/guitool.txt new file mode 100644 index 0000000000..43fb9466ff --- /dev/null +++ b/Documentation/config/guitool.txt @@ -0,0 +1,50 @@ +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/Documentation/config/help.txt b/Documentation/config/help.txt new file mode 100644 index 0000000000..224bbf5a28 --- /dev/null +++ b/Documentation/config/help.txt @@ -0,0 +1,23 @@ +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/Documentation/config/http.txt b/Documentation/config/http.txt new file mode 100644 index 0000000000..3968fbb697 --- /dev/null +++ b/Documentation/config/http.txt @@ -0,0 +1,309 @@ +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.proxySSLCert:: + The pathname of a file that stores a client certificate to use to authenticate + with an HTTPS proxy. Can be overridden by the `GIT_PROXY_SSL_CERT` environment + variable. + +http.proxySSLKey:: + The pathname of a file that stores a private key to use to authenticate with + an HTTPS proxy. Can be overridden by the `GIT_PROXY_SSL_KEY` environment + variable. + +http.proxySSLCertPasswordProtected:: + Enable Git's password prompt for the proxy SSL certificate. Otherwise OpenSSL + will prompt the user, possibly many times, if the certificate or private key + is encrypted. Can be overriden by the `GIT_PROXY_SSL_CERT_PASSWORD_PROTECTED` + environment variable. + +http.proxySSLCAInfo:: + Pathname to the file containing the certificate bundle that should be used to + verify the proxy with when using an HTTPS proxy. Can be overriden by the + `GIT_PROXY_SSL_CAINFO` environment variable. + +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. Currently 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. Currently 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. ++ +Note that raising this limit is only effective for disabling chunked +transfer encoding and therefore should be used only where the remote +server or a proxy only supports HTTP/1.0 or is noncompliant with the +HTTP standard. Raising this is not, in general, an effective solution +for most push problems, but can increase memory consumption +significantly since the entire buffer is allocated even for small +pushes. + +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/Documentation/config/i18n.txt b/Documentation/config/i18n.txt new file mode 100644 index 0000000000..cc25621731 --- /dev/null +++ b/Documentation/config/i18n.txt @@ -0,0 +1,10 @@ +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/Documentation/config/imap.txt b/Documentation/config/imap.txt new file mode 100644 index 0000000000..06166fb5c0 --- /dev/null +++ b/Documentation/config/imap.txt @@ -0,0 +1,44 @@ +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/Documentation/config/index.txt b/Documentation/config/index.txt new file mode 100644 index 0000000000..7cb50b37e9 --- /dev/null +++ b/Documentation/config/index.txt @@ -0,0 +1,27 @@ +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. + If `feature.manyFiles` is enabled, then the default is 4. diff --git a/Documentation/config/init.txt b/Documentation/config/init.txt new file mode 100644 index 0000000000..dc77f8c844 --- /dev/null +++ b/Documentation/config/init.txt @@ -0,0 +1,7 @@ +init.templateDir:: + Specify the directory from which templates will be copied. + (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) + +init.defaultBranch:: + Allows overriding the default branch name e.g. when initializing + a new repository or when cloning an empty repository. diff --git a/Documentation/config/instaweb.txt b/Documentation/config/instaweb.txt new file mode 100644 index 0000000000..50cb2f7d62 --- /dev/null +++ b/Documentation/config/instaweb.txt @@ -0,0 +1,20 @@ +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/Documentation/config/interactive.txt b/Documentation/config/interactive.txt new file mode 100644 index 0000000000..a2d3c7ec44 --- /dev/null +++ b/Documentation/config/interactive.txt @@ -0,0 +1,17 @@ +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/Documentation/config/log.txt b/Documentation/config/log.txt new file mode 100644 index 0000000000..208d5fdcaa --- /dev/null +++ b/Documentation/config/log.txt @@ -0,0 +1,50 @@ +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.excludeDecoration:: + Exclude the specified patterns from the log decorations. This is + similar to the `--decorate-refs-exclude` command-line option, but + the config option can be overridden by the `--decorate-refs` + option. + +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/Documentation/config/mailinfo.txt b/Documentation/config/mailinfo.txt new file mode 100644 index 0000000000..3854d4ae37 --- /dev/null +++ b/Documentation/config/mailinfo.txt @@ -0,0 +1,6 @@ +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/Documentation/config/mailmap.txt b/Documentation/config/mailmap.txt new file mode 100644 index 0000000000..48cbc30722 --- /dev/null +++ b/Documentation/config/mailmap.txt @@ -0,0 +1,15 @@ +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/Documentation/config/man.txt b/Documentation/config/man.txt new file mode 100644 index 0000000000..a727d987a8 --- /dev/null +++ b/Documentation/config/man.txt @@ -0,0 +1,12 @@ +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/Documentation/merge-config.txt b/Documentation/config/merge.txt index d78d6d854e..cb2ed58907 100644 --- a/Documentation/merge-config.txt +++ b/Documentation/config/merge.txt @@ -1,4 +1,4 @@ -merge.conflictstyle:: +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, @@ -26,16 +26,35 @@ merge.ff:: allowed (equivalent to giving the `--ff-only` option from the command line). -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. +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. + 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 @@ -51,13 +70,29 @@ merge.stat:: Whether to print the diffstat between ORIG_HEAD and the merge result at the end of the merge. True by default. +merge.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 merge on a dirty worktree. + However, use with care: the final stash application after a + successful merge might result in non-trivial conflicts. + This option can be overridden by the `--no-autostash` and + `--autostash` options of linkgit:git-merge[1]. + Defaults to false. + 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. -include::mergetools-merge.txt[] +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 @@ -65,7 +100,7 @@ merge.verbosity:: 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. + Can be overridden by the `GIT_MERGE_VERBOSITY` environment variable. merge.<driver>.name:: Defines a human-readable name for a custom low-level diff --git a/Documentation/config/mergetool.txt b/Documentation/config/mergetool.txt new file mode 100644 index 0000000000..09ed31dbfa --- /dev/null +++ b/Documentation/config/mergetool.txt @@ -0,0 +1,53 @@ +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/Documentation/config/notes.txt b/Documentation/config/notes.txt new file mode 100644 index 0000000000..aeef56d49a --- /dev/null +++ b/Documentation/config/notes.txt @@ -0,0 +1,59 @@ +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/Documentation/config/pack.txt b/Documentation/config/pack.txt new file mode 100644 index 0000000000..837f1b1679 --- /dev/null +++ b/Documentation/config/pack.txt @@ -0,0 +1,135 @@ +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.allowPackReuse:: + When true, and when reachability bitmaps are enabled, + pack-objects will try to send parts of the bitmapped packfile + verbatim. This can reduce memory and CPU usage to serve fetches, + but might result in sending a slightly larger pack. Defaults to + true. + +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. Default is + `true`. + +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/Documentation/config/pager.txt b/Documentation/config/pager.txt new file mode 100644 index 0000000000..d3731cf66c --- /dev/null +++ b/Documentation/config/pager.txt @@ -0,0 +1,8 @@ +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/Documentation/config/pretty.txt b/Documentation/config/pretty.txt new file mode 100644 index 0000000000..063c6b63d9 --- /dev/null +++ b/Documentation/config/pretty.txt @@ -0,0 +1,9 @@ +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/Documentation/config/protocol.txt b/Documentation/config/protocol.txt new file mode 100644 index 0000000000..c46e9b3d00 --- /dev/null +++ b/Documentation/config/protocol.txt @@ -0,0 +1,64 @@ +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:: + If set, clients will attempt to communicate with a server + using the specified protocol version. If the server does + not support it, communication falls back to version 0. + If unset, the default is `0`, unless `feature.experimental` + is enabled, in which case the default is `2`. + 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/Documentation/config/pull.txt b/Documentation/config/pull.txt new file mode 100644 index 0000000000..5404830609 --- /dev/null +++ b/Documentation/config/pull.txt @@ -0,0 +1,37 @@ +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` (or just 'm'), 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` (or just 'p', 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` (or just 'i'), 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/Documentation/config/push.txt b/Documentation/config/push.txt new file mode 100644 index 0000000000..f5e5b38c68 --- /dev/null +++ b/Documentation/config/push.txt @@ -0,0 +1,116 @@ +push.default:: + Defines the action `git push` should take if no refspec is + given (whether from the command-line, config, or elsewhere). + 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 + 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'. + If not set, 'no' is used by default, unless 'submodule.recurse' is + set (in which case a 'true' value means 'on-demand'). diff --git a/Documentation/config/rebase.txt b/Documentation/config/rebase.txt new file mode 100644 index 0000000000..7f7a07d22f --- /dev/null +++ b/Documentation/config/rebase.txt @@ -0,0 +1,70 @@ +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.backend:: + Default backend to use for rebasing. Possible choices are + 'apply' or 'merge'. In the future, if the merge backend gains + all remaining capabilities of the apply backend, this setting + may become unused. + +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/Documentation/config/receive.txt b/Documentation/config/receive.txt new file mode 100644 index 0000000000..65f78aac37 --- /dev/null +++ b/Documentation/config/receive.txt @@ -0,0 +1,123 @@ +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/Documentation/config/remote.txt b/Documentation/config/remote.txt new file mode 100644 index 0000000000..a8e6437a90 --- /dev/null +++ b/Documentation/config/remote.txt @@ -0,0 +1,86 @@ +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]. + +remote.<name>.promisor:: + When set to true, this remote will be used to fetch promisor + objects. + +remote.<name>.partialclonefilter:: + The filter that will be applied when fetching from this + promisor remote. diff --git a/Documentation/config/remotes.txt b/Documentation/config/remotes.txt new file mode 100644 index 0000000000..4cfe03221e --- /dev/null +++ b/Documentation/config/remotes.txt @@ -0,0 +1,3 @@ +remotes.<group>:: + The list of remotes which are fetched by "git remote update + <group>". See linkgit:git-remote[1]. diff --git a/Documentation/config/repack.txt b/Documentation/config/repack.txt new file mode 100644 index 0000000000..9c413e177e --- /dev/null +++ b/Documentation/config/repack.txt @@ -0,0 +1,27 @@ +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/Documentation/config/rerere.txt b/Documentation/config/rerere.txt new file mode 100644 index 0000000000..40abdf6a6b --- /dev/null +++ b/Documentation/config/rerere.txt @@ -0,0 +1,12 @@ +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/Documentation/config/reset.txt b/Documentation/config/reset.txt new file mode 100644 index 0000000000..63b7c45aac --- /dev/null +++ b/Documentation/config/reset.txt @@ -0,0 +1,2 @@ +reset.quiet:: + When set to true, 'git reset' will default to the '--quiet' option. diff --git a/Documentation/config/sendemail.txt b/Documentation/config/sendemail.txt new file mode 100644 index 0000000000..0006faf800 --- /dev/null +++ b/Documentation/config/sendemail.txt @@ -0,0 +1,63 @@ +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/Documentation/config/sequencer.txt b/Documentation/config/sequencer.txt new file mode 100644 index 0000000000..b48d532a96 --- /dev/null +++ b/Documentation/config/sequencer.txt @@ -0,0 +1,5 @@ +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/Documentation/config/showbranch.txt b/Documentation/config/showbranch.txt new file mode 100644 index 0000000000..e79ecd9ee9 --- /dev/null +++ b/Documentation/config/showbranch.txt @@ -0,0 +1,3 @@ +showBranch.default:: + The default set of branches for linkgit:git-show-branch[1]. + See linkgit:git-show-branch[1]. diff --git a/Documentation/config/splitindex.txt b/Documentation/config/splitindex.txt new file mode 100644 index 0000000000..afdb186df8 --- /dev/null +++ b/Documentation/config/splitindex.txt @@ -0,0 +1,24 @@ +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/Documentation/config/ssh.txt b/Documentation/config/ssh.txt new file mode 100644 index 0000000000..2ca4bf93e1 --- /dev/null +++ b/Documentation/config/ssh.txt @@ -0,0 +1,35 @@ +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/Documentation/config/stash.txt b/Documentation/config/stash.txt new file mode 100644 index 0000000000..00eb35434e --- /dev/null +++ b/Documentation/config/stash.txt @@ -0,0 +1,16 @@ +stash.useBuiltin:: + Unused configuration variable. Used in Git versions 2.22 to + 2.26 as an escape hatch to enable the legacy shellscript + implementation of stash. 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. + +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/Documentation/config/status.txt b/Documentation/config/status.txt new file mode 100644 index 0000000000..0fc704ab80 --- /dev/null +++ b/Documentation/config/status.txt @@ -0,0 +1,77 @@ +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/Documentation/config/submodule.txt b/Documentation/config/submodule.txt new file mode 100644 index 0000000000..d7a63c8c12 --- /dev/null +++ b/Documentation/config/submodule.txt @@ -0,0 +1,92 @@ +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 + (`checkout`, `fetch`, `grep`, `pull`, `push`, `read-tree`, `reset`, + `restore` and `switch`) except `clone` and `ls-files`. + Defaults to false. + When set to true, it can be deactivated via the + `--no-recurse-submodules` option. Note that some Git commands + lacking this option may call some of the above commands affected by + `submodule.recurse`; for instance `git remote update` will call + `git fetch` but does not have a `--no-recurse-submodules` option. + For these commands a workaround is to temporarily change the + configuration value by using `git -c submodule.recurse=0`. + +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`. Note that if set to `ignore` + or `info`, and if there is an error with the computed alternate, the + clone proceeds as if no alternate was specified. diff --git a/Documentation/config/tag.txt b/Documentation/config/tag.txt new file mode 100644 index 0000000000..5062a057ff --- /dev/null +++ b/Documentation/config/tag.txt @@ -0,0 +1,17 @@ +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 affect tag signing + behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options. diff --git a/Documentation/config/tar.txt b/Documentation/config/tar.txt new file mode 100644 index 0000000000..de8ff48ea9 --- /dev/null +++ b/Documentation/config/tar.txt @@ -0,0 +1,6 @@ +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/Documentation/config/trace2.txt b/Documentation/config/trace2.txt new file mode 100644 index 0000000000..01d3afd8a8 --- /dev/null +++ b/Documentation/config/trace2.txt @@ -0,0 +1,71 @@ +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.envVars:: + A comma-separated list of "important" environment variables that should + be recorded in the trace2 output. For example, + `GIT_HTTP_USER_AGENT,GIT_CONFIG` would cause the trace2 output to + contain events listing the overrides for HTTP user agent and the + location of the Git configuration file (assuming any are set). May be + overriden by the `GIT_TRACE2_ENV_VARS` 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. + +trace2.maxFiles:: + Integer. When writing trace files to a target directory, do not + write additional traces if we would exceed this many files. Instead, + write a sentinel file that will block further tracing to this + directory. Defaults to 0, which disables this check. diff --git a/Documentation/config/transfer.txt b/Documentation/config/transfer.txt new file mode 100644 index 0000000000..f5b6245270 --- /dev/null +++ b/Documentation/config/transfer.txt @@ -0,0 +1,71 @@ +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/Documentation/config/uploadarchive.txt b/Documentation/config/uploadarchive.txt new file mode 100644 index 0000000000..e0698e8c1d --- /dev/null +++ b/Documentation/config/uploadarchive.txt @@ -0,0 +1,6 @@ +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/Documentation/config/uploadpack.txt b/Documentation/config/uploadpack.txt new file mode 100644 index 0000000000..ed1c835695 --- /dev/null +++ b/Documentation/config/uploadpack.txt @@ -0,0 +1,65 @@ +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/Documentation/config/url.txt b/Documentation/config/url.txt new file mode 100644 index 0000000000..e5566c371d --- /dev/null +++ b/Documentation/config/url.txt @@ -0,0 +1,30 @@ +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/Documentation/config/user.txt b/Documentation/config/user.txt new file mode 100644 index 0000000000..59aec7c3ae --- /dev/null +++ b/Documentation/config/user.txt @@ -0,0 +1,38 @@ +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. ++ +Note that the `name` forms of these variables conventionally refer to +some form of a personal name. See linkgit:git-commit[1] and the +environment variables section of linkgit:git[1] for more information on +these settings and the `credential.username` option if you're looking +for authentication credentials instead. + +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/Documentation/config/versionsort.txt b/Documentation/config/versionsort.txt new file mode 100644 index 0000000000..6c7cc054fa --- /dev/null +++ b/Documentation/config/versionsort.txt @@ -0,0 +1,33 @@ +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/Documentation/config/web.txt b/Documentation/config/web.txt new file mode 100644 index 0000000000..beec8d1303 --- /dev/null +++ b/Documentation/config/web.txt @@ -0,0 +1,4 @@ +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/Documentation/config/worktree.txt b/Documentation/config/worktree.txt new file mode 100644 index 0000000000..048e349482 --- /dev/null +++ b/Documentation/config/worktree.txt @@ -0,0 +1,9 @@ +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/Documentation/date-formats.txt b/Documentation/date-formats.txt index c000f08a9d..f1097fac69 100644 --- a/Documentation/date-formats.txt +++ b/Documentation/date-formats.txt @@ -1,17 +1,17 @@ DATE FORMATS ------------ -The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables +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> <timezone offset>`, where `<unix + It is `<unix timestamp> <time zone offset>`, where `<unix timestamp>` is the number of seconds since the UNIX epoch. - `<timezone offset>` is a positive or negative offset from UTC. - For example CET (which is 2 hours ahead UTC) is `+0200`. + `<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 @@ -20,7 +20,9 @@ RFC 2822:: 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. + `T` character as well. Fractional parts of a second will be ignored, + for example `2005-04-07T22:13:13.019` will be treated as + `2005-04-07T22:13:13`. + 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/Documentation/diff-format.txt b/Documentation/diff-format.txt index 15c7e794f4..fbbd410a84 100644 --- a/Documentation/diff-format.txt +++ b/Documentation/diff-format.txt @@ -26,12 +26,12 @@ 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 +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: @@ -46,11 +46,11 @@ That is, from the left to the right: . 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. +. 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. +. 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. +. an LF or a NUL when `-z` option is used, to terminate the record. Possible status letters are: @@ -61,12 +61,13 @@ Possible status letters are: - 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) + 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), and are the only ones to be so. +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. @@ -74,18 +75,19 @@ and it is out of sync with the index. Example: ------------------------------------------------ -:100644 100644 5be4a4...... 000000...... M file.c +:100644 100644 5be4a4a 0000000 M file.c ------------------------------------------------ -When `-z` option is not used, TAB, LF, and backslash characters -in pathnames are represented as `\t`, `\n`, and `\\`, -respectively. +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 +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: @@ -93,12 +95,26 @@ from the format described above in the following way: . there are more "src" modes and "src" sha1 . status is concatenated status characters for each parent . no optional "score" number -. single path, only for "dst" +. tab-separated pathname(s) of the file -Example: +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 describe.c +::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 diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt index 55f499a160..e8ed6470fb 100644 --- a/Documentation/diff-generate-patch.txt +++ b/Documentation/diff-generate-patch.txt @@ -1,12 +1,16 @@ -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. +Generating patch text with -p +----------------------------- + +Running +linkgit:git-diff[1], +linkgit:git-log[1], +linkgit:git-show[1], +linkgit:git-diff-index[1], +linkgit:git-diff-tree[1], or +linkgit:git-diff-files[1] +with the `-p` option produces patch text. +You can customize the creation of patch text 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: @@ -49,14 +53,13 @@ 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 index line includes the blob object names 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. TAB, LF, double quote and backslash characters in pathnames - are represented as `\t`, `\n`, `\"` and `\\`, respectively. - If there is need for such substitution then the whole - pathname is put in double quotes. +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. @@ -71,17 +74,17 @@ separate lines indicate the old and the new mode. rename to a -combined diff format +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 +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: +A "combined diff" format looks like this: ------------ diff --combined describe.c @@ -114,11 +117,11 @@ index fabadb8,cc95eb0..4866510 ------------ 1. It is preceded with a "git diff" header, that looks like - this (when '-c' option is used): + this (when the `-c` option is used): diff --combined file + -or like this (when '--cc' option is used): +or like this (when the `--cc` option is used): diff --cc file @@ -144,11 +147,24 @@ copying detection) are designed to work with diff of two 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 + meant to be applied. The change is similar to the change in the extended 'index' header: @@@ <from-file-range> <from-file-range> <to-file-range> @@@ @@ -174,7 +190,7 @@ 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 nor file2). Also eight other lines are the same +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 diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index bbed2cd79c..7987d72b02 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -23,26 +23,49 @@ ifndef::git-format-patch[] -u:: --patch:: Generate patch (see section on generating patches). - {git-diff? This is the default.} -endif::git-format-patch[] +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. + 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:: - Generate the raw format. - {git-diff-core? This is the default.} +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[] @@ -50,6 +73,13 @@ ifndef::git-format-patch[] 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. @@ -60,6 +90,16 @@ endif::git-format-patch[] --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: + @@ -76,7 +116,7 @@ endif::git-format-patch[] low-occurrence common elements". -- + -For instance, if you configured diff.algorithm variable to a +For instance, if you configured the `diff.algorithm` variable to a non-default value and want to use the default one, then you have to use `--diff-algorithm=default` option. @@ -98,6 +138,14 @@ have to use `--diff-algorithm=default` option. These parameters can also be set individually with `--stat-width=<width>`, `--stat-name-width=<name-width>` and `--stat-count=<count>`. +--compact-summary:: + Output a condensed summary of extended header information such + as file creations or deletions ("new" or "gone", optionally "+l" + if it's a symlink) and mode changes ("+x" or "-x" for adding + or removing executable bit respectively) in diffstat. The + information is put between the filename part and the graph + part. Implies `--stat`. + --numstat:: Similar to `--stat`, but shows number of added and deleted lines in decimal notation and pathname without @@ -110,6 +158,7 @@ These parameters can also be set individually with `--stat-width=<width>`, 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 @@ -154,6 +203,12 @@ 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. @@ -177,10 +232,9 @@ ifndef::git-log[] given, do not munge pathnames and use NULs as output field terminators. endif::git-log[] + -Without this option, each pathname output will have TAB, LF, double quotes, -and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`, -respectively, and the pathname will be enclosed in double quotes if -any of those replacements occurred. +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. @@ -190,13 +244,16 @@ any of those replacements occurred. of the `--diff-filter` option on what the status letters mean. --submodule[=<format>]:: - Specify how differences in submodules are shown. When `--submodule` - or `--submodule=log` is given, the 'log' format is used. This format lists - the commits in the range like linkgit:git-submodule[1] `summary` does. - Omitting the `--submodule` option or specifying `--submodule=short`, - uses the 'short' format. This format just shows the names of the commits - at the beginning and end of the range. Can be tweaked via the - `diff.submodule` configuration variable. + Specify how differences in submodules are shown. When specifying + `--submodule=short` the 'short' format is used. This format just + shows the names of the commits at the beginning and end of the range. + When `--submodule` or `--submodule=log` is specified, the 'log' + format is used. This format lists the commits in the range like + linkgit:git-submodule[1] `summary` does. When `--submodule=diff` + is specified, the 'diff' format is used. This format shows an + inline diff of the changes in the submodule contents between the + commit range. Defaults to `diff.submodule` or the 'short' format + if the config option is unset. --color[=<when>]:: Show colored diff. @@ -214,6 +271,81 @@ ifdef::git-diff[] 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 @@ -254,8 +386,11 @@ 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[1] or linkgit:git-config[1]. Giving it explicitly +linkgit:gitattributes[5] or linkgit:git-config[1]. Giving it explicitly overrides any diff driver or configuration setting. Diff drivers override configuration settings. @@ -268,16 +403,30 @@ endif::git-format-patch[] 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 whitespace errors. What are - considered whitespace errors is controlled by `core.whitespace` + Warn if changes introduce conflict markers or whitespace errors. + What are considered whitespace errors is controlled by `core.whitespace` configuration. By default, trailing whitespaces (including - lines that solely consist of whitespaces) and a space character + lines that consist solely of whitespaces) and a space character that is immediately followed by a tab character inside the initial indent of the line are considered whitespace errors. Exits with non-zero status if problems are found. Not compatible 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:: @@ -287,7 +436,7 @@ endif::git-format-patch[] --binary:: In addition to `--full-index`, output a binary diff that - can be applied with `git-apply`. + can be applied with `git-apply`. Implies `--patch`. --abbrev[=<n>]:: Instead of showing the full 40-byte hexadecimal object @@ -358,9 +507,9 @@ endif::git-log[] --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` nor `git apply`; this is + 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 lack + 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. + @@ -386,6 +535,15 @@ ifndef::git-format-patch[] 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 @@ -397,6 +555,8 @@ 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 @@ -407,18 +567,30 @@ To illustrate the difference between `-S<regex> --pickaxe-regex` and file: + ---- -+ return !regexec(regexp, two->ptr, 1, ®match, 0); ++ return frotz(nitfol, two->ptr, 1, 0); ... -- hit = !regexec(regexp, mf2.ptr, 1, ®match, 0); +- hit = frotz(nitfol, mf2.ptr, 1, 0); ---- + -While `git log -G"regexec\(regexp"` will show this commit, `git log --S"regexec\(regexp" --pickaxe-regex` will not (because the number of +While `git log -G"frotz\(nitfol"` will show this commit, `git log +-S"frotz\(nitfol" --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 @@ -427,30 +599,70 @@ information. --pickaxe-regex:: Treat the <string> given to `-S` as an extended POSIX regular expression to match. + endif::git-format-patch[] -O<orderfile>:: - Output the patch in the order specified in the - <orderfile>, which has one shell glob pattern per line. + 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. +endif::git-format-patch[] --relative[=<path>]:: +--no-relative:: 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[] + `--no-relative` can be used to countermand both `diff.relative` config + option and previous `--relative`. -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. @@ -472,6 +684,8 @@ endif::git-format-patch[] --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:: @@ -530,5 +744,16 @@ endif::git-format-patch[] --no-prefix:: Do not show any source or destination prefix. +--line-prefix=<prefix>:: + Prepend an additional prefix to every line of output. + +--ita-invisible-in-index:: + By default entries added by "git add -N" appear as an existing + empty file in "git diff" and a new file in "git diff --cached". + This option makes the entry appear as a new file in "git diff" + and non-existent in "git diff --cached". This option could be + reverted with `--ita-visible-in-index`. Both options are + experimental and could be removed in future. + For more detailed explanation on these common options, see also linkgit:gitdiffcore[7]. diff --git a/Documentation/doc-diff b/Documentation/doc-diff new file mode 100755 index 0000000000..1694300e50 --- /dev/null +++ b/Documentation/doc-diff @@ -0,0 +1,186 @@ +#!/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-footer cut away footer +" +SUBDIRECTORY_OK=1 +. "$(git --exec-path)/git-sh-setup" + +parallel= +force= +clean= +from_program= +to_program= +cut_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-footer) + cut_footer=-cut-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_footer && +to_dir=$to_oid$to_program$cut_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_footer" = "-cut-footer" + then + for f in $(find "$tmp/rendered/$dname" -type f) + do + head -n -2 "$f" | sed -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/Documentation/everyday.txto b/Documentation/everyday.txto new file mode 100644 index 0000000000..ae555bd47e --- /dev/null +++ b/Documentation/everyday.txto @@ -0,0 +1,9 @@ +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/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index ba1fe49582..6e2a160a47 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -8,27 +8,74 @@ option old data in `.git/FETCH_HEAD` will be overwritten. --depth=<depth>:: - Deepen or shorten the history of a 'shallow' repository created by - `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1]) - to the specified number of commits from the tip of each remote - branch history. Tags for the deepened commits are not fetched. + 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:: - Convert a shallow repository to a complete one, removing all - the limitations imposed by shallow repositories. + If the source repository is complete, convert a shallow + repository to a complete one, removing all the limitations + imposed by shallow repositories. ++ +If the source repository is shallow, fetch as much as possible so that +the current repository has the same history as the source repository. + +--update-shallow:: + By default when fetching from a shallow repository, + `git fetch` refuses refs that require updating + .git/shallow. This option updates .git/shallow and accept such + refs. + +--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 `<rbranch>:<lbranch>` - refspec, it refuses to update the local branch - `<lbranch>` unless the remote branch `<rbranch>` it - fetches is a descendant of `<lbranch>`. This option - overrides that check. + 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:: @@ -39,34 +86,74 @@ ifndef::git-pull[] 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. + +--[no-]write-commit-graph:: + Write a commit-graph after fetching. This overrides the config + setting `fetch.writeCommitGraph`. +endif::git-pull[] + -p:: --prune:: - After fetching, remove any remote-tracking branches which - no longer exist on the remote. -endif::git-pull[] + 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. +ifndef::git-pull[] ++ +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. -ifdef::git-pull[] ---no-tags:: endif::git-pull[] + ifndef::git-pull[] -n:: ---no-tags:: endif::git-pull[] +--no-tags:: By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally. This option disables this automatic tag following. The default - behavior for a remote may be specified with the remote.<name>.tagopt + 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. Providing an empty `<refspec>` to the + `--refmap` option causes Git to ignore the configured + refspecs and rely entirely on the refspecs supplied as + command-line arguments. See section on "Configured Remote-tracking + Branches" for details. + -t:: --tags:: - This is a short-hand for giving `refs/tags/*:refs/tags/*` - refspec from the command line, to ask all tags to be fetched - and stored locally. Because this acts as an explicit - refspec, the default refspecs (configured with the - remote.$name.fetch variable) are overridden and not used. + Fetch all tags from the remote (i.e., fetch remote tags + `refs/tags/*` into local tags with the same name), in addition + to whatever else would otherwise be fetched. Using this + option alone does not subject tags to pruning, even if --prune + is used (though tags may be pruned anyway if they are also the + destination of an explicit refspec; see `--prune`). +ifndef::git-pull[] --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 @@ -76,12 +163,36 @@ ifndef::git-pull[] 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. + clone. By default, 'on-demand' is used, unless + `fetch.recurseSubmodules` is set (see linkgit:git-config[1]). +endif::git-pull[] + +-j:: +--jobs=<n>:: + Number of parallel children to be used for all forms of fetching. ++ +If the `--multiple` option was specified, the different remotes will be fetched +in parallel. If multiple submodules are fetched, they will be fetched in +parallel. To control them independently, use the config settings +`fetch.parallel` and `submodule.fetchJobs` (see linkgit:git-config[1]). ++ +Typically, parallel recursive and multi-remote fetches will be faster. By +default fetches are performed sequentially, not in parallel. +ifndef::git-pull[] --no-recurse-submodules:: Disable recursive fetching of submodules (this has the same effect as - using the '--recurse-submodules=no' option). + using the `--recurse-submodules=no` option). +endif::git-pull[] +--set-upstream:: + If the remote is fetched successfully, pull and add upstream + (tracking) reference, used by argument-less + linkgit:git-pull[1] and other commands. For more information, + see `branch.<name>.merge` and `branch.<name>.remote` in + linkgit:git-config[1]. + +ifndef::git-pull[] --submodule-prefix=<path>:: Prepend <path> to paths printed in informative messages such as "Fetching submodule foo". This option is used @@ -94,7 +205,6 @@ ifndef::git-pull[] 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:: @@ -104,10 +214,11 @@ endif::git-pull[] to communicate with 'git fetch', and unless you are implementing your own Porcelain you are not supposed to use it. +endif::git-pull[] --upload-pack <upload-pack>:: When given, and the repository to fetch from is handled - by 'git fetch-pack', '--exec=<upload-pack>' is passed to + 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. @@ -128,3 +239,33 @@ endif::git-pull[] 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/Documentation/git-add.txt b/Documentation/git-add.txt index 48754cbc67..be5e3ac54b 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -8,9 +8,10 @@ git-add - Add file contents to the index SYNOPSIS -------- [verse] -'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p] +'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] + [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize] + [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]] [--] [<pathspec>...] DESCRIPTION @@ -24,7 +25,7 @@ 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 directory, and before running +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. @@ -53,8 +54,17 @@ OPTIONS Files to add content from. Fileglobs (e.g. `*.c`) can be given to add all matching files. Also a leading directory name (e.g. `dir` to add `dir/file1` - and `dir/file2`) can be given to add all files in the - directory, recursively. + and `dir/file2`) can be given to update the index to + match the current state of the directory as a whole (e.g. + specifying `dir` will record not just a file `dir/file1` + modified in the working tree, a file `dir/file2` added to + the working tree, but also a file `dir/file3` removed from + the working tree). Note that older versions of Git used + to ignore removed files; use `--no-all` option if you want + to add modified or new files but ignore removed ones. ++ +For more details about the <pathspec> syntax, see the 'pathspec' entry +in linkgit:gitglossary[7]. -n:: --dry-run:: @@ -87,7 +97,8 @@ 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:: +-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. @@ -104,23 +115,23 @@ apply to the index. See EDITING PATCHES below. <pathspec>. This removes as well as modifies index entries to match the working tree, but adds no new files. + -If no <pathspec> is given, the current version of Git defaults to -"."; in other words, update all tracked files in the current directory -and its subdirectories. This default will change in a future version -of Git, hence the form without <pathspec> should not be used. +If no <pathspec> is given when `-u` option is used, all +tracked files in the entire working tree are updated (old versions +of Git used to limit the update to the current directory and its +subdirectories). -A:: --all:: --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 + entry. This adds, modifies, and removes index entries to match the working tree. + -If no <pathspec> is given, the current version of Git defaults to -"."; in other words, update all files in the current directory -and its subdirectories. This default will change in a future version -of Git, hence the form without <pathspec> should not be used. +If no <pathspec> is given when `-A` option is used, all +files in the entire working tree are updated (old versions +of Git used to limit the update to the current directory and its +subdirectories). --no-all:: --ignore-removal:: @@ -129,11 +140,9 @@ of Git, hence the form without <pathspec> should not be used. files that have been removed from the working tree. This option is a no-op when no <pathspec> is used. + -This option is primarily to help the current users of Git, whose -"git add <pathspec>..." ignores removed files. In future versions -of Git, "git add <pathspec>..." will be a synonym to "git add -A -<pathspec>..." and "git add --ignore-removal <pathspec>..." will behave like -today's "git add <pathspec>...", ignoring removed files. +This option is primarily to help users who are used to older +versions of Git, whose "git add <pathspec>..." was a synonym +for "git add --no-all <pathspec>...", i.e. ignored removed files. -N:: --intent-to-add:: @@ -160,26 +169,49 @@ today's "git add <pathspec>...", ignoring removed files. 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. + +--pathspec-from-file=<file>:: + Pathspec is passed in `<file>` instead of commandline args. If + `<file>` is exactly `-` then standard input is used. Pathspec + elements are separated by LF or CR/LF. Pathspec elements can be + quoted as explained for the configuration variable `core.quotePath` + (see linkgit:git-config[1]). See also `--pathspec-file-nul` and + global `--literal-pathspecs`. + +--pathspec-file-nul:: + Only meaningful with `--pathspec-from-file`. Pathspec elements are + separated with NUL character and all other characters are taken + literally (including newlines and quotes). + \--:: 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). -Configuration -------------- - -The optional configuration variable `core.excludesfile` indicates a path to a -file containing patterns of file names to exclude from git-add, similar to -$GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to -those in info/exclude. See linkgit:gitignore[5]. - - EXAMPLES -------- * Adds content from all `*.txt` files under `Documentation` directory -and its subdirectories: + and its subdirectories: + ------------ $ git add Documentation/\*.txt @@ -199,7 +231,7 @@ Because this example lets the shell expand the asterisk (i.e. you are listing the files explicitly), it does not consider `subdir/git-foo.sh`. -Interactive mode +INTERACTIVE MODE ---------------- When the command enters the interactive mode, it shows the output of the 'status' subcommand, and then goes into its @@ -296,9 +328,9 @@ patch:: y - stage this hunk n - do not stage this hunk - q - quit; do not stage this hunk nor any of the remaining ones + 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 nor any of the 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 @@ -313,7 +345,7 @@ 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`. +variable `interactive.singleKey` to `true`. diff:: diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index 54d8461d61..38c0852139 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -10,13 +10,13 @@ SYNOPSIS -------- [verse] 'git am' [--signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8] - [--3way] [--interactive] [--committer-date-is-author-date] + [--[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] + [--[no-]scissors] [-S[<keyid>]] [--patch-format=<format>] [(<mbox> | <Maildir>)...] -'git am' (--continue | --skip | --abort) +'git am' (--continue | --skip | --abort | --quit | --show-current-patch[=(diff|raw)]) DESCRIPTION ----------- @@ -35,6 +35,7 @@ OPTIONS --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:: @@ -52,11 +53,23 @@ OPTIONS -c:: --scissors:: Remove everything in body before a scissors line (see - linkgit:git-mailinfo[1]). + 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. @@ -78,12 +91,19 @@ default. You can use `--no-utf8` to override this. -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. + 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-date:: --ignore-space-change:: --ignore-whitespace:: --whitespace=<option>:: @@ -97,6 +117,13 @@ default. You can use `--no-utf8` to override this. program that applies the patch. +--patch-format:: + By default the command will try to detect the patch format + automatically. This option allows the user to bypass the automatic + detection and specify the patch format that the patch(es) should be + interpreted as. Valid formats are mbox, mboxrd, + stgit, stgit-series and hg. + -i:: --interactive:: Run interactively. @@ -119,6 +146,15 @@ default. You can use `--no-utf8` to override this. Skip the current patch. This is only meaningful when restarting an aborted patch. +-S[<keyid>]:: +--gpg-sign[=<keyid>]:: +--no-gpg-sign:: + 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` is useful to + countermand both `commit.gpgSign` configuration variable, and + earlier `--gpg-sign`. + --continue:: -r:: --resolved:: @@ -139,6 +175,16 @@ default. You can use `--no-utf8` to override this. --abort:: Restore the original branch and abort the patching operation. +--quit:: + Abort the patching operation but keep HEAD and the index + untouched. + +--show-current-patch[=(diff|raw)]:: + Show the message at which `git am` has stopped due to + conflicts. If `raw` is specified, show the raw contents of + the e-mail message; if `diff`, show the diff portion only. + Defaults to `raw`. + DISCUSSION ---------- @@ -149,8 +195,8 @@ 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. +"From: ", "Date: ", 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 @@ -171,12 +217,12 @@ 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' +. 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. + 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, @@ -189,6 +235,11 @@ commits, like running 'git am' on the wrong branch or an error in the commits that is more easily fixed by changing the mailbox (e.g. errors in the "From:" lines). +HOOKS +----- +This command can run `applypatch-msg`, `pre-applypatch`, +and `post-applypatch` hooks. See linkgit:githooks[5] for more +information. SEE ALSO -------- diff --git a/Documentation/git-annotate.txt b/Documentation/git-annotate.txt index 05fd482b74..e44a831339 100644 --- a/Documentation/git-annotate.txt +++ b/Documentation/git-annotate.txt @@ -8,7 +8,7 @@ git-annotate - Annotate file lines with commit information SYNOPSIS -------- [verse] -'git annotate' [options] file [revision] +'git annotate' [<options>] <file> [<revision>] DESCRIPTION ----------- diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index f605327946..b9aa39000f 100644 --- a/Documentation/git-apply.txt +++ b/Documentation/git-apply.txt @@ -9,18 +9,20 @@ git-apply - Apply a patch to files and/or to the index SYNOPSIS -------- [verse] -'git apply' [--stat] [--numstat] [--summary] [--check] [--index] [--3way] +'git apply' [--stat] [--numstat] [--summary] [--check] [--index | --intent-to-add] [--3way] [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse] [--allow-binary-replacement | --binary] [--reject] [-z] [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached] - [--ignore-space-change | --ignore-whitespace ] + [--ignore-space-change | --ignore-whitespace] [--whitespace=(nowarn|warn|fix|error|error-all)] [--exclude=<path>] [--include=<path>] [--directory=<root>] - [--verbose] [<patch>...] + [--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, @@ -64,7 +66,7 @@ OPTIONS 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 + up to date, it is flagged as an error. This flag also causes the index file to be updated. --cached:: @@ -72,6 +74,14 @@ OPTIONS cached data, apply the patch, and store the result in the index without using the working tree. This implies `--index`. +--intent-to-add:: + When applying the patch only to the working tree, mark new + files to be added to the index later (see `--intent-to-add` + option in linkgit:git-add[1]). This option is ignored unless + running in a Git repository and `--index` is not specified. + Note that `--index` could be implied by other options such + as `--cached` or `--3way`. + -3:: --3way:: When the patch does not apply cleanly, fall back on 3-way merge if @@ -106,14 +116,15 @@ the information is read from the current index instead. When `--numstat` has been given, do not munge pathnames, but use a NUL-terminated machine-readable format. + -Without this option, each pathname output will have TAB, LF, double quotes, -and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`, -respectively, and the pathname will be enclosed in double quotes if -any of those replacements occurred. +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 slashes from traditional diff paths. The - default is 1. + Remove <n> leading path components (separated by slashes) from + traditional diff paths. E.g., with `-p2`, a patch against + `a/dir/file` will be applied directly to `file`. The default is + 1. -C<n>:: Ensure at least <n> lines of surrounding context match before @@ -229,10 +240,20 @@ 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`. -Configuration +--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:: +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. @@ -240,7 +261,7 @@ apply.whitespace:: When no `--whitespace` flag is given from the command line, this configuration item is used as the default. -Submodules +SUBMODULES ---------- If the patch contains any changes to submodules then 'git apply' treats these changes as follows. @@ -248,7 +269,7 @@ 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 +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 diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt index 163b9f6f41..a595a0ffee 100644 --- a/Documentation/git-archimport.txt +++ b/Documentation/git-archimport.txt @@ -3,7 +3,7 @@ git-archimport(1) NAME ---- -git-archimport - Import an Arch repository into Git +git-archimport - Import a GNU Arch repository into Git SYNOPSIS @@ -14,7 +14,8 @@ SYNOPSIS DESCRIPTION ----------- -Imports a project from one or more Arch repositories. It will follow branches +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 @@ -96,7 +97,7 @@ OPTIONS pruned. -a:: - Attempt to auto-register archives at http://mirrors.sourcecontrol.net + Attempt to auto-register archives at `http://mirrors.sourcecontrol.net` This is particularly useful with the -D option. -t <tmpdir>:: diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt index b97aaab4ed..cfa1e4ebe4 100644 --- a/Documentation/git-archive.txt +++ b/Documentation/git-archive.txt @@ -65,7 +65,10 @@ OPTIONS --remote=<repo>:: Instead of making a tar archive from the local repository, - retrieve a tar archive from a remote repository. + retrieve a tar archive from a remote repository. Note that the + remote repository may place restrictions on which sha1 + expressions may be allowed in `<tree-ish>`. See + linkgit:git-upload-archive[1] for details. --exec=<git-upload-archive>:: Used with --remote to specify the path to the diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt index afeb86c6cd..3ba49e85b7 100644 --- a/Documentation/git-bisect-lk2009.txt +++ b/Documentation/git-bisect-lk2009.txt @@ -119,7 +119,7 @@ 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 +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 @@ -132,7 +132,7 @@ 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 +And then this is what Ingo Molnar (a well known Linux kernel developer) says about his use of git bisect: _____________ @@ -158,7 +158,7 @@ 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. +combinatorial explosion. In fact the problem is that big software often has many different configuration options and that each test case should pass for each @@ -366,7 +366,7 @@ skip" to do the same thing. (In fact the special exit code 125 makes 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 +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 @@ -633,11 +633,11 @@ and so at step 3) we compute f(X). Let's take the following graph as an example: ------------- - G-H-I-J - / \ + G-H-I-J + / \ A-B-C-D-E-F O - \ / - K-L-M-N + \ / + K-L-M-N ------------- If we compute the following non optimal function on it: @@ -649,25 +649,25 @@ g(X) = min(number_of_ancestors(X), number_of_descendants(X)) we get: ------------- - 4 3 2 1 - G-H-I-J + 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 + \ / + 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 + 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 + \ / + K-L-M-N + 7 7 6 5 ------------- So we chose G, H, K or L as the best bisection point, which is better @@ -773,7 +773,7 @@ forked of the main branch at a commit named "D" like this: ------------- A-B-C-D-E-F-G <--main \ - H-I-J <--dev + H-I-J <--dev ------------- The commit "D" is called a "merge base" for branch "main" and "dev" @@ -1103,7 +1103,7 @@ _____________ Combining test suites, git bisect and other systems together ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -We have seen that test suites an git bisect are very powerful when +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. @@ -1321,7 +1321,7 @@ 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 @@ -1347,12 +1347,12 @@ author to given a talk and for publishing this paper. References ---------- -- [[[1]]] http://www.nist.gov/public_affairs/releases/n02-10.htm['Software Errors Cost U.S. Economy $59.5 Billion Annually'. Nist News Release.] -- [[[2]]] http://java.sun.com/docs/codeconv/html/CodeConventions.doc.html#16712['Code Conventions for the Java Programming Language'. Sun Microsystems.] -- [[[3]]] http://en.wikipedia.org/wiki/Software_maintenance['Software maintenance'. Wikipedia.] -- [[[4]]] http://article.gmane.org/gmane.comp.version-control.git/45195/[Junio C Hamano. 'Automated bisect success story'. Gmane.] -- [[[5]]] http://lwn.net/Articles/317154/[Christian Couder. 'Fully automated bisecting with "git bisect run"'. LWN.net.] -- [[[6]]] http://lwn.net/Articles/277872/[Jonathan Corbet. 'Bisection divides users and developers'. LWN.net.] -- [[[7]]] http://article.gmane.org/gmane.linux.scsi/36652/[Ingo Molnar. 'Re: BUG 2.6.23-rc3 can't see sd partitions on Alpha'. Gmane.] -- [[[8]]] http://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]]] http://github.com/Ealdwulf/bbchop[Ealdwulf. 'bbchop'. GitHub.] +- [[[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://lore.kernel.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]]] https://lore.kernel.org/lkml/20071207113734.GA14598@elte.hu/[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/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index f986c5cb3a..7586c5a843 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -3,7 +3,7 @@ git-bisect(1) NAME ---- -git-bisect - Find by binary search the change that introduced a bug +git-bisect - Use binary search to find the commit that introduced a bug SYNOPSIS @@ -16,74 +16,89 @@ DESCRIPTION The command takes various subcommands, and different options depending on the subcommand: - git bisect help - git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<paths>...] - git bisect bad [<rev>] - git bisect good [<rev>...] + 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 + git bisect (visualize|view) git bisect replay <logfile> git bisect log git bisect run <cmd>... + git bisect help -This command uses 'git rev-list --bisect' to help drive the -binary search process to find which change introduced a bug, given an -old "good" commit object name and a later "bad" commit object name. - -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. +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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Using the Linux kernel tree as an example, basic use of the bisect -command is as follows: +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 was the last version - # tested that was good +$ 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) ------------------------------------------------ -When you have specified at least one bad and one good version, the -command bisects the revision tree and outputs something similar to -the following: +You should now compile the checked-out version and test it. If that +version works correctly, type ------------------------------------------------ -Bisecting: 675 revisions left to test after this +$ git bisect good ------------------------------------------------ -The state in the middle of the set of revisions is then checked out. -You would now compile that kernel and boot it. If the booted kernel -works correctly, you would then issue the following command: +If that version is broken, type ------------------------------------------------ -$ git bisect good # this one is good +$ git bisect bad ------------------------------------------------ -The output of this command would be something similar to the following: +Then `git bisect` will respond with something like ------------------------------------------------ -Bisecting: 337 revisions left to test after this +Bisecting: 337 revisions left to test after this (roughly 9 steps) ------------------------------------------------ -You keep repeating this process, compiling the tree, testing it, and -depending on whether it is good or bad issuing the command "git bisect good" -or "git bisect bad" to ask for the next bisection. +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. -Eventually there will be no more revisions left to bisect, and you -will have been left with the first bad kernel revision in "refs/bisect/bad". Bisect reset ~~~~~~~~~~~~ After a bisect session, to clean up the bisection state and return to -the original HEAD (i.e., to quit bisecting), issue the following command: +the original HEAD, issue the following command: ------------------------------------------------ $ git bisect reset @@ -100,28 +115,101 @@ instead: $ git bisect reset <commit> ------------------------------------------------ -For example, `git bisect reset HEAD` will leave you on the current -bisection commit and avoid switching commits at all, while `git bisect -reset bisect/bad` will check out the first bad revision. +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 -~~~~~~~~~~~~~~~~ +Bisect visualize/view +~~~~~~~~~~~~~~~~~~~~~ To see the currently remaining suspects in 'gitk', issue the following -command during the bisection process: +command during the bisection process (the subcommand `view` can be used +as an alternative to `visualize`): ------------ $ git bisect visualize ------------ -`view` may also be used as a synonym for `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 +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 view --stat +$ git bisect visualize --stat ------------ Bisect log and bisect replay @@ -147,17 +235,17 @@ $ git bisect replay that-file Avoiding testing a commit ~~~~~~~~~~~~~~~~~~~~~~~~~ -If, in the middle of a bisect session, you know that the next suggested -revision is not a good one to test (e.g. the change the commit -introduces is known not to work in your environment and you know it -does not have anything to do with the bug you are chasing), you may -want to find a nearby commit and try that instead. +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 +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 @@ -167,20 +255,21 @@ 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 by yourself a nearby commit, you can ask Git -to do it for you by issuing the command: +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 ------------ -But Git may eventually be unable to tell the first bad commit among -a bad commit and one or more skipped commits. +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 even skip a range of commits, instead of just one commit, -using the "'<commit1>'..'<commit2>'" notation. For example: +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 @@ -196,8 +285,8 @@ would issue the command: $ git bisect skip v2.5 v2.5..v2.6 ------------ -This tells the bisect process that the commits between `v2.5` included -and `v2.6` included should be skipped. +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 @@ -231,23 +320,23 @@ 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, and exit with a -code between 1 and 127 (inclusive), except 125, if the current -source code is bad. +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". +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 +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). +`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 @@ -260,7 +349,7 @@ 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 +with the status of the real test to let the `git bisect run` command loop determine the eventual outcome of the bisect session. OPTIONS @@ -268,7 +357,7 @@ 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 +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 @@ -307,12 +396,12 @@ $ 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" +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. +`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 +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. @@ -324,7 +413,7 @@ $ cat ~/test.sh # tweak the working tree by merging the hot-fix branch # and then attempt a build -if git merge --no-commit hot-fix && +if git merge --no-commit --no-ff hot-fix && make then # run project specific test and report its status @@ -379,6 +468,26 @@ In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit 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 -------- diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index f2c85cc633..7e81541996 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -10,7 +10,9 @@ 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>] - [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>] [--] <file> + [--ignore-rev <rev>] [--ignore-revs-file <file>] + [--progress] [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>..<rev>] + [--] <file> DESCRIPTION ----------- @@ -35,7 +37,8 @@ Apart from supporting file annotation, Git also supports searching the development history for when a code snippet occurred in a change. This makes it possible to track when a code snippet was added to a file, moved or copied between files, and eventually deleted or replaced. It works by searching for -a text string in the diff. A small example: +a text string in the diff. A small example of the pickaxe interface +that searches for `blame_usage`: ----------------------------------------------------------------------------- $ git log --pretty=oneline -S'blame_usage' @@ -75,6 +78,8 @@ include::blame-options.txt[] -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 @@ -103,7 +108,7 @@ 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 timezone ("author-tz"); similarly + ("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"). diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 311b33674e..03c0824d52 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -8,14 +8,19 @@ git-branch - List, create, or delete branches SYNOPSIS -------- [verse] -'git branch' [--color[=<when>] | --no-color] [-r | -a] - [--list] [-v [--abbrev=<length> | --no-abbrev]] - [--column[=<options>] | --no-column] - [(--merged | --no-merged | --contains) [<commit>]] [<pattern>...] -'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>] +'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>] @@ -23,35 +28,46 @@ DESCRIPTION ----------- If `--list` is given, or if there are no non-option arguments, existing -branches are listed; the current branch will be highlighted with an -asterisk. Option `-r` causes the remote-tracking branches to be listed, -and option `-a` shows both local and remote branches. If a `<pattern>` +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 is interpreted +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). 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). +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. +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 checkout <newbranch>" to switch to 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 +`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`. @@ -61,6 +77,10 @@ If <oldbranch> had a corresponding reflog, it is renamed to match 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. @@ -78,30 +98,43 @@ OPTIONS --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`. + `--track` or `--set-upstream-to`. -D:: - Delete a branch irrespective of its merged status. + Shortcut for `--delete --force`. --l:: --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. + 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> if <branchname> exists - already. Without `-f` 'git branch' refuses to change an existing branch. + 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:: - Move/rename a branch even if the new branch name already exists. + 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 @@ -113,6 +146,10 @@ OPTIONS 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 @@ -124,14 +161,22 @@ 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:: - Activate the list mode. `git branch <pattern>` would try to create a branch, - use `git branch --list <pattern>` to list matching branches. + 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:: @@ -139,8 +184,10 @@ This option is only applicable in non-verbose mode. 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 name of the upstream branch, as well (see also `git remote - show <remote>`). + 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:: @@ -166,20 +213,18 @@ This option is only applicable in non-verbose mode. 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 checkout` and `git branch` to always behave as if '--no-track' +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. + branch.autoSetupMerge configuration variable is true. --set-upstream:: - If specified branch does not exist yet or if `--force` has been - given, acts exactly like `--track`. Otherwise sets up configuration - like `--track` would when creating the branch, except that where - branch points to is not changed. + 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>:: @@ -193,19 +238,27 @@ start-point is either a local or remote-tracking 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. `request-pull`). + 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`. + 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`. + specified commit (HEAD if not specified). Implies `--list`, + incompatible with `--merged`. <branchname>:: The name of the branch to create or delete. @@ -225,8 +278,33 @@ start-point is either a local or remote-tracking branch. The new name for an existing branch. The same restrictions as for <branchname> apply. - -Examples +--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:: @@ -235,11 +313,11 @@ 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 checkout my2.6.14 +$ 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". + "checkout -b my2.6.14 v2.6.14". Delete an unneeded branch:: + @@ -251,26 +329,41 @@ $ 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]. + '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. + 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 +NOTES ----- -If you are creating a branch that you want to checkout immediately, it is -easier to use the git checkout command with its `-b` option to create -a branch and check it out with a single command. +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`, `--merged` and `--no-merged` serve three related -but different purposes: +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. diff --git a/Documentation/git-bugreport.txt b/Documentation/git-bugreport.txt new file mode 100644 index 0000000000..66e88c2e31 --- /dev/null +++ b/Documentation/git-bugreport.txt @@ -0,0 +1,54 @@ +git-bugreport(1) +================ + +NAME +---- +git-bugreport - Collect information for user to file a bug report + +SYNOPSIS +-------- +[verse] +'git bugreport' [(-o | --output-directory) <path>] [(-s | --suffix) <format>] + +DESCRIPTION +----------- +Captures information about the user's machine, Git client, and repository state, +as well as a form requesting information about the behavior the user observed, +into a single text file which the user can then share, for example to the Git +mailing list, in order to report an observed bug. + +The following information is requested from the user: + + - Reproduction steps + - Expected behavior + - Actual behavior + +The following information is captured automatically: + + - 'git version --build-options' + - uname sysname, release, version, and machine strings + - Compiler-specific info string + - A list of enabled hooks + - $SHELL + +This tool is invoked via the typical Git setup process, which means that in some +cases, it might not be able to launch - for example, if a relevant config file +is unreadable. In this kind of scenario, it may be helpful to manually gather +the kind of information listed above when manually asking for help. + +OPTIONS +------- +-o <path>:: +--output-directory <path>:: + Place the resulting bug report file in `<path>` instead of the root of + the Git repository. + +-s <format>:: +--suffix <format>:: + Specify an alternate suffix for the bugreport name, to create a file + named 'git-bugreport-<formatted suffix>'. This should take the form of a + strftime(3) format string; the current local time will be used. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt index 0417562eb7..d34b0964be 100644 --- a/Documentation/git-bundle.txt +++ b/Documentation/git-bundle.txt @@ -9,8 +9,8 @@ git-bundle - Move objects and refs by archive SYNOPSIS -------- [verse] -'git bundle' create <file> <git-rev-list-args> -'git bundle' verify <file> +'git bundle' create [-q | --quiet | --progress | --all-progress] [--all-progress-implied] <file> <git-rev-list-args> +'git bundle' verify [-q | --quiet] <file> 'git bundle' list-heads <file> [<refname>...] 'git bundle' unbundle <file> [<refname>...] @@ -20,11 +20,14 @@ 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, rsync, 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 +ssh, http) cannot be used. + +The 'git bundle' command packages objects and references in an archive +at the originating machine, which can then be imported into another +repository using 'git fetch', 'git pull', or 'git clone', +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 @@ -33,9 +36,11 @@ destination repository. OPTIONS ------- -create <file>:: +create [options] <file> <git-rev-list-args>:: Used to create a bundle named 'file'. This requires the - 'git-rev-list-args' arguments to define the bundle contents. + '<git-rev-list-args>' arguments to define the bundle contents. + 'options' contains the options specific to the 'git bundle create' + subcommand. verify <file>:: Used to check that a bundle file is valid and will apply @@ -75,6 +80,33 @@ unbundle <file>:: necessarily everything in the pack (in this case, 'git bundle' acts like 'git fetch-pack'). +--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:: +--quiet:: + This flag makes the command not to report its progress + on the standard error stream. + SPECIFYING REFERENCES --------------------- @@ -92,8 +124,16 @@ It is okay to err on the side of caution, causing the bundle file to contain objects already in the destination, as these are ignored when unpacking at the destination. -EXAMPLE -------- +`git clone` can use any bundle created without negative refspecs +(e.g., `new`, but not `old..new`). +If you want to match `git clone --mirror`, which would include your +refs such as `refs/remotes/*`, use `--all`. +If you want to provide the same set of refs that a clone directly +from the source repository would get, use `--branches --tags` for +the `<git-rev-list-args>`. + +EXAMPLES +-------- Assume you want to transfer the history from a repository R1 on machine A to another repository R2 on machine B. diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index 322f5ed315..8e192d87db 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -9,18 +9,22 @@ git-cat-file - Provide content or type and size information for repository objec SYNOPSIS -------- [verse] -'git cat-file' (-t | -s | -e | -p | <type> | --textconv ) <object> -'git cat-file' (--batch | --batch-check) < <list-of-objects> +'git cat-file' (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e | -p | <type> | --textconv | --filters ) [--path=<path>] <object> +'git cat-file' (--batch[=<format>] | --batch-check[=<format>]) [ --textconv | --filters ] [--follow-symlinks] DESCRIPTION ----------- In its first form, the command provides the content or the type of an object in -the repository. The type is required unless '-t' or '-p' is used to find the -object type, or '-s' is used to find the object size, or '--textconv' is used -(which implies type "blob"). +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. +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 ------- @@ -38,8 +42,9 @@ OPTIONS <object>. -e:: - Suppress all output; instead exit with zero status if <object> - exists and is a valid object. + 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. @@ -54,30 +59,129 @@ OPTIONS --textconv:: Show the content as transformed by a textconv filter. In this case, - <object> has be of the form <tree-ish>:<path>, or :<path> in order - to apply the filter to the content recorded in the index at <path>. + <object> has to be of the form <tree-ish>:<path>, or :<path> in + order to apply the filter to the content recorded in the index at + <path>. + +--filters:: + Show the content as converted by the filters configured in + the current working tree for the given <path> (i.e. smudge filters, + end-of-line conversion, etc). In this case, <object> has to be of + the form <tree-ish>:<path>, or :<path>. + +--path=<path>:: + For use with --textconv or --filters, to allow specifying an object + name and a path separately, e.g. when it is difficult to figure out + the revision from which the blob came. --batch:: --batch=<format>:: Print object information and contents for each object provided - on stdin. May not be combined with any other options or arguments. - See the section `BATCH OUTPUT` below for details. + on stdin. May not be combined with any other options or arguments + except `--textconv` or `--filters`, in which case the input lines + also need to specify the path, separated by 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. See the + not be combined with any other options or arguments except + `--textconv` or `--filters`, in which case the input lines also + need to specify the path, separated by 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 `-t` is specified, one of the <type>. -If '-s' is specified, the size of the <object> in bytes. +If `-s` is specified, the size of the <object> in bytes. -If '-e' is specified, no output. +If `-e` is specified, no output, unless the <object> is malformed. -If '-p' is specified, the contents of <object> are pretty-printed. +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. @@ -99,7 +203,7 @@ newline. The available atoms are: The 40-hex object name of the object. `objecttype`:: - The type of of the object (the same as `cat-file -t` reports). + 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` @@ -109,6 +213,11 @@ newline. The available atoms are: The size, in bytes, that the object takes up on disk. See the note about on-disk sizes in the `CAVEATS` section below. +`deltabase`:: + If the object is stored as a delta on-disk, this expands to the + 40-hex sha1 of the delta base object. Otherwise, expands to the + null sha1 (40 zeroes). See `CAVEATS` below. + `rest`:: If this atom is used in the output string, input lines are split at the first whitespace boundary. All characters before that @@ -143,6 +252,53 @@ 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 ------- @@ -152,10 +308,11 @@ should be taken in drawing conclusions about which refs or objects are responsible for disk usage. The size of a packed non-delta object may be much larger than the size of objects which delta against it, but the choice of which object is the base and which is the delta is arbitrary -and is subject to change during a repack. Note also that multiple copies -of an object may be present in the object database; in this case, it is -undefined which copy's size will be reported. +and is subject to change during a repack. +Note also that multiple copies of an object may be present in the object +database; in this case, it is undefined which copy's size or delta base +will be reported. GIT --- diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt index 00e2aa2df2..84f41a8e82 100644 --- a/Documentation/git-check-attr.txt +++ b/Documentation/git-check-attr.txt @@ -9,8 +9,8 @@ git-check-attr - Display gitattributes information SYNOPSIS -------- [verse] -'git check-attr' [-a | --all | attr...] [--] pathname... -'git check-attr' --stdin [-z] [-a | --all | attr...] < <list-of-paths> +'git check-attr' [-a | --all | <attr>...] [--] <pathname>... +'git check-attr' --stdin [-z] [-a | --all | <attr>...] DESCRIPTION ----------- @@ -28,10 +28,11 @@ OPTIONS Consider `.gitattributes` in the index only, ignoring the working tree. --stdin:: - Read file names from stdin instead of from the command-line. + 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. + The output format is modified to be machine-parsable. If `--stdin` is also given, input paths are separated with a NUL character instead of a linefeed character. diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt index ee2e091704..0c3924a63d 100644 --- a/Documentation/git-check-ignore.txt +++ b/Documentation/git-check-ignore.txt @@ -9,17 +9,19 @@ git-check-ignore - Debug gitignore / exclude files SYNOPSIS -------- [verse] -'git check-ignore' [options] pathname... -'git check-ignore' [options] --stdin < <list-of-paths> +'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`, show the pattern from .gitignore (or other input files to -the exclude mechanism) that decides if the pathname is excluded or -included. Later patterns within a file take precedence over earlier -ones. +`--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 ------- @@ -28,14 +30,22 @@ OPTIONS valid with a single pathname. -v, --verbose:: - Also output details about the matching pattern (if any) - for each given pathname. + Instead of printing the paths that are excluded, for each path + that matches an exclude pattern, print the exclude pattern + together with the path. (Matching an exclude pattern usually + means the path is excluded, but if the pattern begins with '!' + then it is a negated pattern and matching it means the path is + NOT excluded.) ++ +For precedence rules within and between exclude sources, see +linkgit:gitignore[5]. --stdin:: - Read file names from stdin instead of from the command-line. + 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 + The output format is modified to be machine-parsable (see below). If `--stdin` is also given, input paths are separated with a NUL character instead of a linefeed character. @@ -69,7 +79,7 @@ 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 +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 @@ -108,7 +118,7 @@ EXIT STATUS SEE ALSO -------- linkgit:gitignore[5] -linkgit:gitconfig[5] +linkgit:git-config[1] linkgit:git-ls-files[1] GIT diff --git a/Documentation/git-check-mailmap.txt b/Documentation/git-check-mailmap.txt index 39028ee1a3..aa2055dbeb 100644 --- a/Documentation/git-check-mailmap.txt +++ b/Documentation/git-check-mailmap.txt @@ -9,7 +9,7 @@ git-check-mailmap - Show canonical names and email addresses of contacts SYNOPSIS -------- [verse] -'git check-mailmap' [options] <contact>... +'git check-mailmap' [<options>] <contact>... DESCRIPTION diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index fc02959ba4..ee6a4144fb 100644 --- a/Documentation/git-check-ref-format.txt +++ b/Documentation/git-check-ref-format.txt @@ -60,7 +60,7 @@ Git imposes the following rules on how references are named: 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 avoids ambiguities in certain +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 @@ -77,11 +77,24 @@ reference name expressions (see linkgit:gitrevisions[7]): . at-open-brace `@{` is used as a notation to access a reflog entry. -With the `--branch` option, it expands the ``previous branch syntax'' -`@{-n}`. For example, `@{-1}` is a way to refer the last branch you -were on. 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. +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 ------- @@ -94,22 +107,22 @@ OPTIONS 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 place of a one full pathname component (e.g., - `foo/*/bar` but not `foo/bar*`). + 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. Iff the normalized + 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. (`--print` is a deprecated way to spell - `--normalize`.) + 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 branch: +* Print the name of the previous thing checked out: + ------------ $ git check-ref-format --branch @{-1} @@ -118,8 +131,8 @@ $ git check-ref-format --branch @{-1} * Determine the reference name to use for a new branch: + ------------ -$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch") || -die "we do not like '$newbranch' as a branch name." +$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch")|| +{ echo "we do not like '$newbranch' as a branch name." >&2 ; exit 1 ; } ------------ GIT diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 91294f89c8..5b697eee1b 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -3,7 +3,7 @@ git-checkout(1) NAME ---- -git-checkout - Checkout a branch or paths to the working tree +git-checkout - Switch branches or restore working tree files SYNOPSIS -------- @@ -12,33 +12,34 @@ SYNOPSIS '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' [-p|--patch] [<tree-ish>] [--] [<paths>...] +'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>... +'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul] +'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...] 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 +or the specified tree. If no pathspec was 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 +'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 + `HEAD` at the branch. Local modifications to the files in the working tree are kept, so that they can be committed to the - <branch>. + `<branch>`. + -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 +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 a +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. @@ -51,7 +52,7 @@ if exists, for the current branch. `--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 +If `-B` is given, `<new_branch>` is created if it doesn't exist; otherwise, it is reset. This is the transactional equivalent of + ------------ @@ -65,29 +66,27 @@ successful. 'git checkout' --detach [<branch>]:: 'git checkout' [--detach] <commit>:: - Prepare to work on top of <commit>, by detaching HEAD at it + 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). +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. +Omitting `<branch>` detaches `HEAD` at the tip of the current branch. -'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...:: +'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...:: +'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]:: - When <paths> or `--patch` are given, 'git checkout' does *not* - switch branches. It updates the named paths in the working tree - from the index file or from a named <tree-ish> (most often a - commit). In this case, the `-b` and `--track` options are - meaningless and giving either of them results in an error. The - <tree-ish> argument can be used to specify a specific tree-ish - (i.e. commit, tag or tree) to update the index for the given - paths before updating the working tree. + Overwrite the contents of the files that match the pathspec. + When the `<tree-ish>` (most often a commit) is not given, + overwrite working tree with the contents in the index. + When the `<tree-ish>` is given, overwrite both the index and + the working tree with the contents at the `<tree-ish>`. + 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 @@ -97,16 +96,29 @@ 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 previous mode, 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 + 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 @@ -116,14 +128,29 @@ entries; instead, unmerged entries are ignored. --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. + 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 + 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. @@ -132,19 +159,40 @@ entries; instead, unmerged entries are ignored. 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 +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 +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. +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. + `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 @@ -153,21 +201,21 @@ explicitly give a name with '-b' in such a case. --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 + 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 + 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. +`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 @@ -176,17 +224,17 @@ 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 +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. +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>. + 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:: @@ -206,37 +254,85 @@ 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 + 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.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-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). + 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 active + 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, submodules working trees 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. + +--pathspec-from-file=<file>:: + Pathspec is passed in `<file>` instead of commandline args. If + `<file>` is exactly `-` then standard input is used. Pathspec + elements are separated by LF or CR/LF. Pathspec elements can be + quoted as explained for the configuration variable `core.quotePath` + (see linkgit:git-config[1]). See also `--pathspec-file-nul` and + global `--literal-pathspecs`. + +--pathspec-file-nul:: + Only meaningful with `--pathspec-from-file`. Pathspec elements are + separated with NUL character and all other characters are taken + literally (including newlines and quotes). <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 + commit, your `HEAD` becomes "detached" and you are no longer on any branch (see below for details). + -As a special case, the `"@{-N}"` syntax for the N-th last branch -checks out the branch (instead of detaching). You may also specify -`-` which is synonymous with `"@{-1}"`. +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 further special case, you may use `"A...B"` as a shortcut for the +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`. @@ -245,24 +341,34 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`. <start_point>:: The name of a commit at which to start the new branch; see - linkgit:git-branch[1] for details. Defaults to HEAD. + 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. +\--:: + Do not interpret any more arguments as options. +<pathspec>...:: + Limits the paths affected by the operation. ++ +For more details, see the 'pathspec' entry in linkgit:gitglossary[7]. DETACHED HEAD ------------- -HEAD normally refers to a named branch (e.g. 'master'). Meanwhile, each +`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: +commits, one of them tagged, and with branch `master` checked out: ------------ - HEAD (refers to branch 'master') - | - v + HEAD (refers to branch 'master') + | + v a---b---c branch 'master' (refers to commit 'c') ^ | @@ -270,17 +376,17 @@ a---b---c branch 'master' (refers to commit 'c') ------------ 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': +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 + HEAD (refers to branch 'master') + | + v a---b---c---d branch 'master' (refers to commit 'd') ^ | @@ -290,7 +396,7 @@ a---b---c---d branch 'master' (refers to commit 'd') 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): +checkout commit `b` (here we show two ways this may be done): ------------ $ git checkout v2.0 # or @@ -305,9 +411,9 @@ 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 +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: ------------ @@ -324,7 +430,7 @@ 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 +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: ------------ @@ -342,12 +448,12 @@ a---b---c---d branch 'master' (refers to commit 'd') ------------ In fact, we can perform all the normal Git operations. But, let's look -at what happens when we then checkout master: +at what happens when we then checkout `master`: ------------ $ git checkout master - HEAD (refers to branch 'master') + HEAD (refers to branch 'master') e---f | / v a---b---c---d branch 'master' (refers to commit 'd') @@ -357,9 +463,9 @@ a---b---c---d branch 'master' (refers to commit 'd') ------------ 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 +`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', +before that happens. If we have not yet moved away from commit `f`, any of these will create a reference to it: ------------ @@ -368,19 +474,19 @@ $ 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. +<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. +<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. +<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 +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 +it. For example, to see the last two commits to which `HEAD` referred, we can use either of these commands: ------------ @@ -388,12 +494,24 @@ $ 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. + the `Makefile` to two revisions back, deletes `hello.c` by + mistake, and gets it back from the index. + ------------ $ git checkout master <1> @@ -404,7 +522,7 @@ $ git checkout hello.c <3> + <1> switch branch <2> take a file out of another commit -<3> restore hello.c from the index +<3> restore `hello.c` from the index + If you want to check out _all_ C source files out of the index, you can say @@ -427,13 +545,13 @@ $ git checkout -- hello.c ------------ . After working in the wrong branch, switching to the correct -branch would be done using: + branch would be done using: + ------------ $ git checkout mytopic ------------ + -However, your "wrong" branch and correct "mytopic" branch may +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: + @@ -455,7 +573,7 @@ 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: + the `-m` option, you would see something like this: + ------------ $ git checkout -m mytopic @@ -474,6 +592,11 @@ $ 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/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index c205d2363e..75feeef08a 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -8,10 +8,9 @@ git-cherry-pick - Apply the changes introduced by some existing commits SYNOPSIS -------- [verse] -'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>... -'git cherry-pick' --continue -'git cherry-pick' --quit -'git cherry-pick' --abort +'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] + [-S[<keyid>]] <commit>... +'git cherry-pick' (--continue | --skip | --abort | --quit) DESCRIPTION ----------- @@ -46,7 +45,7 @@ OPTIONS 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 + 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'). @@ -56,6 +55,13 @@ OPTIONS 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 @@ -99,6 +105,16 @@ 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>]:: +--no-gpg-sign:: + 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` is useful to + countermand both `commit.gpgSign` configuration variable, and + earlier `--gpg-sign`. --ff:: If the current HEAD is the same as the parent of the @@ -120,13 +136,14 @@ effect to your index in a row. --allow-empty-message:: By default, cherry-picking a commit with an empty message will fail. - This option overrides that behaviour, allowing commits with empty + 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 are ignored. This option overrides that behavior and + 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>:: @@ -139,6 +156,11 @@ effect to your index in a row. 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[] @@ -204,16 +226,16 @@ $ 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. + 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. + 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. + spending extra time to avoid mistakes based on incorrectly + matching context lines. SEE ALSO -------- diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt index 2d0daae626..0ea921a593 100644 --- a/Documentation/git-cherry.txt +++ b/Documentation/git-cherry.txt @@ -3,7 +3,7 @@ git-cherry(1) NAME ---- -git-cherry - Find commits not merged upstream +git-cherry - Find commits yet to be applied to upstream SYNOPSIS -------- @@ -12,46 +12,26 @@ SYNOPSIS DESCRIPTION ----------- -The changeset (or "diff") of each commit between the fork-point and <head> -is compared against each commit between the fork-point and <upstream>. -The diffs are compared after removing any whitespace and line numbers. +Determine whether there are commits in `<head>..<upstream>` that are +equivalent to those in the range `<limit>..<head>`. -Every commit that doesn't exist in the <upstream> branch -has its id (sha1) reported, prefixed by a symbol. The ones that have -equivalent change already -in the <upstream> branch are prefixed with a minus (-) sign, and those -that only exist in the <head> branch are prefixed with a plus (+) symbol: - - __*__*__*__*__> <upstream> - / - fork-point - \__+__+__-__+__+__-__+__> <head> - - -If a <limit> has been given then the commits along the <head> branch up -to and including <limit> are not reported: - - __*__*__*__*__> <upstream> - / - fork-point - \__*__*__<limit>__-__+__> <head> - - -Because 'git cherry' compares the changeset rather than the commit id -(sha1), you can use 'git cherry' to find out if a commit you made locally -has been applied <upstream> under a different commit id. For example, -this will happen if you're feeding patches <upstream> via email rather -than pushing or pulling commits directly. +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:: - Verbose. + Show the commit subjects next to the SHA1s. <upstream>:: - Upstream branch to compare against. - Defaults to the first tracked remote branch, if available. + Upstream branch to search for equivalent commits. + Defaults to the upstream branch of HEAD. <head>:: Working branch; defaults to HEAD. @@ -59,6 +39,103 @@ OPTIONS <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] diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt index 89979228b1..a7f309dff5 100644 --- a/Documentation/git-clean.txt +++ b/Documentation/git-clean.txt @@ -16,7 +16,7 @@ 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' +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. @@ -26,16 +26,20 @@ 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. + Normally, when no <path> is specified, git clean will not + recurse into untracked directories to avoid removing too much. + Specify -d to have it recurse into such directories as well. + If any paths are specified, -d is irrelevant; all untracked + files matching the specified paths (with exceptions for nested + git directories mentioned under `--force`) will be removed. -f:: --force:: If the Git configuration variable clean.requireForce is not set - to false, 'git clean' will refuse to run unless given -f, -n or - -i. + to false, 'git clean' will refuse to delete files or directories + unless given -f or -i. Git will refuse to modify untracked + nested git repositories (directories with a .git subdirectory) + unless a second -f is given. -i:: --interactive:: @@ -53,16 +57,15 @@ OPTIONS -e <pattern>:: --exclude=<pattern>:: - In addition to those found in .gitignore (per directory) and - $GIT_DIR/info/exclude, also consider these patterns to be in the - set of the ignore rules in effect. + Use the given exclude pattern in addition to the standard ignore rules + (see linkgit:gitignore[5]). -x:: - Don't use the standard ignore rules read from .gitignore (per - directory) and $GIT_DIR/info/exclude, but do still use the ignore - rules given with `-e` options. This allows removing all untracked + 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 reset') to create a pristine + conjunction with 'git restore' or 'git reset') to create a pristine working directory to test a clean build. -X:: @@ -98,7 +101,7 @@ clean:: filter by pattern:: This shows the files and directories to be deleted and issues an - "Input ignore patterns>>" prompt. You can input space-seperated + "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 diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 450f158779..c898310099 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -12,9 +12,11 @@ SYNOPSIS 'git clone' [--template=<template_directory>] [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] - [--separate-git-dir <git dir>] - [--depth <depth>] [--[no-]single-branch] - [--recursive | --recurse-submodules] [--] <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>] [--sparse] + [--filter=<filter>] [--] <repository> [<directory>] DESCRIPTION @@ -22,7 +24,7 @@ DESCRIPTION Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository -(visible using `git branch -r`), and creates and checks out an +(visible using `git branch --remotes`), and creates and checks out an initial branch that is forked from the cloned repository's currently active branch. @@ -40,8 +42,8 @@ configuration variables. OPTIONS ------- ---local:: -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 @@ -55,18 +57,15 @@ repository is specified as a URL, then this flag is ignored (and we never use the local optimizations). Specifying `--no-local` will override the default when `/path/to/repo` is given, using the regular Git transport instead. -+ -To force copying instead of hardlinking (which may be desirable if you -are trying to make a back-up of your repository), but still avoid the -usual "Git aware" transport mechanism, `--no-hardlinks` can be used. --no-hardlinks:: - Optimize the cloning process from a repository on a - local filesystem by copying files under `.git/objects` - directory. + Force the cloning process from a repository on a local + filesystem to copy the files under the `.git/objects` + directory instead of using hardlinks. This may be desirable + if you are trying to make a back-up of your repository. ---shared:: -s:: +--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 @@ -83,52 +82,74 @@ 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 `-l` option in a repository -cloned with `-s` will copy objects from the source repository into a pack -in the cloned repository, removing the disk space savings of `clone -s`. -It is safe, however, to run `git gc`, which uses the `-l` option by +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 `-s` on +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 <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. +*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. ---quiet:: -q:: +--quiet:: Operate quietly. Progress is not reported to the standard - error stream. This flag is also passed to the `rsync' - command when given. + error stream. ---verbose:: -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 -q + 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. ---no-checkout:: +--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 `-n` + 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 @@ -136,6 +157,22 @@ objects from the source repository into a pack in the cloned repository. used, neither remote-tracking branches nor the related configuration variables are created. +--sparse:: + Initialize the sparse-checkout file so the working + directory starts with only the files in the root + of the repository. The sparse-checkout file can be + modified to grow the working directory as needed. + +--filter=<filter-spec>:: + Use the partial clone feature and request that the server sends + a subset of reachable objects according to a given object filter. + When using `--filter`, the supplied `<filter-spec>` is used for + the partial clone filter. For example, `--filter=blob:none` will + filter out all blobs (file contents) until needed by Git. Also, + `--filter=blob:limit=<size>` will filter out all blobs of size + at least `<size>`. For more details on filter specifications, see + the `--filter` option in linkgit:git-rev-list[1]. + --mirror:: Set up a mirror of the source repository. This implies `--bare`. Compared to `--bare`, `--mirror` not only maps local branches of the @@ -144,13 +181,13 @@ objects from the source repository into a pack in the cloned repository. that all these refs are overwritten by a `git remote update` in the target repository. ---origin <name>:: -o <name>:: +--origin <name>:: Instead of using the remote name `origin` to keep track of the upstream repository, use `<name>`. ---branch <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 @@ -158,8 +195,8 @@ objects from the source repository into a pack in the cloned repository. `--branch` can also take tags and detaches the HEAD at that commit in the resulting repository. ---upload-pack <upload-pack>:: -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. @@ -168,8 +205,8 @@ objects from the source repository into a pack in the cloned repository. Specify the directory from which templates will be used; (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) ---config <key>=<value>:: -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 @@ -178,49 +215,90 @@ objects from the source repository into a pack in the cloned repository. 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 revisions. A shallow repository has a - number of limitations (you cannot clone or fetch from - it, nor push from nor into it), but is adequate if you - are only interested in the recent history of a large project - with a long history, and would want to send in fixes - as patches. + specified number of 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. When creating a shallow - clone with the `--depth` option, this is the default, unless - `--no-single-branch` is given to fetch the histories near the - tips of all branches. + 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. ---recursive:: ---recurse-submodules:: - After the clone is created, initialize all submodules within, - using their default settings. This is equivalent to running - `git submodule update --init --recursive` 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-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 filesytem-agnostic Git symbolic link to there. + then make a filesystem-agnostic Git symbolic link to there. The result is Git repository can be separated from working tree. +-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,URLS>> section below for more information on specifying + <<URLS,GIT URLS>> section below for more information on specifying repositories. <directory>:: @@ -233,7 +311,7 @@ objects from the source repository into a pack in the cloned repository. :git-clone: 1 include::urls.txt[] -Examples +EXAMPLES -------- * Clone from upstream: diff --git a/Documentation/git-column.txt b/Documentation/git-column.txt index 5d6f1cc464..f58e9c43e6 100644 --- a/Documentation/git-column.txt +++ b/Documentation/git-column.txt @@ -13,7 +13,10 @@ SYNOPSIS DESCRIPTION ----------- -This command formats its input into multiple columns. +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 ------- @@ -23,7 +26,7 @@ OPTIONS --mode=<mode>:: Specify layout mode. See configuration variable column.ui for option - syntax. + syntax in linkgit:git-config[1]. --raw-mode=<n>:: Same as --mode but take mode encoded as a number. This is mainly used @@ -43,10 +46,33 @@ OPTIONS --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 +------------ -Author ------- -Written by Nguyen Thai Ngoc Duy <pclouds@gmail.com> +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 --- diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-commit-graph.txt new file mode 100644 index 0000000000..17405c73a9 --- /dev/null +++ b/Documentation/git-commit-graph.txt @@ -0,0 +1,139 @@ +git-commit-graph(1) +=================== + +NAME +---- +git-commit-graph - Write and verify Git commit-graph files + + +SYNOPSIS +-------- +[verse] +'git commit-graph verify' [--object-dir <dir>] [--shallow] [--[no-]progress] +'git commit-graph write' <options> [--object-dir <dir>] [--[no-]progress] + + +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`. If the directory + could not be made into an absolute path, or does not match any known + object directory, `git commit-graph ...` will exit with non-zero + status. + +--[no-]progress:: + Turn progress on/off explicitly. If neither is specified, progress is + shown if standard error is connected to a terminal. + +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. OIDs that resolve to non-commits +(either directly, or by peeling tags) are silently ignored. OIDs that +are malformed, or do not exist generate an error. (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 `--changed-paths` option, compute and write information about the +paths changed between a commit and its first parent. This operation can +take a while on large repositories. It provides significant performance gains +for getting history of a directory or a file with `git log -- <path>`. If +this option is given, future commit-graph writes will automatically assume +that this option was intended. Use `--no-changed-paths` to stop storing this +data. ++ +With the `--split[=<strategy>]` option, write the commit-graph as a +chain of multiple commit-graph files stored in +`<dir>/info/commit-graphs`. Commit-graph layers are merged based on the +strategy and other splitting options. 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 `--split=no-merge` is specified, a merge is never performed, and +the remaining options are ignored. `--split=replace` overwrites the +existing chain with a new one. A bare `--split` defers to the remaining +options. (Note that merging a chain of commit graphs replaces the +existing chain with a length-1 chain where the first and only +incremental holds the entire graph). ++ +* 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`. + +'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 +------------------------------------------------ + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt index cafdc9642d..2e2c581098 100644 --- a/Documentation/git-commit-tree.txt +++ b/Documentation/git-commit-tree.txt @@ -9,7 +9,7 @@ git-commit-tree - Create a new commit object SYNOPSIS -------- [verse] -'git commit-tree' <tree> [(-p <parent>)...] < changelog +'git commit-tree' <tree> [(-p <parent>)...] 'git commit-tree' [(-p <parent>)...] [-S[<keyid>]] [(-m <message>)...] [(-F <file>)...] <tree> @@ -23,6 +23,10 @@ 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) @@ -41,10 +45,10 @@ state was. OPTIONS ------- <tree>:: - An existing tree object + An existing tree object. -p <parent>:: - Each '-p' indicates the id of a parent commit object. + 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 @@ -52,11 +56,16 @@ OPTIONS -F <file>:: Read the commit log message from the given file. Use `-` to read - from the standard input. + 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 commit. - +--gpg-sign[=<keyid>]:: +--no-gpg-sign:: + 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` is useful to + countermand a `--gpg-sign` option given earlier on the command line. Commit Information ------------------ @@ -67,26 +76,6 @@ A commit encapsulates: - 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. @@ -105,6 +94,7 @@ FILES SEE ALSO -------- linkgit:git-write-tree[1] +linkgit:git-commit[1] GIT --- diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 1a7616c73a..a3baea32ae 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -13,23 +13,29 @@ SYNOPSIS [-F <file> | -m <msg>] [--reset-author] [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=<author>] [--date=<date>] [--cleanup=<mode>] [--[no-]status] - [-i | -o] [-S[<keyid>]] [--] [<file>...] + [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]] + [-S[<keyid>]] [--] [<pathspec>...] DESCRIPTION ----------- -Stores the current contents of the index in a new commit along -with a log message from the user describing the changes. +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 added can be specified in several ways: +The content to be committed can be specified in several ways: -1. by using 'git add' to incrementally "add" changes to the - index before using the 'commit' command (Note: even modified - files must be "added"); +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 'git rm' to remove files from the working tree +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, in which +3. by listing files as arguments to the 'commit' command + (without --interactive or --patch switch), in which case the commit will ignore changes staged in the index, and instead record the current content of the listed files (which must already be known to Git); @@ -41,7 +47,8 @@ The content to be added can be specified in several ways: actual commit; 5. by using the --interactive or --patch switches with the 'commit' command - to decide one by one which files or hunks should be part of the commit, + to decide one by one which files or hunks should be part of the commit + in addition to contents in the index, before finalizing the operation. See the ``Interactive Mode'' section of linkgit:git-add[1] to learn how to operate these modes. @@ -75,7 +82,7 @@ OPTIONS -c <commit>:: --reedit-message=<commit>:: - Like '-C', but with '-c' the editor is invoked, so that + Like '-C', but with `-c` the editor is invoked, so that the user can further edit the commit message. --fixup=<commit>:: @@ -93,8 +100,8 @@ OPTIONS --reset-author:: When used with -C/-c/--amend options, or when committing after a - a conflicting cherry-pick, declare that the authorship of the - resulting commit now belongs of the committer. This also renews + conflicting cherry-pick, declare that the authorship of the + resulting commit now belongs to the committer. This also renews the author timestamp. --short:: @@ -110,14 +117,17 @@ OPTIONS `--dry-run`. --long:: - When doing a dry-run, give the output in a the long-format. + When doing a dry-run, give the output in the long-format. Implies `--dry-run`. -z:: --null:: - When showing `short` or `porcelain` status output, terminate - entries in the status output with NUL, instead of LF. If no - format is given, implies the `--porcelain` output format. + 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>:: @@ -139,6 +149,8 @@ OPTIONS 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>:: @@ -154,7 +166,11 @@ OPTIONS -s:: --signoff:: Add Signed-off-by line by the committer at the end of the commit - log message. + 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:: @@ -176,22 +192,29 @@ OPTIONS --cleanup=<mode>:: This option determines how the supplied commit message should be cleaned up before committing. The '<mode>' can be `strip`, - `whitespace`, `verbatim`, or `default`. + `whitespace`, `verbatim`, `scissors` or `default`. + -- strip:: - Strip leading and trailing empty lines, trailing whitespace, and - #commentary and collapse consecutive empty lines. + 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 +The default can be changed by the `commit.cleanup` configuration variable (see linkgit:git-config[1]). -e:: @@ -244,39 +267,64 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].) -o:: --only:: - Make a commit only from the paths specified on the + 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 so far. This is the default mode of operation of + 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 + 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. + already been staged. If used together with `--allow-empty` + paths are also not required, and an empty commit will be created. + +--pathspec-from-file=<file>:: + Pathspec is passed in `<file>` instead of commandline args. If + `<file>` is exactly `-` then standard input is used. Pathspec + elements are separated by LF or CR/LF. Pathspec elements can be + quoted as explained for the configuration variable `core.quotePath` + (see linkgit:git-config[1]). See also `--pathspec-file-nul` and + global `--literal-pathspecs`. + +--pathspec-file-nul:: + Only meaningful with `--pathspec-from-file`. Pathspec elements are + separated with NUL character and all other characters are taken + literally (including newlines and quotes). -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. Note that this diff output doesn't have its - lines prefixed with '#'. + 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:: @@ -300,20 +348,23 @@ configuration variable documented in linkgit:git-config[1]. -S[<keyid>]:: --gpg-sign[=<keyid>]:: - GPG-sign commit. +--no-gpg-sign:: + 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` is useful to + countermand both `commit.gpgSign` configuration variable, and + earlier `--gpg-sign`. \--:: 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[] +<pathspec>...:: + When pathspec is given on the command line, commit the contents of + the files that match the pathspec without recording the changes + already added to the index. The contents of these files are also + staged for the next commit on top of what have been staged before. ++ +For more details, see the 'pathspec' entry in linkgit:gitglossary[7]. EXAMPLES -------- @@ -321,7 +372,7 @@ 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 reset HEAD -- <file>`, +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, @@ -408,6 +459,43 @@ 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). +COMMIT INFORMATION +------------------ + +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) + +The author and committer names are by convention some form of a personal name +(that is, the name by which other humans refer to you), although Git does not +enforce or require any particular form. Arbitrary Unicode may be used, subject +to the constraints listed above. This name has no effect on authentication; for +that, see the `credential.username` variable in linkgit:git-config[1]. + +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). + +The `author.name` and `committer.name` and their corresponding email options +override `user.name` and `user.email` if set and are overridden themselves by +the environment variables. + +The typical usage is to set just the `user.name` and `user.email` variables; +the other options are provided for more complex use cases. + +:git-commit: 1 +include::date-formats.txt[] DISCUSSION ---------- @@ -425,14 +513,14 @@ 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 +`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`, -and `post-commit` hooks. See linkgit:githooks[5] for more +`post-commit` and `post-rewrite` hooks. See linkgit:githooks[5] for more information. FILES diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index e9917b89a9..7573160f21 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -9,18 +9,18 @@ git-config - Get and set repository or global options SYNOPSIS -------- [verse] -'git config' [<file-option>] [type] [-z|--null] name [value [value_regex]] -'git config' [<file-option>] [type] --add name value -'git config' [<file-option>] [type] --replace-all name value [value_regex] -'git config' [<file-option>] [type] [-z|--null] --get name [value_regex] -'git config' [<file-option>] [type] [-z|--null] --get-all name [value_regex] -'git config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex] -'git config' [<file-option>] [type] [-z|--null] --get-urlmatch name URL +'git config' [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-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] [--show-scope] [-z|--null] --get name [value_regex] +'git config' [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] --get-all name [value_regex] +'git config' [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-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>] [-z|--null] -l | --list +'git config' [<file-option>] [--show-origin] [--show-scope] [-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 @@ -31,40 +31,40 @@ 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. +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 specifier can be either '--int' or '--bool', to make -'git config' ensure that the variable(s) are of the given type and -convert the value to the canonical form (simple decimal number for int, -a "true" or "false" string for bool), or '--path', which does some -path expansion (see '--path' below). If no type specifier is passed, no -checks or transformations are performed on the value. +The `--type=<type>` option instructs 'git config' to ensure that incoming and +outgoing values are canonicalize-able under the given <type>. If no +`--type=<type>` is given, no canonicalization will be performed. Callers may +unset an existing `--type` specifier with `--no-type`. When reading, the values are read from the system, global and repository local configuration files by default, and options -'--system', '--global', '--local' and '--file <filename>' can be -used to tell the command to read from only that location (see <<FILES>>). +`--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', -'--file <filename>' can be used to tell the command to write to -that location (you can say '--local' but that is the default). +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 config file is invalid (ret=3), -. can not write to the config file (ret=4), -. no section or name was provided (ret=2), -. the section or key is invalid (ret=1), -. 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). +- 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. @@ -86,8 +86,7 @@ OPTIONS found and the last value if multiple key values were found. --get-all:: - Like get, but does not fail if the number of values for the key - is not exactly one. + 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 @@ -102,7 +101,7 @@ OPTIONS 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. + list them. Returns error code 1 if no value is found. --global:: For writing options: write to global `~/.gitconfig` file @@ -127,19 +126,24 @@ See also <<FILES>>. --local:: For writing options: write to the repository `.git/config` file. - This is the default behavior. + 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. + 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 @@ -159,27 +163,45 @@ See also <<FILES>>. -l:: --list:: - List all variables set in config file. + List all variables set in config file, along with their values. ---bool:: - 'git config' will ensure that the output is "true" or "false" +--type <type>:: + 'git config' will ensure that any input or output is valid under the given + type constraint(s), and will canonicalize outgoing values in `<type>`'s + canonical form. ++ +Valid `<type>`'s include: ++ +- 'bool': canonicalize values as either "true" or "false". +- 'int': canonicalize values as simple decimal numbers. An optional suffix of + 'k', 'm', or 'g' will cause the value to be multiplied by 1024, 1048576, or + 1073741824 upon input. +- 'bool-or-int': canonicalize according to either 'bool' or 'int', as described + above. +- 'path': canonicalize by adding a leading `~` to the value of `$HOME` and + `~user` to the home directory for the specified user. This specifier has no + effect when setting the value (but you can use `git config section.variable + ~/` from the command line to let your shell do the expansion.) +- 'expiry-date': canonicalize by converting from a fixed or relative date-string + to a timestamp. This specifier has no effect when setting the value. +- 'color': When getting a value, canonicalize by converting to an ANSI color + escape sequence. When setting a value, a sanity-check is performed to ensure + that the given value is canonicalize-able as an ANSI color, but it is written + as-is. ++ +--bool:: --int:: - 'git config' will ensure that the output is a simple - decimal number. An optional value suffix of 'k', 'm', or 'g' - in the config file will cause the value to be multiplied - by 1024, 1048576, or 1073741824 prior to output. - --bool-or-int:: - 'git config' will ensure that the output matches the format of - either --bool or --int, as described above. - --path:: - 'git-config' will expand leading '{tilde}' to the value of - '$HOME', and '{tilde}user' to the home directory for the - specified user. This option has no effect when setting the - value (but you can use 'git config bla {tilde}/' from the - command line to let your shell do the expansion). +--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:: @@ -190,6 +212,21 @@ See also <<FILES>>. 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). + +--show-scope:: + Similar to `--show-origin` in that it augments the output of + all queried config options with the scope of that value + (local, global, system, command). + --get-colorbool name [stdout-is-tty]:: Find the color setting for `name` (e.g. `color.diff`) and output @@ -207,21 +244,37 @@ See also <<FILES>>. output it as the ANSI color escape sequence to the standard output. The optional `default` parameter is used instead, if there is no color configured for `name`. ++ +`--type=color [--default=<default>]` is preferred over `--get-color` +(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). + `--system`, `--global`, or repository (default). --[no-]includes:: Respect `include.*` directives in config files when looking up - values. Defaults to on. + 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 +If not set explicitly with `--file`, there are four files where 'git config' will search for configuration options: $(prefix)/etc/gitconfig:: @@ -242,6 +295,10 @@ $XDG_CONFIG_HOME/git/config:: $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 @@ -252,14 +309,18 @@ 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*. +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' and the '--system' options will limit the file used -to the global or system-wide file respectively. The GIT_CONFIG environment -variable has a similar effect, but you can specify any filename you want. +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 @@ -283,33 +344,35 @@ 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 +------------ +# +# 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 @@ -400,17 +463,38 @@ For URLs in `https://weak.example.com`, `http.sslVerify` is set to false, while it is set to `true` for all others: ------------ -% git config --bool --get-urlmatch http.sslverify https://good.example.com +% git config --type=bool --get-urlmatch http.sslverify https://good.example.com true -% git config --bool --get-urlmatch http.sslverify https://weak.example.com +% 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.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/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt index b300e846f1..cb9b4d2e46 100644 --- a/Documentation/git-count-objects.txt +++ b/Documentation/git-count-objects.txt @@ -33,11 +33,16 @@ 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 not valid -loose objects nor valid packs +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:: diff --git a/Documentation/git-credential-cache--daemon.txt b/Documentation/git-credential-cache--daemon.txt index d15db42d43..7051c6bdf8 100644 --- a/Documentation/git-credential-cache--daemon.txt +++ b/Documentation/git-credential-cache--daemon.txt @@ -8,7 +8,7 @@ git-credential-cache--daemon - Temporarily store user credentials in memory SYNOPSIS -------- [verse] -git credential-cache--daemon <socket> +git credential-cache--daemon [--debug] <socket> DESCRIPTION ----------- @@ -21,6 +21,10 @@ 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/Documentation/git-credential-cache.txt b/Documentation/git-credential-cache.txt index 89b730632d..0216c18ef8 100644 --- a/Documentation/git-credential-cache.txt +++ b/Documentation/git-credential-cache.txt @@ -8,7 +8,7 @@ git-credential-cache - Helper to temporarily store passwords in memory SYNOPSIS -------- ----------------------------- -git config credential.helper 'cache [options]' +git config credential.helper 'cache [<options>]' ----------------------------- DESCRIPTION @@ -33,10 +33,13 @@ OPTIONS --socket <path>:: Use `<path>` to contact a running cache daemon (or start a new - cache daemon if one is not started). Defaults to - `~/.git-credential-cache/socket`. If your home directory is on a - network-mounted filesystem, you may need to change this to a - local filesystem. + 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 ---------------------- diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt index 8481cae70e..76b0798856 100644 --- a/Documentation/git-credential-store.txt +++ b/Documentation/git-credential-store.txt @@ -8,7 +8,7 @@ git-credential-store - Helper to store credentials on disk SYNOPSIS -------- ------------------- -git config credential.helper 'store [options]' +git config credential.helper 'store [<options>]' ------------------- DESCRIPTION @@ -29,12 +29,43 @@ linkgit:gitcredentials[7] or `EXAMPLES` below. OPTIONS ------- ---store=<path>:: +--file=<path>:: - Use `<path>` to store credentials. The file will have its + 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. Defaults to `~/.git-credentials`. + 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 -------- @@ -63,6 +94,10 @@ stored on its own line as a URL like: https://user:pass@example.com ------------------------------ +No other kinds of lines (e.g. empty lines or comment lines) are +allowed in the file, even though some may be silently ignored. Do +not view or edit the file with editors. + 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 diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt index b211440373..31c81c4c02 100644 --- a/Documentation/git-credential.txt +++ b/Documentation/git-credential.txt @@ -19,8 +19,7 @@ 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 +interface models the internal C API; see credential.h for more background on the concepts. git-credential takes an "action" option on the command-line (one of @@ -104,17 +103,20 @@ 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 login information (e.g. host, protocol, path), or to the actual +credential data to be obtained (username/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. +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`:: @@ -124,7 +126,8 @@ Git understands the following attributes: `host`:: - The remote hostname for a network credential. + The remote hostname for a network credential. This includes + the port number if one was specified (e.g., "example.com:8088"). `path`:: @@ -135,7 +138,7 @@ Git understands the following attributes: `username`:: The credential's username, if we already have one (e.g., from a - URL, from the user, or from a previously run helper). + URL, the configuration, the user, or from a previously run helper). `password`:: @@ -147,8 +150,12 @@ Git understands the following attributes: 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. + can help callers avoid parsing URLs themselves. ++ +Note that specifying a protocol is mandatory and if the URL +doesn't specify a hostname (e.g., "cert:///path/to/file") the +credential will contain a hostname attribute whose value is an +empty string. ++ +Components which are missing from the URL (e.g., there is no +username in the example above) will be left unset. diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index d1bcda28f4..de1ebed67d 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -21,8 +21,8 @@ DESCRIPTION *WARNING:* `git cvsimport` uses cvsps version 2, which is considered deprecated; it does not work with cvsps version 3 and later. If you are performing a one-shot import of a CVS repository consider using -link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or -link:https://github.com/BartMassey/parsecvs[parsecvs]. +http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or +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. @@ -74,10 +74,10 @@ OPTIONS akin to the way 'git clone' uses 'origin' by default. -o <branch-for-HEAD>:: - When no remote is specified (via -r) the 'HEAD' branch + 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 + 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. @@ -103,7 +103,7 @@ the old cvs2git tool. -p <options-for-cvsps>:: Additional options for cvsps. - The options '-u' and '-A' are implicit and should not be used here. + 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. @@ -122,7 +122,7 @@ If you need to pass multiple options, separate them with a comma. -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 + 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. @@ -144,7 +144,7 @@ This option can be used several times to provide several detection regexes. 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 timezone: + optional time zone: + --------- exon=Andreas Ericsson <ae@op5.se> @@ -154,7 +154,7 @@ This option can be used several times to provide several detection regexes. + 'git cvsimport' will make it appear as those authors had their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly -all along. If a timezone is specified, GIT_AUTHOR_DATE will +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` @@ -186,7 +186,7 @@ messages, bug-tracking systems, email archives, and the like. OUTPUT ------ -If '-v' is specified, the script reports what it is doing. +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. @@ -219,7 +219,7 @@ 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 imort, consider using cvs2git: +want to import, consider using cvs2git: * cvs2git (part of cvs2svn), `http://subversion.apache.org/` diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt index 472f5cbd07..1b1c71ad9d 100644 --- a/Documentation/git-cvsserver.txt +++ b/Documentation/git-cvsserver.txt @@ -22,7 +22,7 @@ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver Usage: [verse] -'git-cvsserver' [options] [pserver|server] [<directory> ...] +'git-cvsserver' [<options>] [pserver|server] [<directory> ...] OPTIONS ------- @@ -54,7 +54,7 @@ Print usage information and exit 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. +unless `--export-all` was given, too. DESCRIPTION @@ -110,7 +110,7 @@ to allow writes to, for example: authdb = /etc/cvsserver/passwd ------ -The format of these files is username followed by the crypted password, +The format of these files is username followed by the encrypted password, for example: ------ @@ -154,7 +154,7 @@ with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean [gitcvs] enabled=1 # optional for debugging - logfile=/path/to/logfile + logFile=/path/to/logfile ------ Note: you need to ensure each user that is going to invoke 'git-cvsserver' has @@ -207,7 +207,7 @@ allowing access over SSH. ------ [[dbbackend]] -Database Backend +DATABASE BACKEND ---------------- 'git-cvsserver' uses one database per Git head (i.e. CVS module) to @@ -223,7 +223,7 @@ 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). +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 @@ -232,7 +232,7 @@ 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 can not be reliably regenerated in a +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 @@ -254,14 +254,14 @@ Configuring database backend its documentation if changing these variables, especially about `DBI->connect()`. -gitcvs.dbname:: +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:: +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 @@ -271,12 +271,12 @@ gitcvs.dbdriver:: Default: 'SQLite' gitcvs.dbuser:: - Database user. Only useful if setting `dbdriver`, since + 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 +gitcvs.dbPass:: + Database password. Only useful if setting `dbDriver`, since SQLite has no concept of database passwords. gitcvs.dbTableNamePrefix:: @@ -288,13 +288,13 @@ All variables can also be set per access method, see <<configaccessmethod,above> Variable substitution ^^^^^^^^^^^^^^^^^^^^^ -In `dbdriver` and `dbuser` you can use the following variables: +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 + alphanumeric ones, `.`, and `-` are replaced with `_` (this should make it easier to use the directory name in a filename if wanted) %m:: @@ -321,7 +321,7 @@ git-cvsserver, as described above. When these environment variables are set, the corresponding command-line arguments may not be used. -Eclipse CVS Client Notes +ECLIPSE CVS CLIENT NOTES ------------------------ To get a checkout with the Eclipse CVS client: @@ -332,7 +332,7 @@ To get a checkout with the Eclipse CVS client: 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 +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. @@ -346,7 +346,7 @@ offer. In that case CVS_SERVER is ignored, and you will have to replace the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc` so that calling 'cvs' effectively calls 'git-cvsserver'. -Clients known to work +CLIENTS KNOWN TO WORK --------------------- - CVS 1.12.9 on Debian @@ -354,7 +354,7 @@ Clients known to work - Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes) - TortoiseCVS -Operations supported +OPERATIONS SUPPORTED -------------------- All the operations required for normal use are supported, including @@ -402,29 +402,29 @@ 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, +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` +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 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". +and `gitcvs.allBinary` to "guess". -Dependencies +DEPENDENCIES ------------ 'git-cvsserver' depends on DBD::SQLite. diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt index 223f731523..fdc28c041c 100644 --- a/Documentation/git-daemon.txt +++ b/Documentation/git-daemon.txt @@ -20,6 +20,7 @@ SYNOPSIS [--inetd | [--listen=<host_or_ipaddr>] [--port=<n>] [--user=<user> [--group=<group>]]] + [--log-destination=(stderr|syslog|none)] [<directory>...] DESCRIPTION @@ -30,7 +31,7 @@ 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 +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. @@ -56,7 +57,7 @@ OPTIONS 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'. + as `/srv/git/hello.git`. --base-path-relaxed:: If --base-path is enabled and repo lookup fails, with this option @@ -80,7 +81,8 @@ OPTIONS do not have the 'git-daemon-export-ok' file. --inetd:: - Have the server run as an inetd service. Implies --syslog. + Have the server run as an inetd service. Implies --syslog (may be + overridden with `--log-destination=`). Incompatible with --detach, --port, --listen, --user and --group options. @@ -90,10 +92,10 @@ OPTIONS 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. + Incompatible with `--inetd` option. --port=<n>:: - Listen on an alternative port. Incompatible with '--inetd' option. + Listen on an alternative port. Incompatible with `--inetd` option. --init-timeout=<n>:: Timeout (in seconds) between the moment the connection is established @@ -110,8 +112,28 @@ OPTIONS zero for no limit. --syslog:: - Log to syslog instead of stderr. Note that this option does not imply - --verbose, thus by default only error conditions will be logged. + Short for `--log-destination=syslog`. + +--log-destination=<destination>:: + Send log messages to the specified destination. + Note that this option does not imply --verbose, + thus by default only error conditions will be logged. + The <destination> must be one of: ++ +-- +stderr:: + Write to standard error. + Note that if `--detach` is specified, + the process disconnects from the real standard error, + making this destination effectively equivalent to `none`. +syslog:: + Write to syslog, using the `git-daemon` identifier. +none:: + Disable all logging. +-- ++ +The default destination is `syslog` if `--inetd` or `--detach` is specified, +otherwise `stderr`. --user-path:: --user-path=<path>:: @@ -169,7 +191,7 @@ Git configuration files in that directory are readable by `<user>`. --forbid-override=<service>:: Allow/forbid overriding the site-wide default with per repository configuration. By default, all the services - are overridable. + may be overridden. --[no-]informative-errors:: When informative errors are turned on, git-daemon will report @@ -184,11 +206,11 @@ Git configuration files in that directory are readable by `<user>`. 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 + (%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 + 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 @@ -204,7 +226,7 @@ SERVICES -------- These services can be globally enabled/disabled using the -command line options of this command. If a finer-grained +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 @@ -296,7 +318,7 @@ 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 + repository (that is the file 'config' next to `HEAD`, 'refs' and 'objects'). + ---------------------------------------------------------------- diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index d20ca402a1..a88f6ae2c6 100644 --- a/Documentation/git-describe.txt +++ b/Documentation/git-describe.txt @@ -3,14 +3,14 @@ git-describe(1) NAME ---- -git-describe - Show the most recent tag that is reachable from a commit - +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>] [<commit-ish>...] 'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>] +'git describe' <blob> DESCRIPTION ----------- @@ -18,21 +18,34 @@ 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. +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. + Commit-ish object names to describe. Defaults to HEAD if omitted. --dirty[=<mark>]:: - Describe the working tree. - It means describe HEAD and appends <mark> (`-dirty` by - default) if the working tree is dirty. +--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 @@ -82,8 +95,25 @@ OPTIONS --match <pattern>:: Only consider tags matching the given `glob(7)` pattern, - excluding the "refs/tags/" prefix. This can be used to avoid - leaking private tags from the repository. + 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. @@ -109,7 +139,7 @@ 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" + 7-char abbreviation for the tip commit +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 @@ -154,7 +184,7 @@ 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 +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. @@ -164,6 +194,14 @@ 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/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt index a86cf62e68..f4bd8155c0 100644 --- a/Documentation/git-diff-index.txt +++ b/Documentation/git-diff-index.txt @@ -37,16 +37,16 @@ include::diff-options.txt[] include::diff-format.txt[] -Operating Modes +OPERATING MODES --------------- You can choose whether you want to trust the index file entirely -(using the '--cached' flag) or ask the diff logic to show any files +(using the `--cached` flag) or ask the diff logic to show any files that don't match the stat state as being "tentatively changed". Both of these operations are very useful indeed. -Cached Mode +CACHED MODE ----------- -If '--cached' is specified, it allows you to ask: +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') @@ -77,7 +77,7 @@ So doing a `git diff-index --cached` is basically very useful when you are asking yourself "what have I already marked for being committed, and what's the difference to a previous tree". -Non-cached Mode +NON-CACHED MODE --------------- The "non-cached" mode takes a different approach, and is potentially the more useful of the two in that what it does can't be emulated with @@ -85,7 +85,7 @@ 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 + 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' @@ -100,8 +100,8 @@ have not actually done a 'git update-index' on it yet - there is no 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` has is -not up-to-date and may contain new stuff. The all-zero sha1 means that to +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. diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt index 1439486e40..5c8a2a5e97 100644 --- a/Documentation/git-diff-tree.txt +++ b/Documentation/git-diff-tree.txt @@ -10,8 +10,8 @@ SYNOPSIS -------- [verse] 'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty] - [-t] [-r] [-c | --cc] [--root] [<common diff options>] - <tree-ish> [<tree-ish>] [<path>...] + [-t] [-r] [-c | --cc] [--combined-all-paths] [--root] + [<common diff options>] <tree-ish> [<tree-ish>] [<path>...] DESCRIPTION ----------- @@ -31,10 +31,7 @@ include::diff-options.txt[] <path>...:: If provided, the results are limited to a subset of files - matching one of these prefix strings. - i.e., file matches `/^<pattern1>|<pattern2>|.../` - Note that this parameter does not provide any wildcard or regexp - features. + matching one of the provided pathspecs. -r:: recurse into sub-trees @@ -43,11 +40,11 @@ include::diff-options.txt[] show tree entry itself as well as subtrees. Implies -r. --root:: - When '--root' is specified the initial commit will be shown as a big + 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 + 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 @@ -70,13 +67,13 @@ commits (but not trees). 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'. + 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. + 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 @@ -91,23 +88,30 @@ include::pretty-options.txt[] -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 + 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). + 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 + 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. @@ -115,51 +119,6 @@ include::pretty-options.txt[] include::pretty-formats.txt[] - -Limiting Output ---------------- -If you're only interested in differences in a subset of files, for -example some architecture-specific files, you might do: - - git diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64 - -and it will only show you what changed in those two directories. - -Or if you are searching for what changed in just `kernel/sched.c`, just do - - git diff-tree -r <tree-ish> <tree-ish> kernel/sched.c - -and it will ignore all differences to other files. - -The pattern is always the prefix, and is matched exactly. There are no -wildcards. Even stricter, it has to match a complete path component. -I.e. "foo" does not pick up `foobar.h`. "foo" does match `foo/bar.h` -so it can be used to name subdirectories. - -An example of normal usage is: - - torvalds@ppc970:~/git> git diff-tree --abbrev 5319e4 - :100664 100664 ac348b... a01513... git-fsck-objects.c - -which tells you that the last commit changed just one file (it's from -this one: - ------------------------------------------------------------------------------ -commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8 -tree 5319e4d609cdd282069cc4dce33c1db559539b03 -parent b4e628ea30d5ab3606119d2ea5caeab141d38df7 -author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005 -committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005 - -Make "git-fsck-objects" print out all the root commits it finds. - -Once I do the reference tracking, I'll also make it print out all the -HEAD commits it finds, which is even more interesting. ------------------------------------------------------------------------------ - -in case you care). - - include::diff-format.txt[] GIT diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index 33fbd8c56f..727f24d16e 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -9,19 +9,21 @@ git-diff - Show changes between commits, commit and working tree, etc SYNOPSIS -------- [verse] -'git diff' [options] [<commit>] [--] [<path>...] -'git diff' [options] --cached [<commit>] [--] [<path>...] -'git diff' [options] <commit> <commit> [--] [<path>...] -'git diff' [options] <blob> <blob> -'git diff' [options] [--no-index] [--] <path> <path> +'git diff' [<options>] [<commit>] [--] [<path>...] +'git diff' [<options>] --cached [<commit>] [--] [<path>...] +'git diff' [<options>] <commit> [<commit>...] <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. +between the index and a tree, changes between two trees, changes resulting +from a merge, changes between two blob objects, or changes between two +files on disk. -'git diff' [--options] [--] [<path>...]:: +'git diff' [<options>] [--] [<path>...]:: This form is to view the changes you made relative to the index (staging area for the next commit). In other @@ -29,26 +31,26 @@ two blob objects, or changes between two files on disk. further add to the index but you still haven't. You can stage these changes by using linkgit:git-add[1]. -'git diff' --no-index [--options] [--] [<path>...]:: +'git diff' [<options>] --no-index [--] <path> <path>:: This form is to compare the given two paths on the filesystem. You can omit the `--no-index` option when 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. + controlled by Git. This form implies `--exit-code`. -'git diff' [--options] --cached [<commit>] [--] [<path>...]:: +'git diff' [<options>] --cached [<commit>] [--] [<path>...]:: This form is to view the changes you staged for the next commit relative to the named <commit>. Typically you would want comparison with the latest commit, so if you do not give <commit>, it defaults to HEAD. - If HEAD does not exist (e.g. unborned branches) and + If HEAD does not exist (e.g. unborn branches) and <commit> is not given, it shows all staged changes. --staged is a synonym of --cached. -'git diff' [--options] <commit> [--] [<path>...]:: +'git diff' [<options>] <commit> [--] [<path>...]:: This form is to view the changes you have in your working tree relative to the named <commit>. You can @@ -56,26 +58,36 @@ two blob objects, or changes between two files on disk. branch name to compare with the tip of a different branch. -'git diff' [--options] <commit> <commit> [--] [<path>...]:: +'git diff' [<options>] <commit> <commit> [--] [<path>...]:: This is to view the changes between two arbitrary <commit>. -'git diff' [--options] <commit>..<commit> [--] [<path>...]:: +'git diff' [<options>] <commit> <commit>... <commit> [--] [<path>...]:: - This is synonymous to the previous form. If <commit> on + This form is to view the results of a merge commit. The first + listed <commit> must be the merge itself; the remaining two or + more commits should be its parents. A convenient way to produce + the desired set of revisions is to use the {caret}@ suffix. + For instance, if `master` names a merge commit, `git diff master + master^@` gives the same combined diff as `git show master`. + +'git diff' [<options>] <commit>..<commit> [--] [<path>...]:: + + This is synonymous to the earlier form (without the "..") for + viewing the changes between two arbitrary <commit>. If <commit> on one side is omitted, it will have the same effect as using HEAD instead. -'git diff' [--options] <commit>\...<commit> [--] [<path>...]:: +'git diff' [<options>] <commit>\...<commit> [--] [<path>...]:: This form is to view the changes on the branch containing and up to the second <commit>, starting at a common ancestor of both <commit>. "git diff A\...B" is equivalent to - "git diff $(git-merge-base A B) B". You can omit any one + "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 if you are doing something exotic, it should be +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>. @@ -87,7 +99,7 @@ and the range notations ("<commit>..<commit>" and "<commit>\...<commit>") do not mean a range as defined in the "SPECIFYING RANGES" section in linkgit:gitrevisions[7]. -'git diff' [options] <blob> <blob>:: +'git diff' [<options>] <blob> <blob>:: This form is to view the differences between the raw contents of two blob objects. @@ -97,6 +109,20 @@ 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 @@ -118,9 +144,9 @@ $ 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. + 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" + would be committing if you run "git commit -a" Comparing with arbitrary commits:: + @@ -131,10 +157,10 @@ $ git diff HEAD^ HEAD <3> ------------ + <1> Instead of using the tip of the current branch, compare with the -tip of "test" branch. + 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". + 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:: @@ -148,7 +174,7 @@ $ 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. + branch was started off it. Limiting the diff output:: + @@ -158,10 +184,10 @@ $ git diff --name-status <2> $ git diff arch/i386 include/asm-i386 <3> ------------ + -<1> Show only modification, rename and copy, but not addition -nor deletion. +<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. + diff output. <3> Limit diff output to named subtrees. Munging the diff output:: @@ -172,7 +198,7 @@ $ git diff -R <2> ------------ + <1> Spend extra cycles to find renames, copies and complete -rewrites (very expensive). + rewrites (very expensive). <2> Output diff in reverse. SEE ALSO @@ -182,7 +208,8 @@ linkgit:git-difftool[1], linkgit:git-log[1], linkgit:gitdiffcore[7], linkgit:git-format-patch[1], -linkgit:git-apply[1] +linkgit:git-apply[1], +linkgit:git-show[1] GIT --- diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt index 11887e63a0..484c485fd0 100644 --- a/Documentation/git-difftool.txt +++ b/Documentation/git-difftool.txt @@ -86,10 +86,22 @@ instead. `--no-symlinks` is the default on Windows. Additionally, `$BASE` is set in the environment. -g:: ---gui:: +--[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`. + `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. @@ -116,6 +128,11 @@ 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]:: diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt index 85f1f30fdf..1978dbdc6a 100644 --- a/Documentation/git-fast-export.txt +++ b/Documentation/git-fast-export.txt @@ -9,7 +9,7 @@ git-fast-export - Git data exporter SYNOPSIS -------- [verse] -'git fast-export [options]' | 'git fast-import' +'git fast-export [<options>]' | 'git fast-import' DESCRIPTION ----------- @@ -17,9 +17,9 @@ 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'. - +linkgit:git-bundle[1]), or as a format that can be edited before being +fed to 'git fast-import' in order to do history rewrites (an ability +relied on by tools like 'git filter-repo'). OPTIONS ------- @@ -67,19 +67,28 @@ produced incorrect results if you gave these options. 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. + --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. + must use the same format as produced by --export-marks. + +--mark-tags:: + In addition to labelling blobs and commits with mark ids, also + label tags. This is useful in conjunction with + `--export-marks` and `--import-marks`, and is also useful (and + necessary) for exporting of nested tags. It does not hurt + other cases and would be the default, but many fast-import + frontends are not prepared to accept tags with mark + identifiers. + -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. +Any commits (or tags) 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 @@ -105,12 +114,54 @@ marks the same across runs. 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. + +--anonymize-map=<from>[:<to>]:: + Convert token `<from>` to `<to>` in the anonymized output. If + `<to>` is omitted, map `<from>` to itself (i.e., do not + anonymize it). 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 re-encoded 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. + 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 -------- @@ -137,13 +188,97 @@ referenced by that revision range contains the string 'refs/heads/master'. -Limitations +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. + +Reproducing some bugs may require referencing particular commits or +paths, which becomes challenging after refnames and paths have been +anonymized. You can ask for a particular token to be left as-is or +mapped to a new value. For example, if you have a bug which reproduces +with `git rev-list sensitive -- secret.c`, you can run: + +--------------------------------------------------- +$ git fast-export --anonymize --all \ + --anonymize-map=sensitive:foo \ + --anonymize-map=secret.c:bar.c \ + >stream +--------------------------------------------------- + +After importing the stream, you can then run `git rev-list foo -- bar.c` +in the anonymized repository. + +Note that paths and refnames are split into tokens at slash boundaries. +The command above would anonymize `subdir/secret.c` as something like +`path123/bar.c`; you could then search for `bar.c` in the anonymized +repository to determine the final pathname. + +To make referencing the final pathname simpler, you can map each path +component; so if you also anonymize `subdir` to `publicdir`, then the +final pathname would be `publicdir/bar.c`. + +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/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 73f980638e..7d9aad2a7e 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -9,7 +9,7 @@ git-fast-import - Backend for fast Git data importers SYNOPSIS -------- [verse] -frontend | 'git fast-import' [options] +frontend | 'git fast-import' [<options>] DESCRIPTION ----------- @@ -40,21 +40,37 @@ OPTIONS not contain the old commit). --quiet:: - Disable all non-fatal output, making fast-import silent when it - is successful. This option disables the output shown by - \--stats. + 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. + is currently the default, but can be disabled with --quiet. + +--allow-unsafe-features:: + Many command-line options can be provided as part of the + fast-import stream itself by using the `feature` or `option` + commands. However, some of these options are unsafe (e.g., + allowing fast-import to access the filesystem outside of the + repository). These options are disabled by default, but can be + allowed by providing this option on the command line. This + currently impacts only the `export-marks`, `import-marks`, and + `import-marks-if-exists` feature commands. ++ + Only enable this option if you trust the program generating the + fast-import stream! This option is enabled automatically for + remote-helpers that use the `import` capability, as they are + already trusted to run their own code. Options for Frontends ~~~~~~~~~~~~~~~~~~~~~ --cat-blob-fd=<fd>:: - Write responses to `cat-blob` and `ls` queries to the + 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. @@ -81,12 +97,12 @@ Locations of Marks Files 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. + 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. + 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. @@ -106,6 +122,26 @@ Locations of Marks Files Relative and non-relative marks may be combined by interweaving --(no-)-relative-marks with the --(import|export)-marks= options. +Submodule Rewriting +~~~~~~~~~~~~~~~~~~~ + +--rewrite-submodules-from=<name>:<file>:: +--rewrite-submodules-to=<name>:<file>:: + Rewrite the object IDs for the submodule specified by <name> from the values + used in the from <file> to those used in the to <file>. The from marks should + have been created by `git fast-export`, and the to marks should have been + created by `git fast-import` when importing that same submodule. ++ +<name> may be any arbitrary string not containing a colon character, but the +same value must be used with both options when specifying corresponding marks. +Multiple submodules may be specified with different values for <name>. It is an +error not to use these options in corresponding pairs. ++ +These options are primarily useful when converting a repository from one hash +algorithm to another; without them, fast-import will fail if it encounters a +submodule because it has no way of writing the object ID into the new hash +algorithm. + Performance and Compression Tuning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -121,7 +157,7 @@ Performance and Compression Tuning --depth=<n>:: Maximum delta depth, for blob and tree deltification. - Default is 10. + Default is 50. --export-pack-edges=<file>:: After creating a packfile, print a line of data to @@ -136,8 +172,10 @@ Performance and Compression Tuning Maximum size of each output packfile. The default is unlimited. +fastimport.unpackLimit:: + See linkgit:git-config[1] -Performance +PERFORMANCE ----------- The design of fast-import allows it to import large projects in a minimum amount of memory usage and processing time. Assuming the frontend @@ -153,7 +191,7 @@ faster if the source data is stored on a different drive than the destination Git repository (due to less IO contention). -Development Cost +DEVELOPMENT COST ---------------- A typical frontend for fast-import tends to weigh in at approximately 200 lines of Perl/Python/Ruby code. Most developers have been able to @@ -163,7 +201,7 @@ an ideal situation, given that most conversion tools are throw-away (use once, and never look back). -Parallel Operation +PARALLEL OPERATION ------------------ Like 'git push' or 'git fetch', imports handled by fast-import are safe to run alongside parallel `git repack -a -d` or `git gc` invocations, @@ -179,12 +217,12 @@ 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 +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 +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 @@ -202,7 +240,7 @@ directory also allows fast-import to run very quickly, as it does not need to perform any costly file update operations when switching between branches. -Input Format +INPUT FORMAT ------------ With the exception of raw file data (which Git does not interpret) the fast-import input format is text (ASCII) based. This text based @@ -231,11 +269,11 @@ 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. +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 + 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 @@ -251,11 +289,18 @@ 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 timezone. In this +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. +variation in formatting will cause fast-import to reject the value, +and some sanity checks on the numeric values may also be performed. + +`raw-permissive`:: + This is the same as `raw` except that no sanity checks on + the numeric epoch and local offset are performed. This can + be useful when trying to filter or import an existing history + with e.g. bogus timezone values. `rfc2822`:: This is the standard email format as described by RFC 2822. @@ -271,7 +316,7 @@ 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 timezone/UTC offset information +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. @@ -287,13 +332,13 @@ format, or its format is easily convertible to it, as there is no ambiguity in parsing. `now`:: - Always use the current time and timezone. The literal + 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 timezone of this system +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 -timezone. +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 @@ -334,6 +379,13 @@ and control the current import process. More detailed discussion `commit` command. This command is optional and is not needed to perform an import. +`alias`:: + Record that a mark refers to a given object without first + creating any new object. Using --import-marks and referring + to missing marks will cause fast-import to fail, so aliases + can provide a way to set otherwise pruned commits to a valid + value (e.g. the nearest non-pruned ancestor). + `checkpoint`:: Forces fast-import to close the current packfile, generate its unique SHA-1 checksum and index, and start a new packfile. @@ -348,7 +400,12 @@ and control the current import process. More detailed discussion `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. + `--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' @@ -377,11 +434,13 @@ 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)? + ('merge' SP <commit-ish> LF)* (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)* LF? .... @@ -413,7 +472,12 @@ 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). +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` ^^^^^^^^ @@ -437,10 +501,16 @@ the email address from the other fields in the line. Note that 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. +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 @@ -483,6 +553,9 @@ Marks must be declared (via `mark`) before they can be used. * 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: ---- @@ -504,10 +577,6 @@ 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. -However Git's other tools never create commits with more than 15 -additional ancestors (forming a 16-way merge). For this reason -it is suggested that frontends do not use more than 15 `merge` -commands per commit; 16, if starting a new, empty branch. Here `<commit-ish>` is any of the commit specification expressions also accepted by `from` (see above). @@ -601,7 +670,7 @@ 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 @@ -734,6 +803,19 @@ 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 @@ -741,7 +823,9 @@ lightweight (non-annotated) tags see the `reset` command below. .... 'tag' SP <name> LF + mark? 'from' SP <commit-ish> LF + original-oid? 'tagger' (SP <name>)? SP LT <email> GT SP <when> LF data .... @@ -816,6 +900,7 @@ assigned mark. .... 'blob' LF mark? + original-oid? data .... @@ -878,6 +963,21 @@ 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). +`alias` +~~~~~~~ +Record that a mark refers to a given object without first creating any +new object. + +.... + 'alias' LF + mark + 'to' SP <commit-ish> LF + LF? +.... + +For a detailed description of `<commit-ish>` see above under `from`. + + `checkpoint` ~~~~~~~~~~~~ Forces fast-import to close the current packfile, start a new one, and to @@ -889,7 +989,7 @@ save out all current branch refs, tags and marks. .... Note that fast-import automatically switches packfiles when the current -packfile reaches \--max-pack-size, or 4 GiB, whichever limit is +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. @@ -931,6 +1031,21 @@ 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 @@ -954,9 +1069,10 @@ Output uses the same format as `git cat-file --batch`: <contents> LF ==== -This command can be used anywhere in the stream that comments are -accepted. In particular, the `cat-blob` command can be used in the -middle of a commit but not in the middle of a `data` command. +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. @@ -969,8 +1085,8 @@ 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 be used anywhere in the stream that comments are -accepted, including the middle of a commit. +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`. @@ -1001,7 +1117,8 @@ Output uses the same format as `git ls-tree <tree> -- <path>`: ==== The <dataref> represents the blob, tree, or commit object at <path> -and can be used in later 'cat-blob', 'filemodify', or 'ls' commands. +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 @@ -1030,7 +1147,7 @@ relative-marks:: no-relative-marks:: force:: Act as though the corresponding command-line option with - a leading '--' was passed on the command line + a leading `--` was passed on the command line (see OPTIONS, above). import-marks:: @@ -1043,9 +1160,11 @@ import-marks-if-exists:: "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 'cat-blob' or 'ls' command. + 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, @@ -1079,13 +1198,13 @@ options the user may specify to git fast-import itself. 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. +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 commandline options change import semantics and may therefore +The following command-line options change import semantics and may therefore not be passed as option: * date-format @@ -1099,11 +1218,11 @@ not be passed as option: 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 +If the `--done` command-line option or `feature done` command is in use, the `done` command is mandatory and marks the end of the stream. -Responses To Commands +RESPONSES TO COMMANDS --------------------- New objects written by fast-import are not available immediately. Most fast-import commands have no visible effect until the next @@ -1125,14 +1244,14 @@ bidirectional pipes: git fast-import >fast-import-output ==== -A frontend set up this way can use `progress`, `ls`, and `cat-blob` -commands to read information from the import in progress. +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`, and `cat-blob` before +pending output from `progress`, `ls`, `get-mark`, and `cat-blob` before performing writes to fast-import that might block. -Crash Reports +CRASH REPORTS ------------- If fast-import is supplied invalid input it will terminate with a non-zero exit status and create a crash report in the top level of @@ -1219,7 +1338,7 @@ An example crash: END OF CRASH REPORT ==== -Tips and Tricks +TIPS AND TRICKS --------------- The following tips and tricks have been collected from various users of fast-import, and are offered here as suggestions. @@ -1227,7 +1346,7 @@ 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 +(`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 @@ -1292,7 +1411,7 @@ 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 +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! @@ -1306,7 +1425,7 @@ 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'. +--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. @@ -1321,7 +1440,7 @@ Your users will feel better knowing how much of the data stream has been processed. -Packfile Optimization +PACKFILE OPTIMIZATION --------------------- When packing a blob fast-import always attempts to deltify against the last blob written. Unless specifically arranged for by the frontend, @@ -1351,8 +1470,15 @@ 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 +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 @@ -1408,7 +1534,7 @@ branch, their in-memory storage size can grow to a considerable size 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=. +increased or decreased on the command line with --active-branches=. per active tree ~~~~~~~~~~~~~~~ @@ -1430,7 +1556,7 @@ and lazy loading of subtrees, allows fast-import to efficiently import projects with 2,000+ branches and 45,114+ files in a very limited memory footprint (less than 2.7 MiB per active branch). -Signals +SIGNALS ------- Sending *SIGUSR1* to the 'git fast-import' process ends the current packfile early, simulating a `checkpoint` command. The impatient @@ -1438,6 +1564,10 @@ 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/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index 444b805d35..c975884793 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -12,7 +12,7 @@ SYNOPSIS 'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] - [-v] [<host>:]<directory> [<refs>...] + [-v] <repository> [<refs>...] DESCRIPTION ----------- @@ -41,13 +41,13 @@ OPTIONS option, then the refs from stdin are processed after those on the command line. + -If '--stateless-rpc' is specified together with this option then +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 + Pass `-q` flag to 'git unpack-objects'; this makes the cloning process less verbose. -k:: @@ -80,13 +80,27 @@ be in a separate packet, and the list must end with a flush packet. the things up in .bash_profile). --exec=<git-upload-pack>:: - Same as \--upload-pack=<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. @@ -97,18 +111,21 @@ be in a separate packet, and the list must end with a flush packet. -v:: Run verbosely. -<host>:: - A remote host that houses the repository. When this - part is specified, 'git-upload-pack' is invoked via - ssh. - -<directory>:: - The repository to sync from. +<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 --- diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index e08a028946..45b6d8e633 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -17,26 +17,31 @@ SYNOPSIS DESCRIPTION ----------- -Fetches named heads or tags from one or more other repositories, -along with the objects necessary to complete them. - -The ref names and their object names of fetched refs are stored -in `.git/FETCH_HEAD`. This information is left for a later merge -operation done by 'git merge'. - -When <refspec> stores the fetched result in remote-tracking branches, -the tags that point at these branches are automatically -followed. This is done by first fetching from the remote using -the given <refspec>s, and if the repository has objects that are -pointed by remote tags that it does not yet have, then fetch -those missing tags. If the other end has tags that point at -branches you are not interested in, you will not get them. - -'git fetch' can fetch from either a single named repository, +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[] @@ -46,6 +51,193 @@ 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 -------- @@ -63,22 +255,37 @@ refspec. * Using refspecs explicitly: + ------------------------------------------------ -$ git fetch origin +pu:pu maint:tmp +$ git fetch origin +seen:seen maint:tmp ------------------------------------------------ + -This updates (or creates, as necessary) branches `pu` and `tmp` in +This updates (or creates, as necessary) branches `seen` and `tmp` in the local repository by fetching from the branches (respectively) -`pu` and `maint` from the remote repository. +`seen` and `maint` from the remote repository. + -The `pu` branch will be updated even if it is does not fast-forward, +The `seen` 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 can not be +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. diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index e4c8e82660..40ba4aa3e6 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -8,13 +8,26 @@ git-filter-branch - Rewrite branches SYNOPSIS -------- [verse] -'git filter-branch' [--env-filter <command>] [--tree-filter <command>] +'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>] [--subdirectory-filter <directory>] - [--prune-empty] + [--tag-name-filter <command>] [--prune-empty] [--original <namespace>] [-d <directory>] [-f | --force] - [--] [<rev-list options>...] + [--state-branch <branch>] [--] [<rev-list options>...] + +WARNING +------- +'git filter-branch' has a plethora of pitfalls that can produce non-obvious +manglings of the intended history rewrite (and can leave you with little +time to investigate such problems since it has such abysmal performance). +These safety and performance issues cannot be backward compatibly fixed and +as such, its use is not recommended. Please use an alternative history +filtering tool such as https://github.com/newren/git-filter-repo/[git +filter-repo]. If you still need to use 'git filter-branch', please +carefully read <<SAFETY>> (and <<PERFORMANCE>>) to learn about the land +mines of filter-branch, and then vigilantly avoid as many of the hazards +listed there as reasonably possible. DESCRIPTION ----------- @@ -52,7 +65,7 @@ if different from the rewritten ones, will be stored in the namespace 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. +`-d` option, e.g. on tmpfs. Reportedly the speedup is very noticeable. Filters @@ -61,7 +74,7 @@ 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 +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 @@ -82,12 +95,23 @@ 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). Do not forget - to re-export the variables. + variables (see linkgit:git-commit-tree[1] for details). --tree-filter <command>:: This is the filter for rewriting the tree and its contents. @@ -161,20 +185,13 @@ 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. ---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>>. - --prune-empty:: - Some kind of filters will generate empty commits, that left the tree - untouched. This switch allow git-filter-branch to ignore such - commits. Though, this switch only applies for commits that have one - and only one parent, it will hence keep merges points. Also, this - option is not compatible with the use of '--commit-filter'. Though you - just need to use the function 'git_commit_non_empty_tree "$@"' instead - of the `git commit-tree "$@"` idiom in your commit filter to make that - happen. + 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 @@ -185,7 +202,7 @@ to other tags will be rewritten to point to the underlying commit. 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 + does this in the `.git-rewrite/` directory but you can override that choice by this parameter. -f:: @@ -194,10 +211,16 @@ to other tags will be rewritten to point to the underlying commit. 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 + such as `--all`, but you must use `--` to separate them from the 'git filter-branch' options. Implies <<Remap_to_ancestor>>. @@ -205,14 +228,22 @@ to other tags will be rewritten to point to the underlying commit. Remap to ancestor ~~~~~~~~~~~~~~~~~ -By using linkgit:rev-list[1] arguments, e.g., path limiters, you can limit the +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. -Examples +EXIT STATUS +----------- + +On success, the exit status is `0`. If the filter can't find any commits to +rewrite, the exit status is `2`. On any other error, the exit status may be +any other non-zero value. + + +EXAMPLES -------- Suppose you want to remove a file (containing confidential information @@ -270,7 +301,7 @@ git filter-branch --parent-filter \ or even simpler: ----------------------------------------------- -echo "$commit-id $graft-id" >> .git/info/grafts +git replace --graft $commit-id $graft-id git filter-branch $graft-id..HEAD ----------------------------------------------- @@ -342,12 +373,10 @@ git filter-branch --env-filter ' if test "$GIT_AUTHOR_EMAIL" = "root@localhost" then GIT_AUTHOR_EMAIL=john@example.com - export GIT_AUTHOR_EMAIL fi if test "$GIT_COMMITTER_EMAIL" = "root@localhost" then GIT_COMMITTER_EMAIL=john@example.com - export GIT_COMMITTER_EMAIL fi ' -- --all -------------------------------------------------------- @@ -390,10 +419,10 @@ git filter-branch --index-filter \ -Checklist for Shrinking a Repository +CHECKLIST FOR SHRINKING A REPOSITORY ------------------------------------ -git-filter-branch is often used to get rid of a subset of files, +git-filter-branch can be used to get rid of a subset of files, usually with some combination of `--index-filter` and `--subdirectory-filter`. People expect the resulting repository to be smaller than the original, but you need a few more steps to @@ -429,6 +458,246 @@ warned. (or if your git-gc is not new enough to support arguments to `--prune`, use `git repack -ad; git prune` instead). +[[PERFORMANCE]] +PERFORMANCE +----------- + +The performance of git-filter-branch is glacially slow; its design makes it +impossible for a backward-compatible implementation to ever be fast: + +* In editing files, git-filter-branch by design checks out each and + every commit as it existed in the original repo. If your repo has + `10^5` files and `10^5` commits, but each commit only modifies five + files, then git-filter-branch will make you do `10^10` modifications, + despite only having (at most) `5*10^5` unique blobs. + +* If you try and cheat and try to make git-filter-branch only work on + files modified in a commit, then two things happen + + ** you run into problems with deletions whenever the user is simply + trying to rename files (because attempting to delete files that + don't exist looks like a no-op; it takes some chicanery to remap + deletes across file renames when the renames happen via arbitrary + user-provided shell) + + ** even if you succeed at the map-deletes-for-renames chicanery, you + still technically violate backward compatibility because users + are allowed to filter files in ways that depend upon topology of + commits instead of filtering solely based on file contents or + names (though this has not been observed in the wild). + +* Even if you don't need to edit files but only want to e.g. rename or + remove some and thus can avoid checking out each file (i.e. you can + use --index-filter), you still are passing shell snippets for your + filters. This means that for every commit, you have to have a + prepared git repo where those filters can be run. That's a + significant setup. + +* Further, several additional files are created or updated per commit + by git-filter-branch. Some of these are for supporting the + convenience functions provided by git-filter-branch (such as map()), + while others are for keeping track of internal state (but could have + also been accessed by user filters; one of git-filter-branch's + regression tests does so). This essentially amounts to using the + filesystem as an IPC mechanism between git-filter-branch and the + user-provided filters. Disks tend to be a slow IPC mechanism, and + writing these files also effectively represents a forced + synchronization point between separate processes that we hit with + every commit. + +* The user-provided shell commands will likely involve a pipeline of + commands, resulting in the creation of many processes per commit. + Creating and running another process takes a widely varying amount + of time between operating systems, but on any platform it is very + slow relative to invoking a function. + +* git-filter-branch itself is written in shell, which is kind of slow. + This is the one performance issue that could be backward-compatibly + fixed, but compared to the above problems that are intrinsic to the + design of git-filter-branch, the language of the tool itself is a + relatively minor issue. + + ** Side note: Unfortunately, people tend to fixate on the + written-in-shell aspect and periodically ask if git-filter-branch + could be rewritten in another language to fix the performance + issues. Not only does that ignore the bigger intrinsic problems + with the design, it'd help less than you'd expect: if + git-filter-branch itself were not shell, then the convenience + functions (map(), skip_commit(), etc) and the `--setup` argument + could no longer be executed once at the beginning of the program + but would instead need to be prepended to every user filter (and + thus re-executed with every commit). + +The https://github.com/newren/git-filter-repo/[git filter-repo] tool is +an alternative to git-filter-branch which does not suffer from these +performance problems or the safety problems (mentioned below). For those +with existing tooling which relies upon git-filter-branch, 'git +repo-filter' also provides +https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/filter-lamely[filter-lamely], +a drop-in git-filter-branch replacement (with a few caveats). While +filter-lamely suffers from all the same safety issues as +git-filter-branch, it at least ameliorates the performance issues a +little. + +[[SAFETY]] +SAFETY +------ + +git-filter-branch is riddled with gotchas resulting in various ways to +easily corrupt repos or end up with a mess worse than what you started +with: + +* Someone can have a set of "working and tested filters" which they + document or provide to a coworker, who then runs them on a different + OS where the same commands are not working/tested (some examples in + the git-filter-branch manpage are also affected by this). + BSD vs. GNU userland differences can really bite. If lucky, error + messages are spewed. But just as likely, the commands either don't + do the filtering requested, or silently corrupt by making some + unwanted change. The unwanted change may only affect a few commits, + so it's not necessarily obvious either. (The fact that problems + won't necessarily be obvious means they are likely to go unnoticed + until the rewritten history is in use for quite a while, at which + point it's really hard to justify another flag-day for another + rewrite.) + +* Filenames with spaces are often mishandled by shell snippets since + they cause problems for shell pipelines. Not everyone is familiar + with find -print0, xargs -0, git-ls-files -z, etc. Even people who + are familiar with these may assume such flags are not relevant + because someone else renamed any such files in their repo back + before the person doing the filtering joined the project. And + often, even those familiar with handling arguments with spaces may + not do so just because they aren't in the mindset of thinking about + everything that could possibly go wrong. + +* Non-ascii filenames can be silently removed despite being in a + desired directory. Keeping only wanted paths is often done using + pipelines like `git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`. + ls-files will only quote filenames if needed, so folks may not + notice that one of the files didn't match the regex (at least not + until it's much too late). Yes, someone who knows about + core.quotePath can avoid this (unless they have other special + characters like \t, \n, or "), and people who use ls-files -z with + something other than grep can avoid this, but that doesn't mean they + will. + +* Similarly, when moving files around, one can find that filenames + with non-ascii or special characters end up in a different + directory, one that includes a double quote character. (This is + technically the same issue as above with quoting, but perhaps an + interesting different way that it can and has manifested as a + problem.) + +* It's far too easy to accidentally mix up old and new history. It's + still possible with any tool, but git-filter-branch almost + invites it. If lucky, the only downside is users getting frustrated + that they don't know how to shrink their repo and remove the old + stuff. If unlucky, they merge old and new history and end up with + multiple "copies" of each commit, some of which have unwanted or + sensitive files and others which don't. This comes about in + multiple different ways: + + ** the default to only doing a partial history rewrite ('--all' is not + the default and few examples show it) + + ** the fact that there's no automatic post-run cleanup + + ** the fact that --tag-name-filter (when used to rename tags) doesn't + remove the old tags but just adds new ones with the new name + + ** the fact that little educational information is provided to inform + users of the ramifications of a rewrite and how to avoid mixing old + and new history. For example, this man page discusses how users + need to understand that they need to rebase their changes for all + their branches on top of new history (or delete and reclone), but + that's only one of multiple concerns to consider. See the + "DISCUSSION" section of the git filter-repo manual page for more + details. + +* Annotated tags can be accidentally converted to lightweight tags, + due to either of two issues: + + ** Someone can do a history rewrite, realize they messed up, restore + from the backups in refs/original/, and then redo their + git-filter-branch command. (The backup in refs/original/ is not a + real backup; it dereferences tags first.) + + ** Running git-filter-branch with either --tags or --all in your + <rev-list options>. In order to retain annotated tags as + annotated, you must use --tag-name-filter (and must not have + restored from refs/original/ in a previously botched rewrite). + +* Any commit messages that specify an encoding will become corrupted + by the rewrite; git-filter-branch ignores the encoding, takes the + original bytes, and feeds it to commit-tree without telling it the + proper encoding. (This happens whether or not --msg-filter is + used.) + +* Commit messages (even if they are all UTF-8) by default become + corrupted due to not being updated -- any references to other commit + hashes in commit messages will now refer to no-longer-extant + commits. + +* There are no facilities for helping users find what unwanted crud + they should delete, which means they are much more likely to have + incomplete or partial cleanups that sometimes result in confusion + and people wasting time trying to understand. (For example, folks + tend to just look for big files to delete instead of big directories + or extensions, and once they do so, then sometime later folks using + the new repository who are going through history will notice a build + artifact directory that has some files but not others, or a cache of + dependencies (node_modules or similar) which couldn't have ever been + functional since it's missing some files.) + +* If --prune-empty isn't specified, then the filtering process can + create hoards of confusing empty commits + +* If --prune-empty is specified, then intentionally placed empty + commits from before the filtering operation are also pruned instead + of just pruning commits that became empty due to filtering rules. + +* If --prune-empty is specified, sometimes empty commits are missed + and left around anyway (a somewhat rare bug, but it happens...) + +* A minor issue, but users who have a goal to update all names and + emails in a repository may be led to --env-filter which will only + update authors and committers, missing taggers. + +* If the user provides a --tag-name-filter that maps multiple tags to + the same name, no warning or error is provided; git-filter-branch + simply overwrites each tag in some undocumented pre-defined order + resulting in only one tag at the end. (A git-filter-branch + regression test requires this surprising behavior.) + +Also, the poor performance of git-filter-branch often leads to safety +issues: + +* Coming up with the correct shell snippet to do the filtering you + want is sometimes difficult unless you're just doing a trivial + modification such as deleting a couple files. Unfortunately, people + often learn if the snippet is right or wrong by trying it out, but + the rightness or wrongness can vary depending on special + circumstances (spaces in filenames, non-ascii filenames, funny + author names or emails, invalid timezones, presence of grafts or + replace objects, etc.), meaning they may have to wait a long time, + hit an error, then restart. The performance of git-filter-branch is + so bad that this cycle is painful, reducing the time available to + carefully re-check (to say nothing about what it does to the + patience of the person doing the rewrite even if they do technically + have more time available). This problem is extra compounded because + errors from broken filters may not be shown for a long time and/or + get lost in a sea of output. Even worse, broken filters often just + result in silent incorrect rewrites. + +* To top it all off, even when users finally find working commands, + they naturally want to share them. But they may be unaware that + their repo didn't have some special cases that someone else's does. + So, when someone else with a different repository runs the same + commands, they get hit by the problems above. Or, the user just + runs commands that really were vetted for special cases, but they + run it on a different OS where it doesn't work, as noted above. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt index bb1232a52c..6793d8fc05 100644 --- a/Documentation/git-fmt-merge-msg.txt +++ b/Documentation/git-fmt-merge-msg.txt @@ -9,7 +9,7 @@ git-fmt-merge-msg - Produce a merge commit message SYNOPSIS -------- [verse] -'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log] <$GIT_DIR/FETCH_HEAD +'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log] 'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log] -F <file> DESCRIPTION @@ -51,22 +51,24 @@ OPTIONS CONFIGURATION ------------- - -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. +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] diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index f2e08d11c1..2ea71c5f6c 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -10,6 +10,9 @@ 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 ----------- @@ -23,35 +26,41 @@ host language allowing their direct evaluation in that language. OPTIONS ------- -<count>:: +<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. -<key>:: +--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>:: - A string that interpolates `%(fieldname)` from the - object pointed at by a ref being shown. If `fieldname` +--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, the value for the field in the object - tag refers is used. When unspecified, defaults to + 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). -<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. +--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:: @@ -62,6 +71,29 @@ OPTIONS 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 ----------- @@ -76,49 +108,180 @@ 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. + 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` in the same way as - `refname` above. + 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. Finally, the optional GPG signature is `contents:signature`. +The message in a commit or a tag object is `contents`, from which +`contents:<part>` can be used to extract various parts out of: + +contents:size:: + The size in bytes of the commit or tag message. + +contents:subject:: + The first paragraph of the message, which typically is a + single line, is taken as the "subject" of the commit or the + tag message. + +contents:body:: + The remainder of the commit or the tag message that follows + the "subject". -For sorting purposes, fields with numeric values sort in numeric -order (`objectsize`, `authordate`, `committerdate`, `taggerdate`). +contents:signature:: + The optional GPG signature of the tag. + +contents:lines=N:: + The first `N` lines of the message. + +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 one of `:default`, `:relative`, `:short`, `:local`, -`:iso8601`, `:rfc2822` or `:raw` to the end of the fieldname; e.g. -`%(taggerdate:relative)`. +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 @@ -207,13 +370,39 @@ eval=`git for-each-ref --shell --format="$fmt" \ eval "$eval" ------------ -Author ------- -Written by Junio C Hamano <gitster@pobox.com>. -Documentation -------------- -Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. +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 --- diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 5c0a4ab2d6..0f81d0437b 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -14,13 +14,21 @@ SYNOPSIS [(--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>] + [--in-reply-to=<message id>] [--suffix=.<sfx>] [--ignore-if-in-upstream] - [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) <n>] + [--cover-from-description=<mode>] + [--rfc] [--subject-prefix=<subject prefix>] + [(--reroll-count|-v) <n>] [--to=<email>] [--cc=<email>] - [--[no-]cover-letter] [--quiet] [--notes[=<ref>]] + [--[no-]cover-letter] [--quiet] + [--[no-]encode-email-headers] + [--no-notes | --notes[=<ref>]] + [--interdiff=<previous>] + [--range-diff=<previous> [--creation-factor=<percent>]] + [--progress] [<common diff options>] [ <since> | <revision range> ] @@ -44,7 +52,7 @@ There are two ways to specify which commits to operate on. The first rule takes precedence in the case of a single <commit>. To apply the second rule, i.e., format everything since the beginning of -history up until <commit>, use the '\--root' option: `git format-patch +history up until <commit>, use the `--root` option: `git format-patch --root <commit>`. If you want to format only <commit> itself, you can do this with `git format-patch -1 <commit>`. @@ -56,7 +64,12 @@ 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. +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 .`. All directory +components will be created. 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 @@ -108,6 +121,7 @@ include::diff-options.txt[] --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, @@ -140,17 +154,17 @@ 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 +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`. +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:: +--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 + reply to the given <message id>, which avoids breaking threads to provide a new patch series. --ignore-if-in-upstream:: @@ -160,16 +174,41 @@ will want to ensure that threading is disabled for `git send-email`. patches being generated, and any patch that matches is ignored. ---subject-prefix=<Subject-Prefix>:: +--cover-from-description=<mode>:: + Controls which parts of the cover letter will be automatically + populated using the branch's description. ++ +If `<mode>` is `message` or `default`, the cover letter subject will be +populated with placeholder text. The body of the cover letter will be +populated with the branch's description. This is the default mode when +no configuration nor command line option is specified. ++ +If `<mode>` is `subject`, the first paragraph of the branch description will +populate the cover letter subject. The remainder of the description will +populate the body of the cover letter. ++ +If `<mode>` is `auto`, if the first paragraph of the branch description +is greater than 100 bytes, then the mode will be `message`, otherwise +`subject` will be used. ++ +If `<mode>` is `none`, both the cover letter subject and body will be +populated with placeholder text. + +--subject-prefix=<subject prefix>:: Instead of the standard '[PATCH]' prefix in the subject - line, instead use '[<Subject-Prefix>]'. This + 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>` pretended to them, and 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` @@ -212,10 +251,50 @@ feeding the result to `git send-email`. --[no-]cover-letter:: In addition to the patches, generate a cover letter file - containing the shortlog and the overall diffstat. You can + containing the branch description, shortlog and the overall diffstat. You can fill in a description in the file before sending it out. +--encode-email-headers:: +--no-encode-email-headers:: + Encode email headers that have non-ASCII characters with + "Q-encoding" (described in RFC 2047), instead of outputting the + headers verbatim. Defaults to the value of the + `format.encodeEmailHeaders` configuration variable. + +--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. + @@ -226,13 +305,19 @@ 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>:: +--[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 @@ -252,6 +337,17 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`. 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. + +--[no-]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. If <commit> is "auto", a base commit is + automatically chosen. The `--no-base` option overrides a + `format.useAutoBase` configuration. + --root:: Treat the revision argument as a <revision range>, even if it is just a single commit (that would normally be treated as a @@ -259,24 +355,30 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`. 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. +outputting more than one patch, add "To:" or "Cc:" headers, configure +attachments, change the patch output directory, and sign off patches +with configuration variables. ------------ [format] headers = "Organization: git-foo\n" - subjectprefix = CHANGE + subjectPrefix = CHANGE suffix = .txt numbered = auto to = <email> cc = <email> attach [ = mime-boundary-string ] - signoff = true - coverletter = auto + signOff = true + outputDirectory = <directory> + coverLetter = auto + coverFromDescription = auto ------------ @@ -359,8 +461,8 @@ One way to test if your MUA is set up correctly is: * Apply it: $ git fetch <project> master:test-apply - $ git checkout test-apply - $ git reset --hard + $ 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. @@ -442,9 +544,9 @@ 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`. + 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), @@ -507,19 +609,74 @@ This should help you to submit patches inline using KMail. 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: + 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: + origin branch: + ------------ $ git format-patch origin @@ -528,7 +685,7 @@ $ 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: + project: + ------------ $ git format-patch --root origin @@ -547,7 +704,7 @@ 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: + as e-mailable patches: + ------------ $ git format-patch -3 diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt index 25c431d3c5..d72d15be5b 100644 --- a/Documentation/git-fsck.txt +++ b/Documentation/git-fsck.txt @@ -11,7 +11,8 @@ SYNOPSIS [verse] 'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] [--[no-]full] [--strict] [--verbose] [--lost-found] - [--[no-]dangling] [--[no-]progress] [<object>*] + [--[no-]dangling] [--[no-]progress] [--connectivity-only] + [--[no-]name-objects] [<object>*] DESCRIPTION ----------- @@ -60,6 +61,19 @@ index file, all SHA-1 references in `refs` namespace, and all reflogs 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 @@ -77,6 +91,12 @@ index file, all SHA-1 references in `refs` namespace, and all reflogs a blob, the contents are written into the file, rather than its object name. +--name-objects:: + When displaying names of reachable objects, in addition to the + SHA-1 also display a name that describes *how* they are reachable, + compatible with linkgit:git-rev-parse[1], e.g. + `HEAD@{1234567890}~25^2:src/`. + --[no-]progress:: Progress status is reported on the standard error stream by default when it is attached to a terminal, unless @@ -84,13 +104,18 @@ index file, all SHA-1 references in `refs` namespace, and all reflogs 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 +`--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). @@ -98,6 +123,9 @@ 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 --------------------- @@ -125,9 +153,9 @@ dangling <type> <object>:: The <type> object <object>, is present in the database but never 'directly' used. A dangling commit could be a root node. -sha1 mismatch <object>:: - The database has an object who's sha1 doesn't match the - database value. +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 diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index e158a3b31f..0c114ad1ca 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -9,26 +9,27 @@ git-gc - Cleanup unnecessary files and optimize the local repository SYNOPSIS -------- [verse] -'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force] +'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack] DESCRIPTION ----------- Runs a number of housekeeping tasks within the current repository, such as compressing file revisions (to reduce disk space and increase -performance) and removing unreachable objects which may have been -created from prior invocations of 'git add'. - -Users are encouraged to run this task on a regular basis within -each repository to maintain good disk space utilization and good -operating performance. - -Some git commands may automatically run 'git gc'; see the `--auto` flag -below for details. If you know what you're doing and all you want is to -disable this behavior permanently without further considerations, just do: - ----------------------- -$ git config --global gc.auto 0 ----------------------- +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 ------- @@ -38,33 +39,28 @@ OPTIONS 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 - persistent, so this option only needs to be used occasionally; every - few hundred changesets or so. + 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. - Some git commands run `git gc --auto` after performing - operations that could create many loose objects. + -Housekeeping is required if there are too many loose objects or -too many packs in the repository. If the number of loose objects -exceeds the value of the `gc.auto` configuration variable, then -all loose objects are combined into a single pack using -`git repack -d -l`. Setting the value of `gc.auto` to 0 -disables automatic packing of loose objects. +See the `gc.auto` option in the "CONFIGURATION" section below for how +this heuristic works. + -If the number of packs exceeds the value of `gc.autopacklimit`, -then existing packs (except those marked with a `.keep` file) -are consolidated into a single pack by using the `-A` option of -'git repack'. Setting `gc.autopacklimit` to 0 disables -automatic consolidation of packs. +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=all prunes loose objects regardless of their age. - --prune is on by default. + --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. @@ -76,72 +72,75 @@ automatic consolidation of packs. Force `git gc` to run even if there may be another `git gc` instance running on this repository. -Configuration +--keep-largest-pack:: + All packs except the largest pack and those marked with a + `.keep` files are consolidated into a single pack. When this + option is used, `gc.bigPackThreshold` is ignored. + +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 optional configuration variable 'gc.reflogExpire' can be -set to indicate how long historical entries within each branch's -reflog should remain available in this repository. The setting is -expressed as a length of time, for example '90 days' or '3 months'. -It defaults to '90 days'. - -The optional configuration variable 'gc.reflogExpireUnreachable' -can be set to indicate how long historical reflog entries which -are not part of the current branch should remain available in -this repository. 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. This option defaults to '30 days'. - -The above two configuration variables can be given to a pattern. For -example, this sets non-default expiry values only to remote-tracking -branches: - ------------- -[gc "refs/remotes/*"] - reflogExpire = never - reflogexpireUnreachable = 3 days ------------- - -The optional configuration variable 'gc.rerereresolved' indicates -how long records of conflicted merge you resolved earlier are -kept. This defaults to 60 days. - -The optional configuration variable 'gc.rerereunresolved' indicates -how long records of conflicted merge you have not resolved are -kept. This defaults to 15 days. - -The optional configuration variable 'gc.packrefs' determines if -'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. -This defaults to true. - -The optional configuration variable 'gc.aggressiveWindow' controls how -much time is spent optimizing the delta compression of the objects in -the repository when the --aggressive option is specified. The larger -the value, the more time is spent optimizing the delta compression. See -the documentation for the --window' option in linkgit:git-repack[1] for -more details. This defaults to 250. - -The optional configuration variable 'gc.pruneExpire' controls how old -the unreferenced loose objects have to be before they are pruned. The -default is "2 weeks ago". - - -Notes ------ +The below documentation is the same as what's found in +linkgit:git-config[1]: + +include::config/gc.txt[] -'git gc' tries very hard to be safe about the garbage it collects. 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/, or reflogs (which may reference commits in branches -that were later amended or rewound). +NOTES +----- -If you are expecting some objects to be collected and they aren't, check -all of those locations and decide whether it makes sense in your case to -remove those references. +'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, notes saved +by 'git notes' under refs/notes/, 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 ----- diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt index 1e2a20dd26..ac44d85b0b 100644 --- a/Documentation/git-get-tar-commit-id.txt +++ b/Documentation/git-get-tar-commit-id.txt @@ -9,17 +9,19 @@ git-get-tar-commit-id - Extract commit ID from an archive created using git-arch SYNOPSIS -------- [verse] -'git get-tar-commit-id' < <tarfile> +'git get-tar-commit-id' DESCRIPTION ----------- -Acts as a filter, extracting the commit ID stored in archives created by -'git archive'. It reads only the first 1024 bytes of input, thus its -runtime is not influenced by the size of <tarfile> very much. + +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 <tarfile> had not been created +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. diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index f83733490f..a7f9bc99ea 100644 --- a/Documentation/git-grep.txt +++ b/Documentation/git-grep.txt @@ -13,18 +13,20 @@ SYNOPSIS [-v | --invert-match] [-h|-H] [--full-name] [-E | --extended-regexp] [-G | --basic-regexp] [-P | --perl-regexp] - [-F | --fixed-strings] [-n | --line-number] + [-F | --fixed-strings] [-n | --line-number] [--column] [-l | --files-with-matches] [-L | --files-without-match] [(-O | --open-files-in-pager) [<pager>]] [-z | --null] - [-c | --count] [--all-match] [-q | --quiet] - [--max-depth <depth>] + [ -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>...] @@ -40,19 +42,33 @@ CONFIGURATION ------------- grep.lineNumber:: - If set to true, enable '-n' option by default. + 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 + '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 + 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), Git will + use as many threads as the number of logical cores available. + +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 ------- @@ -72,10 +88,17 @@ OPTIONS mechanism. Only useful with `--untracked`. --exclude-standard:: - Do not pay attention to ignored files specified via the `.gitignore` + 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 is active 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. This option has no effect + if `--no-index` is given. + -a:: --text:: Process binary files as if they were text. @@ -97,11 +120,18 @@ OPTIONS --max-depth <depth>:: For each <pathspec> given on command line, descend at most <depth> - levels of directories. A negative value means no limit. + 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 @@ -135,8 +165,11 @@ OPTIONS -P:: --perl-regexp:: - Use Perl-compatible regexp for patterns. Requires libpcre to be - compiled in. + 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:: @@ -147,6 +180,10 @@ OPTIONS --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:: @@ -157,17 +194,27 @@ OPTIONS For better compatibility with 'git diff', `--name-only` is a synonym for `--files-with-matches`. --O [<pager>]:: ---open-files-in-pager [<pager>]:: +-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 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. + Use \0 as the delimiter for pathnames in the output, and print + them verbatim. Without this option, pathnames with "unusual" + characters are quoted as explained for the configuration + variable core.quotePath (see git-config(1)). + +-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:: @@ -221,8 +268,29 @@ OPTIONS 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. ++ +Passing the pattern via <file> allows for providing a search pattern +containing a \0. ++ +Not all pattern types support patterns containing \0. Git will error +out if a given pattern type can't support such a pattern. The +`--perl-regexp` pattern type when compiled against the PCRE v2 backend +has the widest support for these types of patterns. ++ +In versions of Git before 2.23.0 patterns containing \0 would be +silently considered fixed. This was never documented, there were also +odd and undocumented interactions between e.g. non-ASCII patterns +containing \0 and `--ignore-case`. ++ +In future versions we may learn to support patterns containing \0 for +more search backends, until then we'll die when the pattern type in +question doesn't support them. -e:: The next parameter is the pattern. This option has to be @@ -260,8 +328,11 @@ OPTIONS <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 +EXAMPLES -------- `git grep 'time_t' -- '*.[ch]'`:: @@ -276,6 +347,20 @@ Examples 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`. + +NOTES ON THREADS +---------------- + +The `--threads` option (and the grep.threads configuration) will be ignored when +`--open-files-in-pager` is used, forcing a single-threaded execution. + +When grepping the object store (with `--cached` or giving tree objects), running +with multiple threads might perform slower than single threaded if `--textconv` +is given and there're too many text conversions. So if you experience low +performance in this case, it might be desirable to use `--threads=1`. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt index 8144527ae0..c9d7e96214 100644 --- a/Documentation/git-gui.txt +++ b/Documentation/git-gui.txt @@ -35,7 +35,7 @@ blame:: browser:: Start a tree browser showing all files in the specified - commit (or 'HEAD' by default). Files selected through the + commit. Files selected through the browser are opened in the blame viewer. citool:: @@ -112,15 +112,9 @@ Other versions are distributed as part of the Git suite for the convenience of end users. -A 'git gui' development repository can be obtained from: +The official repository of the 'git gui' project can be found at: - 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/[]. + https://github.com/prati0100/git-gui.git/ GIT --- diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt index 02c1f12685..df9e2c58bd 100644 --- a/Documentation/git-hash-object.txt +++ b/Documentation/git-hash-object.txt @@ -9,8 +9,8 @@ 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] [--] <file>... -'git hash-object' [-t <type>] [-w] --stdin-paths [--no-filters] < <list-of-paths> +'git hash-object' [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin [--literally]] [--] <file>... +'git hash-object' [-t <type>] [-w] --stdin-paths [--no-filters] DESCRIPTION ----------- @@ -18,9 +18,7 @@ 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. -This is used by 'git cvsimport' to update the index -without modifying files in the work tree. When <type> is not -specified, it defaults to "blob". +When <type> is not specified, it defaults to "blob". OPTIONS ------- @@ -35,7 +33,8 @@ OPTIONS Read the object from standard input instead of from a file. --stdin-paths:: - Read file names from stdin instead of from the command-line. + 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 @@ -51,7 +50,13 @@ OPTIONS 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. + 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 --- diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt index b21e9d79be..69c0c5c34e 100644 --- a/Documentation/git-help.txt +++ b/Documentation/git-help.txt @@ -8,7 +8,7 @@ git-help - Display help information about Git SYNOPSIS -------- [verse] -'git help' [-a|--all] [-g|--guide] +'git help' [-a|--all [--[no-]verbose]] [-g|--guides] [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE] DESCRIPTION @@ -18,10 +18,10 @@ 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 +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 +If the option `--guides` 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 @@ -29,6 +29,10 @@ 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. @@ -43,6 +47,15 @@ OPTIONS 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 @@ -57,10 +70,10 @@ OPTIONS --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. + `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 +but the `man.viewer` configuration variable may be used to choose other display programs (see below). -w:: @@ -69,7 +82,7 @@ other display programs (see below). 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 +`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. @@ -80,9 +93,9 @@ CONFIGURATION VARIABLES help.format ~~~~~~~~~~~ -If no command line option is passed, the 'help.format' configuration +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 +variable; they make 'git help' behave as their corresponding command- line option: * "man" corresponds to '-m|--man', @@ -92,27 +105,27 @@ line option: 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 +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' config variable will be checked if the 'man' format -is chosen. The following values are currently supported: +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), + (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). + 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). +`man.<tool>.cmd` configuration entry (see below). -Multiple values may be given to the 'man.viewer' configuration +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. @@ -124,18 +137,18 @@ For example, this configuration: viewer = woman ------------------------------------------------ -will try to use konqueror first. But this may fail (for example if +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 +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 +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. @@ -143,9 +156,9 @@ available in PATH. man.<tool>.cmd ~~~~~~~~~~~~~~ -When the man viewer, specified by the 'man.viewer' configuration +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 +`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. @@ -153,13 +166,13 @@ page passed as arguments. Note about konqueror ~~~~~~~~~~~~~~~~~~~~ -When 'konqueror' is specified in the 'man.viewer' configuration +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. +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: @@ -176,7 +189,7 @@ Note about git config --global ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Note that all these configuration variables should probably be set -using the '--global' flag, for example like this: +using the `--global` flag, for example like this: ------------------------------------------------ $ git config --global help.format web diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt index e3bcdb50e3..558966aa83 100644 --- a/Documentation/git-http-backend.txt +++ b/Documentation/git-http-backend.txt @@ -21,7 +21,7 @@ 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). +`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 @@ -65,8 +65,8 @@ 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'. +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 @@ -162,7 +162,7 @@ ScriptAliasMatch ^/git/[^/]*(.*) /usr/libexec/git-core/git-http-backend/storage. 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 + 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: + @@ -191,7 +191,7 @@ ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/ ---------------------------------------------------------------- Lighttpd:: - Ensure that `mod_cgi`, `mod_alias, `mod_auth`, `mod_setenv` are + 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: + @@ -241,7 +241,7 @@ $HTTP["url"] =~ "^/git/private" { ENVIRONMENT ----------- -'git http-backend' relies upon the CGI environment variables set +'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) @@ -251,26 +251,27 @@ by the invoking web server, including: * QUERY_STRING * REQUEST_METHOD -The GIT_HTTP_EXPORT_ALL environmental variable may be passed to +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 +All `CGI` environment variables are available to each of the hooks invoked by the 'git-receive-pack'. -Author ------- -Written by Shawn O. Pearce <spearce@spearce.org>. - -Documentation --------------- -Documentation by Shawn O. Pearce <spearce@spearce.org>. - GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt index 21a33d2c41..4deb4893f5 100644 --- a/Documentation/git-http-fetch.txt +++ b/Documentation/git-http-fetch.txt @@ -9,14 +9,15 @@ 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> +'git http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin | --packfile=<hash> | <commit>] <url> DESCRIPTION ----------- Downloads a remote Git repository via HTTP. -*NOTE*: use of this command without -a is deprecated. The -a -behaviour will become the default in a future release. +This command always gets all objects. Historically, there were three options +`-a`, `-c` and `-t` for choosing which objects to download. They are now +silently ignored. OPTIONS ------- @@ -24,12 +25,8 @@ commit-id:: Either the hash or the filename under [URL]/refs/ to pull. --c:: - Get the commit objects. --t:: - Get trees associated with the commit objects. --a:: - Get all the objects. +-a, -c, -t:: + These options are ignored for historical reasons. -v:: Report what is downloaded. @@ -43,6 +40,13 @@ commit-id:: <commit-id>['\t'<filename-as-in--w>] +--packfile=<hash>:: + Instead of a commit id on the command line (which is not expected in + this case), 'git http-fetch' fetches the packfile directly at the given + URL and uses index-pack to generate corresponding .idx and .keep files. + The hash is used to determine the name of the temporary file and is + arbitrary. The output of index-pack is printed to stdout. + --recover:: Verify that everything reachable from target is fetched. Used after an earlier fetch is interrupted. diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt index 2e67362bd4..ea03a4eeb0 100644 --- a/Documentation/git-http-push.txt +++ b/Documentation/git-http-push.txt @@ -55,7 +55,7 @@ OPTIONS The remote refs to update. -Specifying the Refs +SPECIFYING THE REFS ------------------- A '<ref>' specification can be either a single pattern, or a pair @@ -81,13 +81,13 @@ destination side. 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 +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. +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. diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index 875d2831a5..65b53fcc47 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -9,7 +9,7 @@ git-imap-send - Send a collection of patches from stdin to an IMAP folder SYNOPSIS -------- [verse] -'git imap-send' +'git imap-send' [-v] [-q] [--[no-]curl] DESCRIPTION @@ -26,6 +26,28 @@ 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 ------------- @@ -35,48 +57,7 @@ to appropriate values. Variables ~~~~~~~~~ -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 to use imap-send. - -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 to use imap-send. - -imap.host:: - A URL identifying the server. Use a `imap://` prefix for non-secure - connections and a `imaps://` prefix for secure connections. - Ignored when imap.tunnel is set, but required to use imap-send - 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. - Current supported method is 'CRAM-MD5' only. +include::config/imap.txt[] Examples ~~~~~~~~ @@ -97,7 +78,7 @@ Using direct mode: host = imap://imap.example.com user = bob pass = p4ssw0rd -.......................... +......................... Using direct mode with SSL: @@ -109,11 +90,11 @@ Using direct mode with SSL: pass = p4ssw0rd port = 123 sslverify = false -.......................... +......................... -EXAMPLE -------- +EXAMPLES +-------- To submit patches using GMail's IMAP interface, first, edit your ~/.gitconfig to specify your account settings: diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt index b89a5517e5..ac74d058e0 100644 --- a/Documentation/git-index-pack.txt +++ b/Documentation/git-index-pack.txt @@ -77,6 +77,9 @@ OPTIONS --check-self-contained-and-connected:: Die if the pack contains broken links. For internal use only. +--fsck-objects:: + Die if the pack contains broken objects. For internal use only. + --threads=<n>:: Specifies the number of threads to spawn when resolving deltas. This requires that index-pack be compiled with @@ -87,9 +90,19 @@ OPTIONS Specifying 0 will cause Git to auto-detect the number of CPU's and use maximum 3 threads. +--max-input-size=<size>:: + Die, if the pack is larger than <size>. -Note ----- +--object-format=<hash-algorithm>:: + Specify the given object format (hash algorithm) for the pack. The valid + values are 'sha1' and (if enabled) 'sha256'. The default is the algorithm for + the current repository (set by `extensions.objectFormat`), or 'sha1' if no + value is set or outside a repository. ++ +This option cannot be used with --stdin. + +NOTES +----- Once the index has been created, the hash that goes into the name of the pack/idx file is printed to stdout. If --stdin was diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index afd721e3a9..ddfe265da5 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -10,7 +10,8 @@ SYNOPSIS -------- [verse] 'git init' [-q | --quiet] [--bare] [--template=<template_directory>] - [--separate-git-dir <git dir>] + [--separate-git-dir <git dir>] [--object-format=<format>] + [-b <branch-name> | --initial-branch=<branch-name>] [--shared[=<permissions>]] [directory] @@ -38,18 +39,21 @@ 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. +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 +Create a bare repository. If `GIT_DIR` environment is not set, it is set to the current working directory. +--object-format=<format>:: + +Specify the given object format (hash algorithm) for the repository. The valid +values are 'sha1' and (if enabled) 'sha256'. 'sha1' is the default. + --template=<template_directory>:: Specify the directory from which templates will be used. (See the "TEMPLATE @@ -57,12 +61,18 @@ DIRECTORY" section below.) --separate-git-dir=<git dir>:: -Instead of initializing the repository where it is supposed to be, -place a filesytem-agnostic Git symbolic link there, pointing to the -specified path, and initialize a Git repository at the path. The -result is Git repository can be separated from working tree. If this -is reinitialization, the repository will be moved to the specified -path. +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. + +-b <branch-name:: +--initial-branch=<branch-name>:: + +Use the specified name for the initial branch in the newly created repository. +If not specified, fall back to the default name: `master`. --shared[=(false|true|umask|group|all|world|everybody|0xxx)]:: @@ -72,60 +82,68 @@ 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'):: - - 'umask' (or 'false'): Use permissions reported by umask(2). The default, - when `--shared` is not specified. +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. +'group' (or 'true'):: - - 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository - readable by all users. +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. - - '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. +'all' (or 'world' or 'everybody'):: -By default, the configuration flag receive.denyNonFastForwards is enabled -in shared repositories, so that you cannot force a non fast-forwarding push -into it. +Same as 'group', but make the repository readable by all users. -If you name a (possibly non-existent) directory at the end of the command -line, the command is run inside the directory (possibly after creating it). +'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 ------------------ -The template directory contains files and directories that will be copied to -the `$GIT_DIR` after it is created. +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 template directory used will (in order): + - the contents of the `$GIT_TEMPLATE_DIR` environment variable; - - The argument given with the `--template` option. + - the `init.templateDir` configuration variable; or - - The contents of the `$GIT_TEMPLATE_DIR` environment variable. + - the default template directory: `/usr/share/git-core/templates`. - - The `init.templatedir` configuration variable. +The default template directory includes some directory structure, suggested +"exclude patterns" (see linkgit:gitignore[5]), and sample hook files. - - The default template directory: `/usr/share/git-core/templates`. +The sample hooks are all disabled by default. To enable one of the +sample hooks rename it by removing its `.sample` suffix. -The default template directory includes some directory structure, some -suggested "exclude patterns", and copies of sample "hook" files. -The suggested patterns and hook files are all modifiable and extensible. +See linkgit:githooks[5] for more general info on hook execution. EXAMPLES -------- @@ -136,10 +154,12 @@ 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> prepare /path/to/my/codebase/.git directory -<2> add all existing file to the index +<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 --- diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt index f3eef510f2..a54fe4401b 100644 --- a/Documentation/git-instaweb.txt +++ b/Documentation/git-instaweb.txt @@ -29,7 +29,8 @@ OPTIONS 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 and webrick are supported. + Currently apache2, lighttpd, mongoose, plackup, python and + webrick are supported. (Default: lighttpd) -m:: @@ -76,12 +77,12 @@ You may specify configuration in your .git/config httpd = apache2 -f port = 4321 browser = konqueror - modulepath = /usr/lib/apache2/modules + 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 +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 diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt new file mode 100644 index 0000000000..96ec6499f0 --- /dev/null +++ b/Documentation/git-interpret-trailers.txt @@ -0,0 +1,390 @@ +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/Documentation/git-log.txt b/Documentation/git-log.txt index 34097efea7..3fd26d5212 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -9,15 +9,18 @@ git-log - Show commit logs SYNOPSIS -------- [verse] -'git log' [<options>] [<revision range>] [[\--] <path>...] +'git log' [<options>] [<revision range>] [[--] <path>...] DESCRIPTION ----------- Shows the commit logs. -The command takes options applicable to the 'git rev-list' +:git-log: 1 +include::rev-list-description.txt[] + +The command takes options applicable to the linkgit:git-rev-list[1] command to control what is shown and how, and options applicable to -the 'git diff-*' commands to control how the changes +the linkgit:git-diff[1] command to control how the changes each commit introduces are shown. @@ -29,48 +32,63 @@ OPTIONS (works only for a single file). --no-decorate:: ---decorate[=short|full|no]:: +--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. The default option - is 'short'. + 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`. The + `log.excludeDecoration` config option allows excluding refs from + the decorations, but an explicit `--decorate-refs` pattern will + override a match in `log.excludeDecoration`. --source:: Print out the ref name given on the command line by which each commit was reached. ---use-mailmap:: +--[no-]mailmap:: +--[no-]use-mailmap:: Use mailmap file to map author and committer names and email - to canonical real names and email addresses. See + 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 + 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. +produced by `--stat`, etc. --log-size:: - Before the log message print out its size in bytes. Intended - mainly for porcelain tools consumption. If Git is unable to - produce a valid value size is set to zero. - Note that only message is considered, if also a diff is shown - its size is not included. + 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 :<regex>:<file>:: - +-L :<funcname>:<file>:: Trace the evolution of the line range given by "<start>,<end>" - (or the funcname regex <regex>) within the <file>. You may + (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. + give zero or one positive revision arguments, and + <start> and <end> (or <funcname>) must exist in the starting revision. + You can specify this option more than once. Implies `--patch`. + Patch output can be suppressed using `--no-patch`, but other diff formats + (namely `--raw`, `--numstat`, `--shortstat`, `--dirstat`, `--summary`, + `--name-only`, `--name-status`, `--check`) are not currently implemented. + include::line-range-format.txt[] @@ -80,16 +98,16 @@ include::line-range-format.txt[] 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" + ways to spell <revision range>, see the 'Specifying Ranges' section of linkgit:gitrevisions[7]. -[\--] <path>...:: +[--] <path>...:: Show only commits that are enough to explain how the files - that match the specified paths came to be. See "History - Simplification" below for details and other simplification + that match the specified paths came to be. See 'History + Simplification' below for details and other simplification modes. + -Paths may need to be prefixed with "\-- " to separate them from +Paths may need to be prefixed with `--` to separate them from options or the revision range, when confusion arises. include::rev-list-options.txt[] @@ -113,12 +131,12 @@ EXAMPLES `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 + 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 + The `--` is necessary to avoid confusion with the *branch* named 'gitk' `git log --name-status release..test`:: @@ -129,7 +147,7 @@ EXAMPLES `git log --follow builtin/rev-list.c`:: - Shows the commits that changed builtin/rev-list.c, including + Shows the commits that changed `builtin/rev-list.c`, including those commits that occurred before the file was given its present name. @@ -147,17 +165,18 @@ EXAMPLES `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 + ``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 + 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 @@ -172,32 +191,46 @@ 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". + 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, UTF-8 + 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`. - -log.showroot:: - If `false`, 'git log' and related commands will not treat the ++ +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 + 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 @@ -205,7 +238,7 @@ 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, +overridden by the `GIT_NOTES_DISPLAY_REF` environment variable, and overridden by the `--notes=<ref>` option. GIT diff --git a/Documentation/git-lost-found.txt b/Documentation/git-lost-found.txt deleted file mode 100644 index d54932889f..0000000000 --- a/Documentation/git-lost-found.txt +++ /dev/null @@ -1,74 +0,0 @@ -git-lost-found(1) -================= - -NAME ----- -git-lost-found - Recover lost refs that luckily have not yet been pruned - -SYNOPSIS --------- -[verse] -'git lost-found' - -DESCRIPTION ------------ - -*NOTE*: this command is deprecated. Use linkgit:git-fsck[1] with -the option '--lost-found' instead. - -Finds dangling commits and tags from the object database, and -creates refs to them in the .git/lost-found/ directory. Commits and -tags that dereference to commits are stored in .git/lost-found/commit, -and other objects are stored in .git/lost-found/other. - - -OUTPUT ------- -Prints to standard output the object names and one-line descriptions -of any commits or tags found. - -EXAMPLE -------- - -Suppose you run 'git tag -f' and mistype the tag to overwrite. -The ref to your tag is overwritten, but until you run 'git -prune', the tag itself is still there. - ------------- -$ git lost-found -[1ef2b196d909eed523d4f3c9bf54b78cdd6843c6] GIT 0.99.9c -... ------------- - -Also you can use gitk to browse how any tags found relate to each -other. - ------------- -$ gitk $(cd .git/lost-found/commit && echo ??*) ------------- - -After making sure you know which the object is the tag you are looking -for, you can reconnect it to your regular `refs` hierarchy by using -the `update-ref` command. - ------------- -$ git cat-file -t 1ef2b196 -tag -$ git cat-file tag 1ef2b196 -object fa41bbce8e38c67a218415de6cfa510c7e50032a -type commit -tag v0.99.9c -tagger Junio C Hamano <junkio@cox.net> 1131059594 -0800 - -GIT 0.99.9c - -This contains the following changes from the "master" branch, since -... -$ git update-ref refs/tags/not-lost-anymore 1ef2b196 -$ git rev-parse not-lost-anymore -1ef2b196d909eed523d4f3c9bf54b78cdd6843c6 ------------- - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt index c0856a6e0a..3cb2ebb438 100644 --- a/Documentation/git-ls-files.txt +++ b/Documentation/git-ls-files.txt @@ -9,15 +9,17 @@ git-ls-files - Show information about files in the index and the working tree SYNOPSIS -------- [verse] -'git ls-files' [-z] [-t] [-v] +'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] [--abbrev] [--] [<file>...] + [--full-name] [--recurse-submodules] + [--abbrev] [--] [<file>...] DESCRIPTION ----------- @@ -51,11 +53,12 @@ OPTIONS Show only ignored files in the output. When showing files in the index, print only those matched by an exclude pattern. When showing "other" files, show only those matched by an exclude - pattern. + pattern. Standard ignore rules are not automatically activated, + therefore at least one of the `--exclude*` options is required. -s:: --stage:: - Show staged contents' object name, mode bits and stage number in the output. + 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 @@ -75,7 +78,8 @@ OPTIONS succeed. -z:: - \0 line termination on output. + \0 line termination on output and do not quote filenames. + See OUTPUT below for more information. -x <pattern>:: --exclude=<pattern>:: @@ -114,6 +118,7 @@ OPTIONS 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: @@ -124,18 +129,28 @@ a space) at the start of each line: 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 active 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. @@ -147,6 +162,23 @@ a space) at the start of each line: 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. @@ -154,13 +186,16 @@ a space) at the start of each line: Files to show. If no files are given all files which match the other specified criteria are shown. -Output +OUTPUT ------ -'git ls-files' just outputs the filenames unless '--stage' is specified in +'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. @@ -170,12 +205,13 @@ the index records up to three such pairs; one from tree O in stage 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) -When `-z` option is not used, TAB, LF, and backslash characters -in pathnames are represented as `\t`, `\n`, and `\\`, -respectively. +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 +EXCLUDE PATTERNS ---------------- 'git ls-files' can use a list of "exclude patterns" when @@ -185,15 +221,15 @@ specifies the format of exclude patterns. These exclude patterns come from these places, in order: - 1. The command line flag --exclude=<pattern> specifies a + 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 + 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 + 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 diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 2e22915eb8..492e573856 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -9,8 +9,9 @@ git-ls-remote - List references in a remote repository SYNOPSIS -------- [verse] -'git ls-remote' [--heads] [--tags] [-u <exec> | --upload-pack <exec>] - [--exit-code] <repository> [<refs>...] +'git ls-remote' [--heads] [--tags] [--refs] [--upload-pack=<exec>] + [-q | --quiet] [--exit-code] [--get-url] [--sort=<key>] + [--symref] [<repository> [<refs>...]] DESCRIPTION ----------- @@ -27,9 +28,17 @@ OPTIONS 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. + displayed. Note that `git ls-remote -h` used without + anything else on the command line gives help, consistent + with other git subcommands. + +--refs:: + Do not show peeled tags or pseudorefs like `HEAD` in the output. + +-q:: +--quiet:: + Do not print remote URL to stderr. --u <exec>:: --upload-pack=<exec>:: Specify the full path of 'git-upload-pack' on the remote host. This allows listing references from repositories accessed via @@ -47,6 +56,30 @@ OPTIONS "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 @@ -61,21 +94,27 @@ OPTIONS 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 +---- +$ 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 seen rc +5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master +c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/seen +$ 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 --- diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt index 16e87fd6dd..a7515714da 100644 --- a/Documentation/git-ls-tree.txt +++ b/Documentation/git-ls-tree.txt @@ -20,16 +20,16 @@ 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 + 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 + `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. + 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. @@ -46,14 +46,15 @@ OPTIONS -t:: Show tree entries even when going to recurse them. Has no effect - if '-r' was not passed. '-d' implies '-t'. + if `-r` was not passed. `-d` implies `-t`. -l:: --long:: Show object size of blob (file) entries. -z:: - \0 line termination on output. + \0 line termination on output and do not quote filenames. + See OUTPUT FORMAT below for more information. --name-only:: --name-status:: @@ -82,8 +83,6 @@ Output Format ------------- <mode> SP <type> SP <object> TAB <file> -Unless the `-z` option is used, TAB, LF, and backslash characters -in pathnames are represented as `\t`, `\n`, and `\\`, respectively. This output format is compatible with what `--index-info --stdin` of 'git update-index' expects. @@ -95,6 +94,11 @@ 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/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt index 164a3c6ede..3bbc731f67 100644 --- a/Documentation/git-mailinfo.txt +++ b/Documentation/git-mailinfo.txt @@ -66,6 +66,11 @@ conversion, even with this flag. -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 @@ -80,7 +85,7 @@ 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 enabled by default with the configuration option mailinfo.scissors. +This can be enabled by default with the configuration option mailinfo.scissors. --no-scissors:: Ignore scissors lines. Useful for overriding mailinfo.scissors settings. diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt index 4d1b871d96..e3b2a88c4b 100644 --- a/Documentation/git-mailsplit.txt +++ b/Documentation/git-mailsplit.txt @@ -8,7 +8,8 @@ git-mailsplit - Simple UNIX mbox splitter program SYNOPSIS -------- [verse] -'git mailsplit' [-b] [-f<nn>] [-d<prec>] [--keep-cr] -o<directory> [--] [(<mbox>|<Maildir>)...] +'git mailsplit' [-b] [-f<nn>] [-d<prec>] [--keep-cr] [--mboxrd] + -o<directory> [--] [(<mbox>|<Maildir>)...] DESCRIPTION ----------- @@ -47,6 +48,10 @@ OPTIONS --keep-cr:: Do not remove `\r` from lines ending with `\r\n`. +--mboxrd:: + Input is of the "mboxrd" format and "^>+From " line escaping is + reversed. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt index 87842e33f8..2d944e0851 100644 --- a/Documentation/git-merge-base.txt +++ b/Documentation/git-merge-base.txt @@ -13,6 +13,7 @@ SYNOPSIS 'git merge-base' [-a|--all] --octopus <commit>... 'git merge-base' --is-ancestor <commit> <commit> 'git merge-base' --independent <commit>... +'git merge-base' --fork-point <ref> [<commit>] DESCRIPTION ----------- @@ -24,8 +25,8 @@ that does not have any better common ancestor is a 'best common ancestor', i.e. a 'merge base'. Note that there can be more than one merge base for a pair of commits. -OPERATION MODE --------------- +OPERATION MODES +--------------- As the most common special case, specifying only two commits on the command line means computing the merge base between the given two commits. @@ -56,6 +57,14 @@ from linkgit:git-show-branch[1] when used with the `--merge-base` option. and exit with status 0 if true, or with status 1 if not. Errors are signaled by a non-zero status that is not 1. +--fork-point:: + Find the point at which a branch (or any history that leads + to <commit>) forked from another branch (or any reference) + <ref>. This does not just look for the common ancestor of + the two commits, but also takes into account the reflog of + <ref> to see if the history leading to <commit> forked from + an earlier incarnation of the branch <ref> (see discussion + on this mode below). OPTIONS ------- @@ -71,9 +80,11 @@ 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 +.... + o---o---o---B + / +---o---1---o---o---o---A +.... the merge base between 'A' and 'B' is '1'. @@ -81,21 +92,25 @@ 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 +.... + 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 +.... + 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, @@ -107,11 +122,13 @@ the best common ancestor of all commits. When the history involves criss-cross merges, there can be more than one 'best' common ancestor for two commits. For example, with this topology: - ---1---o---A - \ / - X - / \ - ---2---o---o---B +.... +---1---o---A + \ / + X + / \ +---2---o---o---B +.... both '1' and '2' are merge-bases of A and B. Neither one is better than the other (both are 'best' merge bases). When the `--all` option is not given, @@ -122,21 +139,102 @@ 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 +.... +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 +.... +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 -------- diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt index d2fc12ec77..f856032613 100644 --- a/Documentation/git-merge-file.txt +++ b/Documentation/git-merge-file.txt @@ -41,7 +41,8 @@ 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. If the merge was clean, the exit value is 0. +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 diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt index 02676fb391..2ab84a91e5 100644 --- a/Documentation/git-merge-index.txt +++ b/Documentation/git-merge-index.txt @@ -54,20 +54,24 @@ original is first. But the argument order to the 3-way merge program 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 +---- +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 +---- +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 diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 439545926e..3819fadac1 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -10,10 +10,10 @@ SYNOPSIS -------- [verse] 'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] - [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] - [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...] -'git merge' <msg> HEAD <commit>... -'git merge' --abort + [--no-verify] [-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 ----------- @@ -44,11 +44,7 @@ a log message from the user describing the changes. D---E---F---G---H master ------------ -The second syntax (<msg> `HEAD` <commit>...) is supported for -historical reasons. Do not use it from the command line or in -new scripts. It is the same as `git merge -m <msg> <commit>...`. - -The third syntax ("`git merge --abort`") can only be run after the +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 @@ -60,15 +56,13 @@ reconstruct the original (pre-merge) changes. Therefore: discouraged: while possible, it may leave you in a state that is hard to back out of in the case of a conflict. +The third syntax ("`git merge --continue`") can only be run after the +merge has resulted in conflicts. OPTIONS ------- include::merge-options.txt[] --S[<keyid>]:: ---gpg-sign[=<keyid>]:: - GPG-sign the resulting merge commit. - -m <msg>:: Set the commit message to be used for the merge commit (in case one is created). @@ -78,15 +72,30 @@ 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. +invocations. The automated message can include the branch description. ---[no-]rerere-autoupdate:: +-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. + try to reconstruct the pre-merge state. If an autostash entry is + present, apply it to the worktree. + If there were uncommitted worktree changes present when the merge started, 'git merge --abort' will in some cases be unable to @@ -94,17 +103,33 @@ 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. +`MERGE_HEAD` is present unless `MERGE_AUTOSTASH` is also present in +which case 'git merge --abort' applies the stash entry to the worktree +whereas 'git reset --merge' will save the stashed changes in the stash +list. + +--quit:: + Forget about the current merge in progress. Leave the index + and the working tree as-is. If `MERGE_AUTOSTASH` is present, the + stash entry will be saved to the stash list. + +--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, and if `merge.defaultToUpstream` -configuration variable is set, merge the remote-tracking branches -that the current branch is configured to use as its upstream. +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 @@ -119,12 +144,12 @@ 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. (One -exception is when the changed index entries are in the state that -would result from the merge already.) +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." +will exit early with the message "Already up to date." FAST-FORWARD MERGE ------------------ @@ -233,7 +258,7 @@ 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" +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: @@ -271,7 +296,10 @@ After seeing a conflict, you can do two things: * 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' to seal the deal. + '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: @@ -328,9 +356,9 @@ include::merge-strategies.txt[] CONFIGURATION ------------- -include::merge-config.txt[] +include::config/merge.txt[] -branch.<name>.mergeoptions:: +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. diff --git a/Documentation/git-mergetool--lib.txt b/Documentation/git-mergetool--lib.txt index 055550b2bc..4da9d24096 100644 --- a/Documentation/git-mergetool--lib.txt +++ b/Documentation/git-mergetool--lib.txt @@ -28,7 +28,9 @@ to define the operation mode for the functions listed below. FUNCTIONS --------- get_merge_tool:: - returns a 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. diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt index 07137f252b..6b14702e78 100644 --- a/Documentation/git-mergetool.txt +++ b/Documentation/git-mergetool.txt @@ -71,11 +71,33 @@ success of the resolution after the custom tool has exited. --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. - This is the default behaviour; the option is provided to - override any configuration settings. + 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 --------------- diff --git a/Documentation/git-mktag.txt b/Documentation/git-mktag.txt index 3ca158b05e..fa6a756123 100644 --- a/Documentation/git-mktag.txt +++ b/Documentation/git-mktag.txt @@ -9,7 +9,7 @@ git-mktag - Creates a tag object SYNOPSIS -------- [verse] -'git mktag' < signature_file +'git mktag' DESCRIPTION ----------- @@ -20,7 +20,8 @@ The output is the new tag's <object> identifier. Tag Format ---------- -A tag signature file has a very simple fixed format: four lines of +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> diff --git a/Documentation/git-mktree.txt b/Documentation/git-mktree.txt index 5c6ebdfad9..27fe2b32e1 100644 --- a/Documentation/git-mktree.txt +++ b/Documentation/git-mktree.txt @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION ----------- Reads standard input in non-recursive `ls-tree` output format, and creates -a tree object. The order of the tree entries is normalised by mktree so +a tree object. The order of the tree entries is normalized by mktree so pre-sorting the input is not required. The object name of the tree object built is written to the standard output. @@ -32,7 +32,7 @@ OPTIONS --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 + optional. Note - if the `-z` option is used, lines are terminated with NUL. GIT diff --git a/Documentation/git-multi-pack-index.txt b/Documentation/git-multi-pack-index.txt new file mode 100644 index 0000000000..0c6619493c --- /dev/null +++ b/Documentation/git-multi-pack-index.txt @@ -0,0 +1,95 @@ +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>] [--[no-]progress] <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. + +--[no-]progress:: + Turn progress on/off explicitly. If neither is specified, progress is + shown if standard error is connected to a terminal. + +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. ++ +If `repack.packKeptObjects` is `false`, then any pack-files with an +associated `.keep` file will not be selected for the batch to repack. + + +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/Documentation/git-mv.txt b/Documentation/git-mv.txt index b1f79881ef..79449bf98f 100644 --- a/Documentation/git-mv.txt +++ b/Documentation/git-mv.txt @@ -32,10 +32,10 @@ OPTIONS --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 + 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. + file unless `-f` is given. -n:: --dry-run:: Do nothing; only show what would happen @@ -52,6 +52,18 @@ core.worktree setting to make the submodule work in the new location. It also will attempt to update the submodule.<name>.path setting in the linkgit:gitmodules[5] file and stage that file (unless -n is used). +BUGS +---- +Each time a superproject update moves a populated submodule (e.g. when +switching between commits before and after the move) a stale submodule +checkout will remain in the old location and an empty directory will +appear in the new location. To populate the submodule again in the new +location the user will have to run "git submodule update" +afterwards. Removing the old directory is only safe when it uses a +gitfile, as otherwise the history of the submodule will be deleted +too. Both steps will be obsolete when recursive submodule update has +been implemented. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt index ca28fb8e2a..5cb0eb0855 100644 --- a/Documentation/git-name-rev.txt +++ b/Documentation/git-name-rev.txt @@ -26,7 +26,18 @@ OPTIONS --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. + 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 @@ -50,8 +61,8 @@ OPTIONS --always:: Show uniquely abbreviated commit object as fallback. -EXAMPLE -------- +EXAMPLES +-------- Given a commit, find out where it is relative to the local refs. Say somebody wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a. diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index 46ef0466be..ced2e8280e 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -9,16 +9,16 @@ SYNOPSIS -------- [verse] 'git notes' [list [<object>]] -'git notes' add [-f] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] -'git notes' copy [-f] ( --stdin | <from-object> <to-object> ) -'git notes' append [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] -'git notes' edit [<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 [-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' prune [-n] [-v] 'git notes' get-ref @@ -68,8 +68,8 @@ add:: 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 + Copy the notes for the first object onto the second object (defaults to + HEAD). 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>` @@ -101,7 +101,7 @@ merge:: any) into the current notes ref (called "local"). + If conflicts arise and a strategy for automatically resolving -conflicting notes (see the -s/--strategy option) is not given, +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. @@ -146,26 +146,32 @@ OPTIONS -C <object>:: --reuse-message=<object>:: - Take the given blob object (for example, another note) as the + 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 + 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 - is taken to be in `refs/notes/` if it is not qualified. + `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 from the standard + 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). @@ -179,6 +185,7 @@ OPTIONS 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. @@ -192,7 +199,7 @@ OPTIONS .git/NOTES_MERGE_REF symref is updated to the resulting commit. --abort:: - Abort/reset a in-progress 'git notes merge', i.e. a notes merge + 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. @@ -243,6 +250,9 @@ 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). @@ -287,7 +297,7 @@ arbitrary files using 'git hash-object': ------------ $ cc *.c $ blob=$(git hash-object -w a.out) -$ git notes --ref=built add -C "$blob" HEAD +$ git notes --ref=built add --allow-empty -C "$blob" HEAD ------------ (You cannot simply use `git notes --ref=built add -F a.out HEAD` @@ -306,13 +316,27 @@ core.notesRef:: 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 + `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. + `GIT_NOTES_DISPLAY_REF` environment variable. See linkgit:git-log[1]. notes.rewrite.<command>:: @@ -321,13 +345,14 @@ notes.rewrite.<command>:: 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' +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`, and `ignore`. Defaults to `concatenate`. + `concatenate`, `cat_sort_uniq`, or `ignore`. Defaults to + `concatenate`. + This setting can be overridden with the `GIT_NOTES_REWRITE_MODE` environment variable. @@ -341,33 +366,33 @@ notes.rewriteRef:: 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. +Can be overridden with the `GIT_NOTES_REWRITE_REF` environment variable. ENVIRONMENT ----------- -'GIT_NOTES_REF':: +`GIT_NOTES_REF`:: Which ref to manipulate notes from, instead of `refs/notes/commits`. This overrides the `core.notesRef` setting. -'GIT_NOTES_DISPLAY_REF':: +`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 + `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':: +`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`, and `ignore`. + Must be one of `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`. This overrides the `core.rewriteMode` setting. -'GIT_NOTES_REWRITE_REF':: +`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. @@ -375,16 +400,6 @@ does not match any refs is silently ignored. If not set in the environment, the list of notes to copy depends on the `notes.rewrite.<command>` and `notes.rewriteRef` settings. - -Author ------- -Written by Johannes Schindelin <johannes.schindelin@gmx.de> and -Johan Herland <johan@herland.net> - -Documentation -------------- -Documentation by Johannes Schindelin and Johan Herland - GIT --- -Part of the linkgit:git[7] suite +Part of the linkgit:git[1] suite diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index 8cba16d67f..dab9609013 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -29,8 +29,8 @@ Submit Git changes back to p4 using 'git p4 submit'. The command the updated p4 remote branch. -EXAMPLE -------- +EXAMPLES +-------- * Clone a repository: + ------------ @@ -71,12 +71,12 @@ $ git p4 clone //depot/path/project ------------ This: -1. Creates an empty Git repository in a subdirectory called 'project'. +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'. +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. +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: @@ -104,7 +104,7 @@ $ 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 +`--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 @@ -114,7 +114,7 @@ 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' +into the right branch. This can be overridden with the `--branch` option to specify just a single branch to update. @@ -134,7 +134,7 @@ 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 +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. @@ -149,14 +149,51 @@ 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. +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 +`--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 ------- @@ -166,9 +203,10 @@ General options All commands except clone accept these options. --git-dir <dir>:: - Set the 'GIT_DIR' environment variable. See linkgit:git[1]. + Set the `GIT_DIR` environment variable. See linkgit:git[1]. ---verbose, -v:: +-v:: +--verbose:: Provide more progress information. Sync options @@ -220,26 +258,40 @@ Git repository: 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 + sync operations must specify `--import-local` as well so that they can find the p4 branches in refs/heads. --max-changes <n>:: - Limit the number of imported changes to 'n'. Useful to - limit the amount of history when using the '@all' p4 revision - specifier. + 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 + '//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' @@ -253,9 +305,6 @@ options described above. --bare:: Perform a bare clone. See linkgit:git-clone[1]. --/ <path>:: - Exclude selected depot paths when cloning. - Submit options ~~~~~~~~~~~~~~ These options can be used to modify 'git p4 submit' behavior. @@ -263,7 +312,7 @@ 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'. + from `HEAD`. -M:: Detect renames. See linkgit:git-diff[1]. Renames will be @@ -279,7 +328,8 @@ These options can be used to modify 'git p4 submit' behavior. Export tags from Git as p4 labels. Tags found in Git are applied to the perforce working directory. ---dry-run, -n:: +-n:: +--dry-run:: Show just what commits would be submitted to p4; do not change state in Git or p4. @@ -290,6 +340,15 @@ These options can be used to modify 'git p4 submit' behavior. 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 @@ -302,6 +361,68 @@ These options can be used to modify 'git p4 submit' behavior. p4/master. See the "Sync options" section above for more information. +--commit <sha1>|<sha1..sha1>:: + Submit only the specified commit or range of commits, instead of the full + list of changes that are in the current Git branch. + +--disable-rebase:: + Disable the automatic rebase after all commits have been successfully + submitted. Can also be set with git-p4.disableRebase. + +--disable-p4sync:: + Disable the automatic sync of p4/master from Perforce after commits have + been submitted. Implies --disable-rebase. Can also be set with + git-p4.disableP4Sync. Sync with origin/master still goes ahead if possible. + +Hooks for submit +---------------- + +p4-pre-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. +It can be bypassed with the `--no-verify` command line option. + +One usage scenario is to run unit tests in the hook. + +p4-prepare-changelist +~~~~~~~~~~~~~~~~~~~~~ + +The `p4-prepare-changelist` hook is executed right after preparing +the default changelist message and before the editor is started. +It takes one parameter, the name of the file that contains the +changelist text. Exiting with a non-zero status from the script +will abort the process. + +The purpose of the hook is to edit the message file in place, +and it is not supressed by the `--no-verify` option. This hook +is called even if `--prepare-p4-only` is set. + +p4-changelist +~~~~~~~~~~~~~ + +The `p4-changelist` hook is executed after the changelist +message has been edited by the user. It can be bypassed with the +`--no-verify` option. It takes a single parameter, the name +of the file that holds the proposed changelist text. Exiting +with a non-zero status causes the command to abort. + +The hook is allowed to edit the changelist file and can be used +to normalize the text into some project standard format. It can +also be used to refuse the Submit after inspect the message file. + +p4-post-changelist +~~~~~~~~~~~~~~~~~~ + +The `p4-post-changelist` hook is invoked after the submit has +successfully occured in P4. It takes no parameters and is meant +primarily for notification and cannot affect the outcome of the +git p4 submit action. + + + Rebase options ~~~~~~~~~~~~~~ These options can be used to modify 'git p4 rebase' behavior. @@ -309,6 +430,13 @@ These options can be used to modify 'git p4 rebase' behavior. --import-labels:: Import p4 labels. +Unshelve options +~~~~~~~~~~~~~~~~ + +--origin:: + Sets the git refspec against which the shelved P4 changelist is compared. + Defaults to p4/master. + DEPOT PATH SYNTAX ----------------- The p4 depot path argument to 'git p4 sync' and 'git p4 clone' can @@ -328,7 +456,7 @@ p4 revision specifier on the end: 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 + 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 @@ -342,7 +470,7 @@ 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 +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 @@ -364,7 +492,7 @@ dedicating a client spec just for 'git p4'. The name of the client can be given to 'git p4' in multiple ways. The variable 'git-p4.client' takes precedence if it exists. Otherwise, normal p4 mechanisms of determining the client are used: environment -variable P4CLIENT, a file referenced by P4CONFIG, or the local host name. +variable `P4CLIENT`, a file referenced by `P4CONFIG`, or the local host name. BRANCH DETECTION @@ -377,7 +505,7 @@ 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' +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. @@ -433,27 +561,33 @@ General variables ~~~~~~~~~~~~~~~~~ git-p4.user:: User specified as an option to all p4 commands, with '-u <user>'. - The environment variable 'P4USER' can be used instead. + The environment variable `P4USER` can be used instead. git-p4.password:: Password specified as an option to all p4 commands, with '-P <password>'. - The environment variable 'P4PASS' can be used instead. + The environment variable `P4PASS` can be used instead. git-p4.port:: Port specified as an option to all p4 commands, with '-p <port>'. - The environment variable 'P4PORT' can be used instead. + The environment variable `P4PORT` can be used instead. git-p4.host:: Host specified as an option to all p4 commands, with '-h <host>'. - The environment variable 'P4HOST' can be used instead. + The environment variable `P4HOST` can be used instead. git-p4.client:: Client specified as an option to all p4 commands, with '-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:: @@ -494,9 +628,61 @@ git-p4.labelImportRegexp:: 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. + 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:: @@ -558,6 +744,12 @@ git-p4.conflict:: Specify submit behavior when a conflict with p4 is found, as per --conflict. The default behavior is 'ask'. +git-p4.disableRebase:: + Do not rebase the tree against p4/master following a submit. + +git-p4.disableP4Sync:: + Do not sync p4/master with Perforce following a submit. Implies git-p4.disableRebase. + IMPLEMENTATION DETAILS ---------------------- * Changesets from p4 are imported using Git fast-import. diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt index d94edcd4b4..eaa2f2a404 100644 --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -12,14 +12,16 @@ SYNOPSIS 'git pack-objects' [-q | --progress | --all-progress] [--all-progress-implied] [--no-reuse-delta] [--delta-base-offset] [--non-empty] [--local] [--incremental] [--window=<n>] [--depth=<n>] - [--revs [--unpacked | --all]] [--stdout | base-name] - [--keep-true-parents] < object-list + [--revs [--unpacked | --all]] [--keep-pack=<pack-name>] + [--stdout [--filter=<filter-spec>] | base-name] + [--shallow] [--keep-true-parents] [--[no-]sparse] < object-list DESCRIPTION ----------- -Reads list of objects from the standard input, and writes a packed -archive with specified base-name, or to the standard output. +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 @@ -47,12 +49,11 @@ transport by their peers. OPTIONS ------- base-name:: - Write into a pair of files (.pack and .idx), using + 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 are written in + 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 - of the sorted object names to make the resulting filename - based on the pack content, and written to the standard + based on the pack content and is written to the standard output of the command. --stdout:: @@ -65,6 +66,8 @@ base-name:: the same way as 'git rev-list' with the `--objects` flag uses its `commit` arguments to build the list of objects it outputs. The objects on the resulting list are packed. + Besides revisions, `--not` or `--shallow <SHA-1>` lines are + also accepted. --unpacked:: This implies `--revs`. When processing the list of @@ -93,7 +96,9 @@ base-name:: it too deep affects the performance on the unpacker side, because delta data needs to be applied that many times to get to the necessary object. - The default value for --window is 10 and --depth is 50. ++ +The default value for --window is 10 and --depth is 50. The maximum +depth is 4095. --window-memory=<n>:: This option provides an additional limit on top of `--window`; @@ -103,13 +108,18 @@ base-name:: 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, which is the - default. + `--window-memory=0` makes memory usage unlimited. The default + is taken from the `pack.windowMemory` configuration variable. --max-pack-size=<n>:: - Maximum size of each output pack file. The size can be suffixed with + 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. - If specified, multiple packfiles may be created. + This option + prevents the creation of a bitmap index. The default is unlimited, unless the config variable `pack.packSizeLimit` is set. @@ -118,6 +128,13 @@ base-name:: has a .keep file to be ignored, even if it would have otherwise been packed. +--keep-pack=<pack-name>:: + This flag causes an object already in the given pack to be + ignored, even if it would have otherwise been + packed. `<pack-name>` is the 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. @@ -179,6 +196,17 @@ base-name:: Add --no-reuse-object if you want to force a uniform compression level on all data no matter the source. +--[no-]sparse:: + Toggle 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. If this option is not included, + it defaults to the value of `pack.useSparse`, which is true unless + otherwise specified. + --thin:: Create a "thin" pack by omitting the common objects between a sender and a receiver in order to reduce network transfer. This @@ -189,6 +217,11 @@ 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 @@ -224,6 +257,146 @@ So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle. 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] diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt index 312c3b1fe5..442caff8a9 100644 --- a/Documentation/git-patch-id.txt +++ b/Documentation/git-patch-id.txt @@ -8,14 +8,16 @@ git-patch-id - Compute unique ID for a patch SYNOPSIS -------- [verse] -'git patch-id' < <patch> +'git patch-id' [--stable | --unstable] DESCRIPTION ----------- -A "patch ID" is nothing but a SHA-1 of the diff 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. +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. @@ -27,8 +29,32 @@ This can be used to make a mapping from patch ID to commit ID. OPTIONS ------- -<patch>:: - The diff to create the ID of. + +--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 --- diff --git a/Documentation/git-peek-remote.txt b/Documentation/git-peek-remote.txt deleted file mode 100644 index 87ea3fb054..0000000000 --- a/Documentation/git-peek-remote.txt +++ /dev/null @@ -1,43 +0,0 @@ -git-peek-remote(1) -================== - -NAME ----- -git-peek-remote - List the references in a remote repository - - -SYNOPSIS --------- -[verse] -'git peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory> - -DESCRIPTION ------------ -This command is deprecated; use 'git ls-remote' instead. - -OPTIONS -------- ---upload-pack=<git-upload-pack>:: - Use this to specify the path to 'git-upload-pack' on the - remote side, if it is not found on your $PATH. Some - installations of sshd ignores the user's environment - setup scripts for login shells (e.g. .bash_profile) and - your privately installed git may not be found on the system - default $PATH. Another workaround suggested is to set - up your $PATH in ".bashrc", but this flag is for people - who do not want to pay the overhead for non-interactive - shells, but prefer having a lean .bashrc file (they set most of - the things up in .bash_profile). - -<host>:: - A remote host that houses the repository. When this - part is specified, 'git-upload-pack' is invoked via - ssh. - -<directory>:: - The repository to sync from. - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt index 6738055bd3..9fed59a317 100644 --- a/Documentation/git-prune-packed.txt +++ b/Documentation/git-prune-packed.txt @@ -1,5 +1,5 @@ git-prune-packed(1) -===================== +=================== NAME ---- diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index bf824108c1..03552dd86f 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -9,7 +9,7 @@ git-prune - Prune all unreachable objects from the object database SYNOPSIS -------- [verse] -'git prune' [-n] [-v] [--expire <expire>] [--] [<head>...] +'git prune' [-n] [-v] [--progress] [--expire <time>] [--] [<head>...] DESCRIPTION ----------- @@ -24,6 +24,8 @@ objects unreachable from any of these head objects from the object database. In addition, it prunes the unpacked objects that are also found in packs by running 'git prune-packed'. +It also removes entries from .git/shallow that are not reachable by +any ref. Note that unreachable, packed objects will remain. If this is not desired, see linkgit:git-repack[1]. @@ -40,21 +42,24 @@ OPTIONS --verbose:: Report all removed objects. -\--:: - Do not interpret any more arguments as options. +--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. -EXAMPLE -------- +EXAMPLES +-------- -To prune objects not used by your repository nor another that +To prune objects not used by your repository or another that borrows from your repository via its `.git/objects/info/alternates`: @@ -62,7 +67,7 @@ borrows from your repository via its $ git prune $(cd ../another && git rev-parse --all) ------------ -Notes +NOTES ----- In most cases, users will not need to call 'git prune' directly, but diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index beea10b148..5c3fb67c01 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -9,7 +9,7 @@ git-pull - Fetch from and integrate with another repository or a local branch SYNOPSIS -------- [verse] -'git pull' [options] [<repository> [<refspec>...]] +'git pull' [<options>] [<repository> [<refspec>...]] DESCRIPTION @@ -42,6 +42,8 @@ Assume the following history exists and the current branch is 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 @@ -51,7 +53,7 @@ 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 remotes/origin/master + A---B---C origin/master / \ D---E---F---G---H master ------------ @@ -65,16 +67,13 @@ 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 cancelled and the work tree untouched. +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 ------- -Options meant for 'git pull' itself and the underlying 'git merge' -must be given before the options meant for 'git fetch'. - -q:: --quiet:: This is passed to both underlying git-fetch to squelch reporting of @@ -86,36 +85,43 @@ must be given before the options meant for 'git fetch'. 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 too (see linkgit:git-config[1] and linkgit:gitmodules[5]). - That might be necessary to get the data needed for merging submodule - commits, a feature Git learned in 1.7.3. Notice that the result of a - merge will not be checked out in the submodule, "git submodule update" - has to be called afterwards to bring the work tree up to date with the - merge result. + This option controls if new commits of populated submodules should + be fetched, and if the working trees of active submodules should be + updated, too (see linkgit:git-fetch[1], 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~ -include::merge-options.txt[] - :git-pull: 1 +include::merge-options.txt[] + -r:: ---rebase[=false|true|preserve]:: +--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 preserve, also rebase the current branch on top of the upstream -branch, but pass `--preserve-merges` along to `git rebase` so that -locally created merge commits will not be flattened. +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. + -See `pull.rebase`, `branch.<name>.rebase` and `branch.autosetuprebase` in +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. + @@ -150,15 +156,15 @@ present while on branch `<name>`, that value is used instead of 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 `URL: ` line -in `$GIT_DIR/remotes/<origin>` file is used. +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>` -file is consulted and its `Pull: ` lines are used. +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: @@ -201,7 +207,8 @@ EXAMPLES current branch: + ------------------------------------------------ -$ git pull, git pull origin +$ git pull +$ git pull origin ------------------------------------------------ + Normally the branch merged in is the HEAD of the remote repository, @@ -214,9 +221,9 @@ branch.<name>.merge options; see linkgit:git-config[1] for details. $ 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: +This leaves a copy of `next` temporarily in FETCH_HEAD, and +updates the remote-tracking branch `origin/next`. +The same can be done by invoking fetch and merge: + ------------------------------------------------ $ git fetch origin @@ -228,11 +235,13 @@ 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 can not be +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. diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 9eec740910..3b8053447e 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -9,8 +9,10 @@ git-push - Update remote refs along with associated objects SYNOPSIS -------- [verse] -'git push' [--all | --mirror | --tags] [--follow-tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>] - [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream] +'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>...]] @@ -33,7 +35,14 @@ 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 gitlink:git-config[1] for the meaning of `push.default`). +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]] @@ -56,30 +65,90 @@ it can be any arbitrary "SHA-1 expression", such as `master~4` or + The <dst> tells which ref on the remote side is updated with this push. Arbitrary expressions cannot be used here, an actual ref must -be named. If `:`<dst> is omitted, the same ref as <src> will be -updated. +be named. +If `git push [<repository>]` without any `<refspec>` argument is set to +update some ref at the destination with `<src>` with +`remote.<repository>.push` configuration variable, `:<dst>` part can +be omitted--such a push will update a ref that `<src>` normally updates +without any `<refspec>` on the command line. Otherwise, missing +`:<dst>` means to update the same ref as the `<src>`. ++ +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. By default this is only allowed if <dst> is not -a tag (annotated or lightweight), and then only if it can fast-forward -<dst>. By having the optional leading `+`, you can tell Git to update -the <dst> ref even if it is not allowed by default (e.g., it is not a -fast-forward.) This does *not* attempt to merge <src> into <dst>. See -EXAMPLES below for details. +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. + -`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`. +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. + -Pushing an empty <src> allows you to delete the <dst> ref from -the remote repository. +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:: - Instead of naming each ref to push, specifies that all - refs under `refs/heads/` be pushed. + Push all branches (i.e. refs under `refs/heads/`); cannot be + used with other <refspec>. --prune:: Remove remote branches that don't have a local counterpart. For example @@ -109,6 +178,7 @@ already exists on the remote side. will be tab-separated and sent to stdout instead of stderr. The full symbolic names of the refs will be given. +-d:: --delete:: All listed refs are deleted from the remote repository. This is the same as prefixing all refs with a colon. @@ -122,7 +192,37 @@ already exists on the remote side. 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. + 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>:: @@ -137,9 +237,8 @@ already exists on the remote side. Usually, "git push" refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. + -This option bypasses the check, but instead requires that the -current value of the ref to be the expected value. "git push" -fails otherwise. +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 @@ -151,15 +250,14 @@ 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 you update the ref while -making sure that your earlier "lease" is still valid). +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, unless specified with a `--force-with-lease=<refname>:<expect>` -option that explicitly states what the expected value is. +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 @@ -168,10 +266,11 @@ 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 +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). +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 @@ -180,6 +279,47 @@ 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:: @@ -202,35 +342,21 @@ origin +master` to force a push to the `master` branch). See the `<refspec>...` section above for details. --repo=<repository>:: - This option is only relevant if no <repository> argument is - passed in the invocation. In this case, 'git push' derives the - remote name from the current branch: If it tracks a remote - branch, then that remote repository is pushed to. Otherwise, - the name "origin" is used. For this latter case, this option - can be used to override the name "origin". In other words, - the difference between these two commands -+ --------------------------- -git push public #1 -git push --repo=public #2 --------------------------- -+ -is that #1 always pushes to "public" whereas #2 pushes to "public" -only if the current branch does not track a remote branch. This is -useful if you write an alias or script around 'git push'. + 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]. + 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. + `--thin`. -q:: --quiet:: @@ -248,22 +374,34 @@ useful if you write an alias or script around 'git push'. is specified. This flag forces progress status even if the standard error stream is not directed to a terminal. ---recurse-submodules=check|on-demand:: - 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. +--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. + 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[] @@ -341,7 +479,7 @@ reason:: refs, no explanation is needed. For a failed ref, the reason for failure is described. -Note about fast-forwards +NOTE ABOUT FAST-FORWARDS ------------------------ When an update changes a branch (or more in general, a ref) that used to @@ -380,7 +518,7 @@ 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) nor the work by +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. @@ -428,7 +566,7 @@ overwrite it. In other words, "git push --force" is a method reserved for a case where you do mean to lose history. -Examples +EXAMPLES -------- `git push`:: @@ -437,8 +575,10 @@ Examples configured for the current branch). `git push origin`:: - Without additional configuration, works like - `git push origin :`. + Without additional configuration, pushes the current branch to + the configured upstream (`remote.origin.merge` configuration + variable) if it has the same name as the current branch, and + errors out without pushing otherwise. + The default behavior of this command when no <refspec> is given can be configured by setting the `push` option of the remote, or the `push.default` @@ -471,6 +611,9 @@ the ones in the examples below) can be configured as the default for `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 @@ -523,6 +666,8 @@ 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/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt index a356196586..70562dc4c0 100644 --- a/Documentation/git-quiltimport.txt +++ b/Documentation/git-quiltimport.txt @@ -1,5 +1,5 @@ git-quiltimport(1) -================ +================== NAME ---- @@ -10,6 +10,7 @@ SYNOPSIS -------- [verse] 'git quiltimport' [--dry-run | -n] [--author <author>] [--patches <dir>] + [--series <file>] [--keep-non-patch] DESCRIPTION @@ -42,13 +43,22 @@ OPTIONS information can be found in the patch description. --patches <dir>:: - The directory to find the quilt patches and the - quilt series file. + The directory to find the quilt patches. + The default for the patch directory is patches -or the value of the $QUILT_PATCHES environment +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/Documentation/git-range-diff.txt b/Documentation/git-range-diff.txt new file mode 100644 index 0000000000..9701c1e5fd --- /dev/null +++ b/Documentation/git-range-diff.txt @@ -0,0 +1,273 @@ +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. + +--[no-]notes[=<ref>]:: + This flag is passed to the `git log` program + (see linkgit:git-log[1]) that generates the patches. + +<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 most of 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 assignment 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/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt index c4bde6509e..5fa8bab64c 100644 --- a/Documentation/git-read-tree.txt +++ b/Documentation/git-read-tree.txt @@ -38,8 +38,9 @@ OPTIONS started. --reset:: - Same as -m, except that unmerged entries are discarded - instead of failing. + 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 @@ -57,7 +58,7 @@ OPTIONS -n:: --dry-run:: Check if the command would error out, without updating the index - nor the files in the working tree for real. + or the files in the working tree for real. -v:: Show the progress of checking files out. @@ -81,12 +82,11 @@ OPTIONS * when both sides add a path identically. The resolution is to add that path. ---prefix=<prefix>/:: +--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. Note that the `<prefix>/` - value must end with a slash. + existed in the original index file. --exclude-per-directory=<gitignore>:: When running the command with `-u` and `-m` options, the @@ -115,6 +115,12 @@ OPTIONS directories the index file and index output file are located in. +--[no-]recurse-submodules:: + Using --recurse-submodules will update the content of all active + 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. @@ -123,15 +129,19 @@ OPTIONS 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 +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 trees are +fast-forward merge with 2 trees, or a 3-way merge if 3 or more trees are provided. @@ -173,6 +183,7 @@ 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) @@ -211,6 +222,7 @@ refer to the presence of a path in the specified commit: 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, @@ -283,7 +295,7 @@ merge. The different stages represent the "result tree" (stage 0, aka 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 +<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: @@ -375,7 +387,7 @@ middle of doing, and when your working tree is ready (i.e. you have finished your work-in-progress), attempt the merge again. -Sparse checkout +SPARSE CHECKOUT --------------- "Sparse checkout" allows populating the working directory sparsely. @@ -424,7 +436,7 @@ support. SEE ALSO -------- linkgit:git-write-tree[1]; linkgit:git-ls-files[1]; -linkgit:gitignore[5] +linkgit:gitignore[5]; linkgit:git-sparse-checkout[1]; GIT --- diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 94e07fdab5..374d2486f7 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -3,33 +3,35 @@ git-rebase(1) NAME ---- -git-rebase - Forward-port local commits to the updated upstream head +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>] +'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] + [--onto <newbase> | --keep-base] [<upstream> [<branch>]] +'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] --root [<branch>] -'git rebase' --continue | --skip | --abort | --edit-todo +'git rebase' (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch) DESCRIPTION ----------- If <branch> is specified, 'git rebase' will perform an automatic -`git checkout <branch>` before doing anything else. Otherwise +`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. If you are currently not on any -branch or if the current branch does not have a configured upstream, -the rebase will abort. +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 -`git log HEAD`, if --root is specified). +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 @@ -78,7 +80,7 @@ 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, +following history (in which `A'` and `A` introduce the same set of changes, but have different committer information): ------------ @@ -201,15 +203,7 @@ Alternatively, you can undo the 'git rebase' with CONFIGURATION ------------- -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:: - If set to true enable '--autostash' option by default. +include::config/rebase.txt[] OPTIONS ------- @@ -223,6 +217,24 @@ 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. +--keep-base:: + Set the starting point at which to create the new commits to the + merge base of <upstream> <branch>. Running + 'git rebase --keep-base <upstream> <branch>' is equivalent to + running 'git rebase --onto <upstream>... <upstream>'. ++ +This option is useful in the case where one is developing a feature on +top of an upstream branch. While the feature is being worked on, the +upstream branch may advance and it may not be the best idea to keep +rebasing on top of the upstream but to keep the base commit as-is. ++ +Although both this option and --fork-point find the merge base between +<upstream> and <branch>, this option uses the merge base as the _starting +point_ on which new commits will be created, whereas --fork-point uses +the merge base to determine the _set of commits_ which will be rebased. ++ +See also INCOMPATIBLE OPTIONS below. + <upstream>:: Upstream branch to compare against. May be any valid commit, not just an existing branch name. Defaults to the configured @@ -241,9 +253,84 @@ leave out at most one of A and B, in which case it defaults to 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. If a temporary stash entry was created + using --autostash, it will be saved to the stash list. + +--apply:: + Use applying strategies to rebase (calling `git-am` + internally). This option may become a no-op in the future + once the merge backend handles everything the apply one does. ++ +See also INCOMPATIBLE OPTIONS below. + +--empty={drop,keep,ask}:: + How to handle commits that are not empty to start and are not + clean cherry-picks of any upstream commit, but which become + empty after rebasing (because they contain a subset of already + upstream changes). With drop (the default), commits that + become empty are dropped. With keep, such commits are kept. + With ask (implied by --interactive), the rebase will halt when + an empty commit is applied allowing you to choose whether to + drop it, edit files more, or just commit the empty changes. + Other options, like --exec, will use the default of drop unless + -i/--interactive is explicitly specified. ++ +Note that commits which start empty are kept (unless --no-keep-empty +is specified), and commits which are clean cherry-picks (as determined +by `git log --cherry-mark ...`) are detected and dropped as a +preliminary step (unless --reapply-cherry-picks is passed). ++ +See also INCOMPATIBLE OPTIONS below. + +--no-keep-empty:: --keep-empty:: - Keep the commits that do not change anything from its - parents in the result. + Do not keep commits that start empty before the rebase + (i.e. that do not change anything from its parent) in the + result. The default is to keep commits which start empty, + since creating such commits requires passing the --allow-empty + override flag to `git commit`, signifying that a user is very + intentionally creating such a commit and thus wants to keep + it. ++ +Usage of this flag will probably be rare, since you can get rid of +commits that start empty by just firing up an interactive rebase and +removing the lines corresponding to the commits you don't want. This +flag exists as a convenient shortcut, such as for cases where external +tools generate many empty commits and you want them all removed. ++ +For commits which do not start empty but become empty after rebasing, +see the --empty flag. ++ +See also INCOMPATIBLE OPTIONS below. + +--reapply-cherry-picks:: +--no-reapply-cherry-picks:: + Reapply all clean cherry-picks of any upstream commit instead + of preemptively dropping them. (If these commits then become + empty after rebasing, because they contain a subset of already + upstream changes, the behavior towards them is controlled by + the `--empty` flag.) ++ +By default (or if `--no-reapply-cherry-picks` is given), these commits +will be automatically dropped. Because this necessitates reading all +upstream commits, this can be expensive in repos with a large number +of upstream commits that need to be read. ++ +`--reapply-cherry-picks` allows rebase to forgo reading all upstream +commits, potentially improving performance. ++ +See also INCOMPATIBLE OPTIONS below. + +--allow-empty-message:: + No-op. Rebasing commits with an empty message used to fail + and this option would override that behavior, allowing commits + with empty messages to be rebased. Now commits with an empty + message do not cause rebasing to halt. ++ +See also INCOMPATIBLE OPTIONS below. --skip:: Restart the rebasing process by skipping the current patch. @@ -251,17 +338,24 @@ leave out at most one of A and B, in which case it defaults to HEAD. --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. + upstream side. This is the default. + 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>:: @@ -271,8 +365,10 @@ other words, the sides are swapped. + 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 discards all patches from the <branch>, +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>:: @@ -280,6 +376,22 @@ which makes little sense. 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>]:: +--no-gpg-sign:: + 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` is useful to + countermand both `commit.gpgSign` configuration variable, and + earlier `--gpg-sign`. -q:: --quiet:: @@ -308,56 +420,124 @@ which makes little sense. 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. + ever ignored. Implies --apply. ++ +See also INCOMPATIBLE OPTIONS below. --f:: +--no-ff:: --force-rebase:: - Force the rebase even if the current branch is a descendant - of the commit you are rebasing onto. Normally non-interactive rebase will - exit with the message "Current branch is up to date" in such a - situation. - Incompatible with the --interactive option. -+ -You may find this (or --no-ff with an interactive rebase) 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). +-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 <upstream> is given on the command line, then the default is +`--no-fork-point`, otherwise the default is `--fork-point`. ++ +If your branch was based on <upstream> but <upstream> was rewound and +your branch contains commits which were dropped, this option can be used +with `--keep-base` in order to drop those commits from your branch. ++ +See also INCOMPATIBLE OPTIONS below. --ignore-whitespace:: --whitespace=<option>:: - These flag are passed to the 'git apply' program + These flags are passed to the 'git apply' program (see linkgit:git-apply[1]) that applies the patch. - Incompatible with the --interactive option. + Implies --apply. ++ +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]). - Incompatible with the --interactive option. ++ +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 works with interactive rebases, +where 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:: - Instead of ignoring merges, try to recreate them. + [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. -+ -This option can only be used with the `--interactive` option -(see INTERACTIVE MODE below). + 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: @@ -371,6 +551,11 @@ or by giving more than one `--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 @@ -381,42 +566,218 @@ squash/fixup series. 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 a commit whose title begins with - 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`). Ignores subsequent - "fixup! " or "squash! " after the first, in case you referred to an - earlier fixup/squash with `git commit --fixup/--squash`. -+ -This option is only valid when the '--interactive' option is used. -+ -If the '--autosquash' option is enabled by default using the -configuration variable `rebase.autosquash`, this option can be + "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. ---[no-]autostash:: - Automatically create a temporary stash before the operation +--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. ---no-ff:: - With --interactive, cherry-pick 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. -+ -Without --interactive, this is a synonym for --force-rebase. -+ -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). +--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: + + * --apply + * --committer-date-is-author-date + * --ignore-date + * --ignore-whitespace + * --whitespace + * -C + +are incompatible with the following options: + + * --merge + * --strategy + * --strategy-option + * --allow-empty-message + * --[no-]autosquash + * --rebase-merges + * --preserve-merges + * --interactive + * --exec + * --no-keep-empty + * --empty= + * --reapply-cherry-picks + * --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 + * --preserve-merges and --empty= + * --keep-base and --onto + * --keep-base and --root + * --fork-point and --root + +BEHAVIORAL DIFFERENCES +----------------------- + +git rebase has two primary backends: apply and merge. (The apply +backend used to be known as the 'am' backend, but the name led to +confusion as it looks like a verb instead of a noun. Also, the merge +backend used to be known as the interactive backend, but it is now +used for non-interactive cases as well. Both were renamed based on +lower-level functionality that underpinned each.) There are some +subtle differences in how these two backends behave: + +Empty commits +~~~~~~~~~~~~~ + +The apply backend unfortunately drops intentionally empty commits, i.e. +commits that started empty, though these are rare in practice. It +also drops commits that become empty and has no option for controlling +this behavior. + +The merge backend keeps intentionally empty commits by default (though +with -i they are marked as empty in the todo list editor, or they can +be dropped automatically with --no-keep-empty). + +Similar to the apply backend, by default the merge backend drops +commits that become empty unless -i/--interactive is specified (in +which case it stops and asks the user what to do). The merge backend +also has an --empty={drop,keep,ask} option for changing the behavior +of handling commits that become empty. + +Directory rename detection +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Due to the lack of accurate tree information (arising from +constructing fake ancestors with the limited information available in +patches), directory rename detection is disabled in the apply backend. +Disabled directory rename detection means that if one side of history +renames a directory and the other adds new files to the old directory, +then the new files will be left behind in the old directory without +any warning at the time of rebasing that you may want to move these +files into the new directory. + +Directory rename detection works with the merge backend to provide you +warnings in such cases. + +Context +~~~~~~~ + +The apply backend works by creating a sequence of patches (by calling +`format-patch` internally), and then applying the patches in sequence +(calling `am` internally). Patches are composed of multiple hunks, +each with line numbers, a context region, and the actual changes. The +line numbers have to be taken with some fuzz, since the other side +will likely have inserted or deleted lines earlier in the file. The +context region is meant to help find how to adjust the line numbers in +order to apply the changes to the right lines. However, if multiple +areas of the code have the same surrounding lines of context, the +wrong one can be picked. There are real-world cases where this has +caused commits to be reapplied incorrectly with no conflicts reported. +Setting diff.context to a larger value may prevent such types of +problems, but increases the chance of spurious conflicts (since it +will require more lines of matching context to apply). + +The merge backend works with a full copy of each relevant file, +insulating it from these types of problems. + +Labelling of conflicts markers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When there are content conflicts, the merge machinery tries to +annotate each side's conflict markers with the commits where the +content came from. Since the apply backend drops the original +information about the rebased commits and their parents (and instead +generates new fake commits based off limited information in the +generated patches), those commits cannot be identified; instead it has +to fall back to a commit summary. Also, when merge.conflictStyle is +set to diff3, the apply backend will use "constructed merge base" to +label the content from the merge base, and thus provide no information +about the merge base commit whatsoever. + +The merge backend works with the full commits on both sides of history +and thus has no such limitations. + +Hooks +~~~~~ + +The apply backend has not traditionally called the post-commit hook, +while the merge backend has. Both have called the post-checkout hook, +though the merge backend has squelched its output. Further, both +backends only call the post-checkout hook with the starting point +commit of the rebase, not the intermediate commits nor the final +commit. In each case, the calling of these hooks was by accident of +implementation rather than by design (both backends were originally +implemented as shell scripts and happened to invoke other commands +like 'git checkout' or 'git commit' that would call the hooks). Both +backends should have the same behavior, though it is not entirely +clear which, if any, is correct. We will likely make rebase stop +calling either of these hooks in the future. + +Interruptability +~~~~~~~~~~~~~~~~ + +The apply backend has safety problems with an ill-timed interrupt; if +the user presses Ctrl-C at the wrong time to try to abort the rebase, +the rebase can enter a state where it cannot be aborted with a +subsequent `git rebase --abort`. The merge backend does not appear to +suffer from the same shortcoming. (See +https://lore.kernel.org/git/20200207132152.GC2868@szeder.dev/ for +details.) + +Commit Rewording +~~~~~~~~~~~~~~~~ + +When a conflict occurs while rebasing, rebase stops and asks the user +to resolve. Since the user may need to make notable changes while +resolving conflicts, after conflicts are resolved and the user has run +`git rebase --continue`, the rebase should open an editor and ask the +user to update the commit message. The merge backend does this, while +the apply backend blindly applies the original commit message. + +Miscellaneous differences +~~~~~~~~~~~~~~~~~~~~~~~~~ + +There are a few more behavioral differences that most folks would +probably consider inconsequential but which are mentioned for +completeness: + +* Reflog: The two backends will use different wording when describing + the changes made in the reflog, though both will make use of the + word "rebase". + +* Progress, informational, and error messages: The two backends + provide slightly different progress and informational messages. + Also, the apply backend writes error messages (such as "Your files + would be overwritten...") to stdout, while the merge backend writes + them to stderr. + +* State directories: The two backends keep their state in different + directories under .git/ include::merge-strategies.txt[] @@ -491,9 +852,15 @@ By replacing the command "pick" with the command "edit", you can tell 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 @@ -516,7 +883,8 @@ $ git rebase -i HEAD~5 And move the first patch to the end of the list. -You might want to preserve merges, if you have a history like this: +You might want to recreate merge commits, e.g. if you have a history +like this: ------------------ X @@ -530,7 +898,7 @@ 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 -p --onto Q O +$ git rebase -i -r --onto Q O ----------------------------- Reordering and editing commits usually creates untested intermediate @@ -626,7 +994,7 @@ on this 'subsystem'. You might end up with a history like the following: ------------ - o---o---o---o---o---o---o---o---o master + o---o---o---o---o---o---o---o master \ o---o---o---o---o subsystem \ @@ -672,7 +1040,8 @@ 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`. + a full history rewriting command like + https://github.com/newren/git-filter-repo[`filter-repo`]. The easy case @@ -683,7 +1052,8 @@ Only works if the changes (patch IDs based on the diff contents) on '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 +changes that are already present in the new upstream (unless +`--reapply-cherry-picks` is given). So if you say (assuming you're on 'topic') ------------ $ git rebase subsystem @@ -710,7 +1080,7 @@ NOTE: While an "easy case recovery" sometimes appears to be successful --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 +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: @@ -731,12 +1101,147 @@ 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 `--preserve-merges --interactive` does not -represent the topology of the revision graph. Editing commits and -rewording their commit messages should work fine, but attempts to -reorder commits tend to produce counterintuitive results. +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 ------------ diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt index b1f7dc643a..25702ed730 100644 --- a/Documentation/git-receive-pack.txt +++ b/Documentation/git-receive-pack.txt @@ -33,12 +33,15 @@ post-update hooks found in the Documentation/howto directory. option, which tells it if updates to a ref should be denied if they are not fast-forwards. +A number of other receive.* config options are available to tweak +its behavior, see linkgit:git-config[1]. + OPTIONS ------- <directory>:: The repository to sync into. -pre-receive Hook +PRE-RECEIVE HOOK ---------------- Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists and is executable, it will be invoked once with no parameters. The @@ -53,6 +56,56 @@ 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. @@ -61,7 +114,9 @@ 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. -update Hook +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: @@ -83,7 +138,7 @@ ensure the ref will actually be updated, it is only a prerequisite. As such it is not a good idea to send notices (e.g. email) from this hook. Consider using the post-receive hook instead. -post-receive Hook +POST-RECEIVE HOOK ----------------- After all refs were updated (or attempted to be updated), if any ref update was successful, and if $GIT_DIR/hooks/post-receive @@ -101,25 +156,40 @@ the update. Refs that were created will have sha1-old 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: - - #!/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 - exit 0 +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. @@ -130,7 +200,7 @@ after it was updated by 'git-receive-pack', but before the hook was able to evaluate it. It is recommended that hooks rely on sha1-new rather than the current value of refname. -post-update Hook +POST-UPDATE HOOK ---------------- After all other processing, if at least one ref was updated, and if $GIT_DIR/hooks/post-update file exists and is executable, then @@ -144,8 +214,37 @@ 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 +---- +#!/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 diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt index 70791b9fd8..ff487ff77d 100644 --- a/Documentation/git-reflog.txt +++ b/Documentation/git-reflog.txt @@ -17,85 +17,122 @@ The command takes various subcommands, and different options depending on the subcommand: [verse] -'git reflog expire' [--dry-run] [--stale-fix] [--verbose] - [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>... -'git reflog delete' ref@\{specifier\}... '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. -Reflog is a mechanism to record when the tip of branches are -updated. This command is to manage the information recorded in it. - -The subcommand "expire" is used to prune 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 the end users -- instead, see linkgit:git-gc[1]. +OPTIONS +------- -The subcommand "show" (which is also the default, in the absence of any -subcommands) will take all the normal log options, and show the log of -the reference provided in the command-line (or `HEAD`, by default). -The reflog will cover all recent actions (HEAD reflog records branch switching -as well). It is an alias for `git log -g --abbrev-commit --pretty=oneline`; -see linkgit:git-log[1]. +Options for `show` +~~~~~~~~~~~~~~~~~~ -The reflog is 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", and so on. See linkgit:gitrevisions[7] for -more details. +`git reflog show` accepts any of the options accepted by `git log`. -To delete single entries from the reflog, use the subcommand "delete" -and specify the _exact_ entry (e.g. "`git reflog delete master@{2}`"). +Options for `expire` +~~~~~~~~~~~~~~~~~~~~ -OPTIONS -------- +--all:: + Process the reflogs of all references. ---stale-fix:: - This revamps the logic -- the definition of "broken commit" - becomes: a commit that is not reachable from any of the refs and - there is a missing object among the commit, tree, or blob - objects reachable from it that is not reachable from any of the - refs. -+ -This computation involves traversing all the reachable objects, i.e. it -has the same cost as 'git prune'. Fortunately, once this is run, we -should not have to ever worry about missing objects, because the current -prune and pack-objects know about reflogs and protect objects referred by -them. +--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>:: - Entries older than this time are pruned. Without the - option it is taken from configuration `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). + 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>:: - Entries older than this time and not reachable from - the current tip of the branch are pruned. Without the - option it is taken from configuration - `gc.reflogExpireUnreachable`, which in turn defaults to - 30 days. --expire-unreachable=all prunes unreachable - entries regardless of their age; --expire-unreachable=never + 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). - ---all:: - Instead of listing <refs> explicitly, prune all refs. + `--expire`). --updateref:: - Update the ref with the sha1 of the top reflog entry (i.e. - <ref>@\{0\}) after expiring or deleting. + 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:: - While expiring or deleting, adjust each reflog entry to ensure - that the `old` sha1 field points to the `new` sha1 field of the - previous entry. + 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/Documentation/git-relink.txt b/Documentation/git-relink.txt deleted file mode 100644 index 3b33c99510..0000000000 --- a/Documentation/git-relink.txt +++ /dev/null @@ -1,30 +0,0 @@ -git-relink(1) -============= - -NAME ----- -git-relink - Hardlink common objects in local repositories - -SYNOPSIS --------- -[verse] -'git relink' [--safe] <dir>... <master_dir> - -DESCRIPTION ------------ -This will scan 1 or more object repositories and look for objects in common -with a master repository. Objects not already hardlinked to the master -repository will be replaced with a hardlink to the master repository. - -OPTIONS -------- ---safe:: - Stops if two objects with the same hash exist but have different sizes. - Default is to warn and continue. - -<dir>:: - Directories containing a .git/objects/ subdirectory. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote-ext.txt b/Documentation/git-remote-ext.txt index 8cfc748ae2..88ea7e1cc0 100644 --- a/Documentation/git-remote-ext.txt +++ b/Documentation/git-remote-ext.txt @@ -55,14 +55,14 @@ some tunnel. the vhost field in the git:// service request (to rest of the argument). Default is not to send vhost in such request (if sent). -ENVIRONMENT VARIABLES: ----------------------- +ENVIRONMENT VARIABLES +--------------------- GIT_TRANSLOOP_DEBUG:: If set, prints debugging information about various reads/writes. -ENVIRONMENT VARIABLES PASSED TO COMMAND: ----------------------------------------- +ENVIRONMENT VARIABLES PASSED TO COMMAND +--------------------------------------- GIT_EXT_SERVICE:: Set to long name (git-upload-pack, etc...) of service helper needs @@ -73,8 +73,8 @@ GIT_EXT_SERVICE_NOPREFIX:: to invoke. -EXAMPLES: ---------- +EXAMPLES +-------- This remote helper is transparently used by Git when you use commands such as "git fetch <URL>", "git clone <URL>", , "git push <URL>" or "git remote add <nick> <URL>", where <URL> @@ -104,7 +104,7 @@ begins with `ext::`. Examples: link-level address). "ext::git-server-alias foo %G/repo% with% spaces %Vfoo":: - Represents a repository with path '/repo with spaces' accessed + 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 @@ -116,10 +116,9 @@ begins with `ext::`. Examples: determined by the helper using environment variables (see above). -Documentation --------------- -Documentation by Ilari Liusvaara, Jonathan Nieder and the Git list -<git@vger.kernel.org> +SEE ALSO +-------- +linkgit:gitremote-helpers[7] GIT --- diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt index 933c2adaf6..0451ceb8a2 100644 --- a/Documentation/git-remote-fd.txt +++ b/Documentation/git-remote-fd.txt @@ -17,7 +17,7 @@ fetch, push or archive. If only <infd> is given, it is assumed to be a bidirectional socket connected to remote Git server (git-upload-pack, git-receive-pack or -git-upload-achive). If both <infd> and <outfd> are given, they are assumed +git-upload-archive). If both <infd> and <outfd> are given, they are assumed to be pipes connected to a remote Git server (<infd> being the inbound pipe and <outfd> being the outbound pipe. @@ -50,9 +50,9 @@ EXAMPLES `git push fd::7,8/bar master`:: Same as above. -Documentation --------------- -Documentation by Ilari Liusvaara and the Git list <git@vger.kernel.org> +SEE ALSO +-------- +linkgit:gitremote-helpers[7] GIT --- diff --git a/Documentation/git-remote-helpers.txto b/Documentation/git-remote-helpers.txto index 49233f5d26..6f353ebfd3 100644 --- a/Documentation/git-remote-helpers.txto +++ b/Documentation/git-remote-helpers.txto @@ -1,7 +1,7 @@ git-remote-helpers ================== -This document has been moved to linkgit:gitremote-helpers[1]. +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. diff --git a/Documentation/git-remote-testgit.txt b/Documentation/git-remote-testgit.txt deleted file mode 100644 index f791d73c05..0000000000 --- a/Documentation/git-remote-testgit.txt +++ /dev/null @@ -1,30 +0,0 @@ -git-remote-testgit(1) -===================== - -NAME ----- -git-remote-testgit - Example remote-helper - - -SYNOPSIS --------- -[verse] -git clone testgit::<source-repo> [<destination>] - -DESCRIPTION ------------ - -This command is a simple remote-helper, that is used both as a -testcase for the remote-helper functionality, and as an example to -show remote-helper authors one possible implementation. - -The best way to learn more is to read the comments and source code in -'git-remote-testgit'. - -SEE ALSO --------- -linkgit:gitremote-helpers[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 2507c8bd91..9659abbf8e 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -1,9 +1,9 @@ git-remote(1) -============ +============= NAME ---- -git-remote - manage set of tracked repositories +git-remote - Manage set of tracked repositories SYNOPSIS @@ -15,6 +15,7 @@ SYNOPSIS '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> @@ -58,6 +59,9 @@ 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>` @@ -128,19 +132,36 @@ The named branches will be interpreted as if specified with the 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 URL remote points to. Sets first URL remote points to matching +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, error occurs and nothing is changed. +<oldurl> doesn't match any URL, an error occurs and nothing is changed. ++ +With `--push`, push URLs are manipulated instead of fetch URLs. + -With '--push', push URLs are manipulated instead of fetch URLs. +With `--add`, instead of changing existing URLs, new URL is added. + -With '--add', instead of changing some URL, 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. + -With '--delete', instead of changing some URL, all URLs matching -regex <url> are deleted. 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':: @@ -151,24 +172,28 @@ With `-n` option, the remote heads are not queried first with 'prune':: -Deletes all stale remote-tracking branches under <name>. -These stale branches have already been removed from the remote repository -referenced by <name>, but are still locally available in -"remotes/<name>". +Deletes stale references associated with <name>. By default, stale +remote-tracking branches under <name> are deleted, but depending on +global configuration and the configuration of the remote we might even +prune local tags that haven't been pushed there. Equivalent to `git +fetch --prune <name>`, except that no new references will be fetched. ++ +See the PRUNING section of linkgit:git-fetch[1] for what it'll prune +depending on various configuration. + With `--dry-run` option, report what branches will be pruned, but do not actually prune them. 'update':: -Fetch updates for a named set of remotes in the repository as defined by -remotes.<group>. If a named group is not specified on the command line, +Fetch updates for remotes or remote groups in the repository as defined by +remotes.<group>. If neither group nor remote is specified on the command line, the configuration parameter remotes.default will be used; if remotes.default is not defined, all remotes which do not have the configuration parameter remote.<name>.skipDefaultUpdate set to true will be updated. (See linkgit:git-config[1]). + -With `--prune` option, prune all the remotes that are updated. +With `--prune` option, run pruning against all the remotes that are updated. DISCUSSION @@ -178,7 +203,7 @@ The remote configuration is achieved using the `remote.origin.url` and `remote.origin.fetch` configuration variables. (See linkgit:git-config[1]). -Examples +EXAMPLES -------- * Add a new remote, fetch, and check out a branch from it @@ -205,7 +230,7 @@ $ git branch -r staging/master staging/staging-linus staging/staging-next -$ git checkout -b staging staging/master +$ git switch -c staging staging/master ... ------------ diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt index 4c1aff65e6..92f146d27d 100644 --- a/Documentation/git-repack.txt +++ b/Documentation/git-repack.txt @@ -9,12 +9,12 @@ git-repack - Pack unpacked objects in a repository SYNOPSIS -------- [verse] -'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [--window=<n>] [--depth=<n>] +'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>] DESCRIPTION ----------- -This script is used to combine all objects that do not currently +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. @@ -33,16 +33,21 @@ OPTIONS 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` + 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 + 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. @@ -90,7 +95,12 @@ other objects in that pack they already have locally. space. `--depth` limits the maximum delta depth; making it too deep affects the performance on the unpacker side, because delta data needs to be applied that many times to get to the necessary object. - The default value for --window is 10 and --depth is 50. ++ +The default value for --window is 10 and --depth is 50. The maximum +depth is 4095. + +--threads=<n>:: + This option is passed through to `git pack-objects`. --window-memory=<n>:: This option provides an additional limit on top of `--window`; @@ -100,16 +110,60 @@ other objects in that pack they already have locally. 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, which is the - default. + `--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. + 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 ------------- @@ -118,7 +172,7 @@ 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 or rsync protocol, then you +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 diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index f373ab48d4..f271d758c3 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -9,8 +9,11 @@ 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' -l [<pattern>] +'git replace' [--format=<format>] [-l [<pattern>]] DESCRIPTION ----------- @@ -49,7 +52,7 @@ $ git cat-file commit foo shows information about commit 'bar'. -The 'GIT_NO_REPLACE_OBJECTS' environment variable can be set to +The `GIT_NO_REPLACE_OBJECTS` environment variable can be set to achieve the same effect as the `--no-replace-objects` option. OPTIONS @@ -63,6 +66,36 @@ OPTIONS --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 @@ -70,12 +103,31 @@ OPTIONS Typing "git replace" without arguments, also lists all replace refs. +--format=<format>:: + When listing, use the specified <format>, which can be one of + 'short', 'medium' and 'long'. When omitted, the format + defaults to 'short'. + +FORMATS +------- + +The following format are available: + +* 'short': + <replaced sha1> +* 'medium': + <replaced sha1> -> <replacement sha1> +* 'long': + <replaced sha1> (<replaced type>) -> <replacement sha1> (<replacement type>) + CREATING REPLACEMENT OBJECTS ---------------------------- -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. +linkgit:git-hash-object[1], linkgit:git-rebase[1], and +https://github.com/newren/git-filter-repo[git-filter-repo], 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 @@ -96,11 +148,13 @@ 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] +https://github.com/newren/git-filter-repo[git-filter-repo] GIT --- diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt deleted file mode 100644 index 9ec115b9e0..0000000000 --- a/Documentation/git-repo-config.txt +++ /dev/null @@ -1,23 +0,0 @@ -git-repo-config(1) -================== - -NAME ----- -git-repo-config - Get and set repository or global options - - -SYNOPSIS --------- -[verse] -'git repo-config' ... - - -DESCRIPTION ------------ - -This is a synonym for linkgit:git-config[1]. Please refer to the -documentation of that command. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-request-pull.txt b/Documentation/git-request-pull.txt index b99681ce85..4d4392d0f8 100644 --- a/Documentation/git-request-pull.txt +++ b/Documentation/git-request-pull.txt @@ -13,22 +13,66 @@ SYNOPSIS DESCRIPTION ----------- -Summarizes the changes between two commits to the standard output, and includes -the given URL in the generated summary. +Generate a request asking your upstream project to pull changes into +their tree. The request, printed to the standard output, +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:: - Show patch text + Include patch text in the output. <start>:: - Commit to start at. + Commit to start at. This names a commit that is already in + the upstream history. <url>:: - URL to include in the summary. + The repository URL to be pulled from. <end>:: - Commit to end at; defaults to HEAD. + Commit to end at (defaults to HEAD). This names the commit + at the tip of the history you are asking to be pulled. ++ +When the repository named by `<url>` has the commit at a tip of a +ref that is different from the ref you have locally, you can use the +`<local>:<remote>` syntax, to have its local name, a colon `:`, and +its remote name. + + +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 --- diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt index a62227f84e..4cfc883378 100644 --- a/Documentation/git-rerere.txt +++ b/Documentation/git-rerere.txt @@ -24,7 +24,7 @@ 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 +You need to set the configuration variable `rerere.enabled` in order to enable this command. @@ -69,7 +69,7 @@ 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 +`gc.rerereUnresolved` and `gc.rerereResolved` configuration variables respectively. @@ -91,7 +91,7 @@ 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 checkout topic + $ git switch topic $ git merge master o---*---o---+ topic @@ -113,10 +113,10 @@ the upstream might have been advanced since the test merge `+`, in which case the final commit graph would look like this: ------------ - $ git checkout topic + $ git switch topic $ git merge master $ ... work on both topic and master branches - $ git checkout master + $ git switch master $ git merge topic o---*---o---+---o---o topic @@ -136,11 +136,11 @@ merges, you could blow away the test merge, and keep building on top of the tip before the test merge: ------------ - $ git checkout topic + $ git switch topic $ git merge master $ git reset --hard HEAD^ ;# rewind the test merge $ ... work on both topic and master branches - $ git checkout master + $ git switch master $ git merge topic o---*---o-------o---o topic @@ -205,12 +205,18 @@ development on the topic branch: ------------ you could run `git rebase master topic`, to bring yourself -up-to-date before your topic is ready to be sent upstream. +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/Documentation/git-reset.txt b/Documentation/git-reset.txt index f445cb38fa..252e2d4e47 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -8,35 +8,38 @@ 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 | --hard | --merge | --keep] [-q] [<commit>] +'git reset' [-q] [<tree-ish>] [--] <pathspec>... +'git reset' [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>] +'git reset' (--patch | -p) [<tree-ish>] [--] [<pathspec>...] +'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, nor - the current branch.) -+ -This means that `git reset <paths>` is the opposite of `git add -<paths>`. -+ -After running `git reset <paths>` to update the index entry, you can -use linkgit:git-checkout[1] to check the contents out of the index to -the working tree. -Alternatively, using linkgit:git-checkout[1] and specifying a commit, you +In the first three forms, copy entries from `<tree-ish>` to the index. +In the last 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>] [--] <pathspec>...:: +'git reset' [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]:: + These forms reset the index entries for all paths that match the + `<pathspec>` to their state at `<tree-ish>`. (It does not affect + the working tree or the current branch.) ++ +This means that `git reset <pathspec>` is the opposite of `git add +<pathspec>`. This command is equivalent to +`git restore [--source=<tree-ish>] --staged <pathspec>...`. ++ +After running `git reset <pathspec>` 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>...]:: +'git reset' (--patch | -p) [<tree-ish>] [--] [<pathspec>...]:: Interactively select hunks in the difference between the index - and <tree-ish> (defaults to HEAD). The chosen hunks are applied + 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. @@ -44,47 +47,56 @@ 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: + 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 nor 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' + 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. + 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 `<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. + 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>', +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. + different between `<commit>` and `HEAD`. + If a file that is different between `<commit>` and `HEAD` has local + changes, reset is aborted. + +--[no-]recurse-submodules:: + When the working tree is updated, using --recurse-submodules will + also recursively reset the working tree of all active submodules + according to the commit recorded in the superproject, also setting + the submodules' HEAD to be detached at that commit. -- -If you want to undo a commit other than the latest on a branch, -linkgit:git-revert[1] is your friend. +See "Reset, restore and revert" in linkgit:git[1] for the differences +between the three commands. OPTIONS @@ -92,8 +104,31 @@ OPTIONS -q:: --quiet:: - Be quiet, only report errors. - +--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. + +--pathspec-from-file=<file>:: + Pathspec is passed in `<file>` instead of commandline args. If + `<file>` is exactly `-` then standard input is used. Pathspec + elements are separated by LF or CR/LF. Pathspec elements can be + quoted as explained for the configuration variable `core.quotePath` + (see linkgit:git-config[1]). See also `--pathspec-file-nul` and + global `--literal-pathspecs`. + +--pathspec-file-nul:: + Only meaningful with `--pathspec-from-file`. Pathspec elements are + separated with NUL character and all other characters are taken + literally (including newlines and quotes). + +\--:: + Do not interpret any more arguments as options. + +<pathspec>...:: + Limits the paths affected by the operation. ++ +For more details, see the 'pathspec' entry in linkgit:gitglossary[7]. EXAMPLES -------- @@ -109,17 +144,17 @@ $ 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 sounds worthy of merging. + 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 nor 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. + 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:: + @@ -131,29 +166,29 @@ $ 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". + 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. +<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]. +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 checkout topic/wip <3> +$ 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. + 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. +<3> Switch to `topic/wip` branch and keep working. Undo commits permanently:: + @@ -162,11 +197,11 @@ $ 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.) +<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:: + @@ -183,18 +218,18 @@ $ 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. + 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. + 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. + 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:: + @@ -208,14 +243,14 @@ $ 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. + 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. + 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:: @@ -226,13 +261,13 @@ 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 checkout feature ;# you were working in "feature" branch and -$ work work work ;# got interrupted +$ git switch feature ;# you were working in "feature" branch and +$ work work work ;# got interrupted $ git commit -a -m "snapshot WIP" <1> -$ git checkout master +$ git switch master $ fix fix fix $ git commit ;# commit with real log -$ git checkout feature +$ git switch feature $ git reset --soft HEAD^ ;# go back to WIP state <2> $ git reset <3> ------------ @@ -273,21 +308,70 @@ reset it while keeping the changes in your working tree. + ------------ $ git tag start -$ git checkout -b branch1 +$ git switch -c branch1 $ edit $ git commit ... <1> $ edit -$ git checkout -b branch2 <2> +$ git switch -c branch2 <2> $ git reset --keep start <3> ------------ + -<1> This commits your first edits in branch1. +<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 checkout -b branch2 start"), but nobody is + 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". +<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 @@ -299,104 +383,120 @@ The tables below show what happens when running: git reset --option target ---------- -to reset the HEAD to another commit (`target`) with the different +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 +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 +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 local change wrt the index before -it starts, and that it writes the result out to the working tree. So if +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. +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 +`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 +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. +.... +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 --- diff --git a/Documentation/git-restore.txt b/Documentation/git-restore.txt new file mode 100644 index 0000000000..84c6c40010 --- /dev/null +++ b/Documentation/git-restore.txt @@ -0,0 +1,215 @@ +git-restore(1) +============== + +NAME +---- +git-restore - Restore working tree files + +SYNOPSIS +-------- +[verse] +'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>... +'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] --pathspec-from-file=<file> [--pathspec-file-nul] +'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, if `--staged` is given, the contents are restored from `HEAD`, +otherwise from the index. Use `--source` to restore from a different commit. + +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 contents are restored from `HEAD` if `--staged` is +given, otherwise from the index. + +-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>`. + +--recurse-submodules:: +--no-recurse-submodules:: + If `<pathspec>` names an active submodule and the restore location + includes the working tree, the submodule will only be updated if + this option is given, in which case its working tree will be + restored to the commit recorded in the superproject, and any local + modifications overwritten. If nothing (or + `--no-recurse-submodules`) is used, submodules working trees will + not be updated. Just like linkgit:git-checkout[1], this will detach + `HEAD` of the submodule. + +--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. + +--pathspec-from-file=<file>:: + Pathspec is passed in `<file>` instead of commandline args. If + `<file>` is exactly `-` then standard input is used. Pathspec + elements are separated by LF or CR/LF. Pathspec elements can be + quoted as explained for the configuration variable `core.quotePath` + (see linkgit:git-config[1]). See also `--pathspec-file-nul` and + global `--literal-pathspecs`. + +--pathspec-file-nul:: + Only meaningful with `--pathspec-from-file`. Pathspec elements are + separated with NUL character and all other characters are taken + literally (including newlines and quotes). + +\--:: + Do not interpret any more arguments as options. + +<pathspec>...:: + Limits the paths affected by the operation. ++ +For more details, see the 'pathspec' entry in linkgit:gitglossary[7]. + +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/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt index 045b37b82e..5da66232dc 100644 --- a/Documentation/git-rev-list.txt +++ b/Documentation/git-rev-list.txt @@ -9,95 +9,13 @@ 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=(local|relative|default|iso|rfc|short) ] - [ [\--objects | \--objects-edge] [ \--unpacked ] ] - [ \--pretty | \--header ] - [ \--bisect ] - [ \--bisect-vars ] - [ \--bisect-all ] - [ \--merge ] - [ \--reverse ] - [ \--walk-reflogs ] - [ \--no-walk ] [ \--do-walk ] - <commit>... [ \-- <paths>... ] +'git rev-list' [<options>] <commit>... [[--] <path>...] 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 ------------------------------------------------------------------------ +:git-rev-list: 1 +include::rev-list-description.txt[] 'rev-list' is a very essential Git command, since it provides the ability to build and traverse commit ancestry graphs. For diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index d068a65377..19b12b6d43 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -9,7 +9,7 @@ git-rev-parse - Pick out and massage parameters SYNOPSIS -------- [verse] -'git rev-parse' [ --option ] <args>... +'git rev-parse' [<options>] <args>... DESCRIPTION ----------- @@ -50,6 +50,10 @@ Options for --parseopt the first non-option argument. This can be used to parse sub-commands that take options themselves. +--stuck-long:: + Only meaningful in `--parseopt` mode. Output the options in their + long form if available, and with their arguments stuck. + Options for Filtering ~~~~~~~~~~~~~~~~~~~~~ @@ -87,7 +91,8 @@ repository. For example: ---- prefix=$(git rev-parse --show-prefix) cd "$(git rev-parse --show-toplevel)" -eval "set -- $(git rev-parse --sq --prefix "$prefix" "$@")" +# rev-parse provides the -- needed for 'set' +eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")" ---- --verify:: @@ -98,7 +103,7 @@ eval "set -- $(git rev-parse --sq --prefix "$prefix" "$@")" + 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 "^{type}" peeling operator to the parameter. +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` @@ -110,6 +115,7 @@ can be used. 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 @@ -120,6 +126,12 @@ can be used. '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 @@ -130,19 +142,13 @@ can be used. The option core.warnAmbiguousRefs is used to select the strict abbreviation mode. ---short:: ---short=number:: - Instead of outputting the full SHA-1 values of object names try to - abbreviate them to a shorter unique name. When no length is specified - 7 is used. The minimum length is 4. - --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 + 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 @@ -173,6 +179,20 @@ shown. If the pattern does not contain a globbing character (`?`, character (`?`, `*`, or `[`), it is turned into a prefix match by appending `/*`. +--exclude=<glob-pattern>:: + Do not include refs matching '<glob-pattern>' that the next `--all`, + `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise + consider. Repetitions of this option accumulate exclusion patterns + up to the next `--all`, `--branches`, `--tags`, `--remotes`, or + `--glob` option (other options or arguments do not clear + 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 @@ -197,6 +217,13 @@ 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". @@ -208,12 +235,22 @@ print a message to stderr and exit with nonzero status. --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 @@ -225,7 +262,25 @@ print a message to stderr and exit with nonzero status. directory. --show-toplevel:: - Show the absolute path of the top-level directory. + Show the absolute path of the top-level directory of the working + tree. If there is no working tree, report an error. + +--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. + +--show-object-format[=(storage|input|output)]:: + Show the object format (hash algorithm) used for the repository + for storage inside the `.git` directory, input, or output. For + input, multiple algorithms may be printed, space-separated. + If not specified, the default is "storage". + Other Options ~~~~~~~~~~~~~ @@ -266,26 +321,28 @@ Input Format 'git rev-parse --parseopt' input format is fully text based. It has two parts, separated by a line that contains only `--`. The lines before the separator -(should be more than one) are used for the usage. +(should be one or more) are used for the usage. The lines after the separator describe the options. Each line of options has this format: ------------ -<opt_spec><flags>* SP+ help LF +<opt-spec><flags>*<arg-hint>? SP+ help LF ------------ -`<opt_spec>`:: +`<opt-spec>`:: its format is the short option character, then the long option name separated by a comma. Both parts are not required, though at least one - is necessary. `h,help`, `dry-run` and `f` are all three correct - `<opt_spec>`. + 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 is optional (though its use is discouraged). + * Use `?` to mean that the option takes an optional argument. You + probably want to use the `--stuck-long` mode to be able to + unambiguously parse the optional argument. * Use `*` to mean that this option should not be listed in the usage generated for the `-h` argument. It's shown for `--help-all` as @@ -293,6 +350,12 @@ Each line of options has this format: * Use `!` to not make the corresponding negated long option available. +`<arg-hint>`:: + `<arg-hint>`, if specified, is used as a name of the argument in the + help output, for options that take arguments. `<arg-hint>` is + terminated by the first whitespace. It is customary to use a + dash to separate words in a multi-word argument hint. + The remainder of the line, after stripping the spaces, is used as the help associated to the option. @@ -305,7 +368,7 @@ Example ------------ OPTS_SPEC="\ -some-command [options] <args>... +some-command [<options>] <args>... some-command does foo and bar! -- @@ -313,6 +376,8 @@ h,help show the help foo some nifty option --foo bar= some cool option --bar with an argument +baz=arg another cool option --baz with a named argument +qux?path qux may take a path argument but has meaning by itself An option group Header C? option C with an optional argument" @@ -320,6 +385,28 @@ C? option C with an optional argument" eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)" ------------ + +Usage text +~~~~~~~~~~ + +When `"$@"` is `-h` or `--help` in the above example, the following +usage text would be shown: + +------------ +usage: some-command [<options>] <args>... + + some-command does foo and bar! + + -h, --help show the help + --foo some nifty option --foo + --bar ... some cool option --bar with an argument + --baz <arg> another cool option --baz with a named argument + --qux[=<path>] qux may take a path argument but has meaning by itself + +An option group Header + -C[...] option C with an optional argument +------------ + SQ-QUOTE -------- diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt index 2de67a5496..044276e9da 100644 --- a/Documentation/git-revert.txt +++ b/Documentation/git-revert.txt @@ -8,10 +8,8 @@ git-revert - Revert some existing commits SYNOPSIS -------- [verse] -'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] <commit>... -'git revert' --continue -'git revert' --quit -'git revert' --abort +'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] [-S[<keyid>]] <commit>... +'git revert' (--continue | --skip | --abort | --quit) DESCRIPTION ----------- @@ -24,12 +22,15 @@ 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 +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-checkout[1], specifically the `git checkout -<commit> -- <filename>` syntax. Take care with these alternatives as +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>...:: @@ -37,7 +38,7 @@ OPTIONS 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' + default, see linkgit:git-rev-list[1] and its `--no-walk` option. -e:: @@ -66,6 +67,13 @@ more details. 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 @@ -80,9 +88,19 @@ more details. This is useful when reverting more than one commits' effect to your index in a row. +-S[<keyid>]:: +--gpg-sign[=<keyid>]:: +--no-gpg-sign:: + 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` is useful to + countermand both `commit.gpgSign` configuration variable, and + earlier `--gpg-sign`. + -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. @@ -94,6 +112,11 @@ effect to your index in a row. 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[] diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt index 9d731b453d..ab750367fd 100644 --- a/Documentation/git-rm.txt +++ b/Documentation/git-rm.txt @@ -8,16 +8,18 @@ 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>... +'git rm' [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] + [--quiet] [--pathspec-from-file=<file> [--pathspec-file-nul]] + [--] [<pathspec>...] 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, +Remove files matching pathspec 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, @@ -26,15 +28,20 @@ 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. +<pathspec>...:: + Files to remove. 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. ++ +The command removes only the paths that are known to Git. ++ +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`. ++ +For more details, see the 'pathspec' entry in linkgit:gitglossary[7]. -f:: --force:: @@ -68,19 +75,19 @@ OPTIONS `git rm` normally outputs one line (in the form of an `rm` command) for each file removed. This option suppresses that output. +--pathspec-from-file=<file>:: + Pathspec is passed in `<file>` instead of commandline args. If + `<file>` is exactly `-` then standard input is used. Pathspec + elements are separated by LF or CR/LF. Pathspec elements can be + quoted as explained for the configuration variable `core.quotePath` + (see linkgit:git-config[1]). See also `--pathspec-file-nul` and + global `--literal-pathspecs`. -DISCUSSION ----------- +--pathspec-file-nul:: + Only meaningful with `--pathspec-from-file`. Pathspec elements are + separated with NUL character and all other characters are taken + literally (including newlines and quotes). -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 -------------------------------------------------------- @@ -140,20 +147,21 @@ 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 fail - no matter if forced -or not - 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). +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 +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. +work tree without committing the removal, use linkgit:git-submodule[1] `deinit` +instead. Also see linkgit:gitsubmodules[7] for details on submodule removal. EXAMPLES -------- @@ -170,6 +178,15 @@ of files and subdirectories under the `Documentation/` directory. (i.e. you are listing the files explicitly), it does not remove `subdir/git-foo.sh`. +BUGS +---- +Each time a superproject update removes a populated submodule +(e.g. when switching between commits before and after the removal) a +stale submodule checkout will remain in the old location. Removing the +old directory is only safe when it uses a gitfile, as otherwise the +history of the submodule will be deleted too. This step will be +obsolete when recursive submodule update has been implemented. + SEE ALSO -------- linkgit:git-add[1] diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index f0e57a597b..0a69810147 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -9,7 +9,8 @@ git-send-email - Send a collection of patches as emails SYNOPSIS -------- [verse] -'git send-email' [options] <file|directory|rev-list options>... +'git send-email' [<options>] <file|directory|rev-list options>... +'git send-email' --dump-aliases DESCRIPTION @@ -20,7 +21,7 @@ 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 by command line options. If not +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. @@ -32,7 +33,7 @@ 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 + 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. @@ -46,49 +47,54 @@ 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'. + of `sendemail.annotate`. See the CONFIGURATION section for + `sendemail.multiEdit`. ---bcc=<address>:: +--bcc=<address>,...:: Specify a "Bcc:" value for each email. Default is the value of - 'sendemail.bcc'. + `sendemail.bcc`. + -The --bcc option must be repeated for each user you want on the bcc list. +This option may be specified multiple times. ---cc=<address>:: +--cc=<address>,...:: Specify a starting "Cc:" value for each email. - Default is the value of 'sendemail.cc'. + Default is the value of `sendemail.cc`. + -The --cc option must be repeated for each user you want on the cc list. +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 +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, +(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'. +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 + 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. + 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 @@ -110,13 +116,13 @@ is not set, this will be prompted for. Only necessary if --compose is also set. If --compose is not set, this will be prompted for. ---to=<address>:: +--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, + value of the `sendemail.to` configuration value; if that is unspecified, and --to-cmd is not specified, this will be prompted for. + -The --to option must be repeated for each user you want on the to list. +This option may be specified multiple times. --8bit-encoding=<encoding>:: When encountering a non-ASCII message or subject that does not @@ -131,6 +137,23 @@ Note that no attempts whatsoever are made to validate the 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 ~~~~~~~ @@ -141,42 +164,60 @@ Sending 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 + `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'. + `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'. + `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. + 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 +`--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 `/usr/sbin/sendmail` or - `/usr/lib/sendmail` if such program is available, or - `localhost` otherwise. + 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 @@ -184,11 +225,11 @@ a password is obtained using 'git-credential'. 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. + `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' + Default value can be specified by the `sendemail.smtpServerOption` configuration option. + The --smtp-server-option option must be repeated for each option you want @@ -199,14 +240,19 @@ must be used for each option. Legacy alias for '--smtp-encryption ssl'. --smtp-ssl-cert-path:: - Path to ca-certificates (either a directory or a single file). - Set it to an empty string to disable certificate verification. - Defaults to the value set to the 'sendemail.smtpsslcertpath' - configuration variable, if set, or `/etc/ssl/certs` otherwise. + 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'), + 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:: @@ -214,9 +260,32 @@ must be used for each option. 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. @@ -227,52 +296,67 @@ Automating 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. + 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' + 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'. + 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 + 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 +- '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). + 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' +- '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 +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 + Default is the value of `sendemail.suppressFrom` configuration value; if that is unspecified, default to --no-suppress-from. --[no-]thread:: @@ -284,7 +368,7 @@ specified, as well as 'body' if --no-signed-off-cc is specified. + 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, +`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 @@ -309,7 +393,7 @@ Administering - 'auto' is equivalent to 'cc' + 'compose' -- + -Default is the value of 'sendemail.confirm' configuration value; if that +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'. @@ -318,8 +402,8 @@ have been specified, in which case default to 'compose'. --[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 + 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:: @@ -331,51 +415,88 @@ have been specified, in which case default to 'compose'. Currently, validation means the following: + -- - * Warn of patches that contain lines longer than 998 characters; this - is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt. + * 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'. +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:: +sendemail.aliasesFile:: To avoid typing long email addresses, point this to one or more - email aliases files. You must also supply 'sendemail.aliasfiletype'. + 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'. +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:: +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 + 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' + one of 'always', 'never', 'cc', 'compose', or 'auto'. See `--confirm` in the previous section for the meaning of these values. -EXAMPLE -------- +EXAMPLES +-------- Use gmail as the smtp server ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To use 'git send-email' to send your patches through the GMail SMTP server, edit ~/.gitconfig to specify your account settings: - [sendemail] - smtpencryption = tls - smtpserver = smtp.gmail.com - smtpuser = yourname@gmail.com - smtpserverport = 587 +---- +[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: @@ -384,8 +505,17 @@ following commands: $ edit outgoing/0000-* $ git send-email outgoing/* -Note: the following perl modules are required - Net::SMTP::SSL, MIME::Base64 and Authen::SASL +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 -------- diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt index dc3a568baa..44fd146b91 100644 --- a/Documentation/git-send-pack.txt +++ b/Documentation/git-send-pack.txt @@ -9,7 +9,10 @@ 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] [<host>:]<directory> [<ref>...] +'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 ----------- @@ -29,12 +32,22 @@ OPTIONS a directory on the default $PATH. --exec=<git-receive-pack>:: - Same as \--receive-pack=<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. @@ -52,6 +65,28 @@ OPTIONS 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 @@ -64,20 +99,21 @@ OPTIONS The remote refs to update. -Specifying the Refs +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 +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 +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, it can be either a +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>'. @@ -104,13 +140,13 @@ name. See linkgit:git-rev-parse[1]. 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 +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. +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. diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt index 4f67c4cde6..8632612c31 100644 --- a/Documentation/git-sh-setup.txt +++ b/Documentation/git-sh-setup.txt @@ -41,7 +41,7 @@ usage:: die with the usage message. set_reflog_action:: - Set GIT_REFLOG_ACTION environment to a given string (typically + 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 diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt index c35051ba58..11361f33e9 100644 --- a/Documentation/git-shell.txt +++ b/Documentation/git-shell.txt @@ -24,7 +24,7 @@ named `git-shell-commands` in the user's home directory. COMMANDS -------- -'git shell' accepts the following commands after the '-c' option: +'git shell' accepts the following commands after the `-c` option: 'git receive-pack <argument>':: 'git upload-pack <argument>':: @@ -43,7 +43,7 @@ directory. INTERACTIVE USE --------------- -By default, the commands above can be executed only with the '-c' +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' @@ -62,11 +62,11 @@ permissions. If a `no-interactive-login` command exists, then it is run and the interactive shell is aborted. -EXAMPLE -------- +EXAMPLES +-------- To disable interactive logins, displaying a greeting instead: -+ + ---------------- $ chsh -s /usr/bin/git-shell $ mkdir $HOME/git-shell-commands @@ -79,6 +79,22 @@ 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), diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index 31af7f2736..a72ea7f7ba 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -8,8 +8,8 @@ git-shortlog - Summarize 'git log' output SYNOPSIS -------- [verse] +'git shortlog' [<options>] [<revision range>] [[--] <path>...] git log --pretty=short | 'git shortlog' [<options>] -'git shortlog' [<options>] [<revision range>] [[\--] <path>...] DESCRIPTION ----------- @@ -47,6 +47,10 @@ OPTIONS 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 @@ -65,13 +69,16 @@ them. ways to spell <revision range>, see the "Specifying Ranges" section of linkgit:gitrevisions[7]. -[\--] <path>...:: +[--] <path>...:: Consider only commits that are enough to explain how the files that match the specified paths came to be. + -Paths may need to be prefixed with "\-- " to separate them from +Paths may need to be prefixed with `--` to separate them from options or the revision range, when confusion arises. +:git-shortlog: 1 +include::rev-list-options.txt[] + MAPPING AUTHORS --------------- diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt index a515648ab0..5cc2fcefba 100644 --- a/Documentation/git-show-branch.txt +++ b/Documentation/git-show-branch.txt @@ -19,13 +19,13 @@ DESCRIPTION ----------- Shows the commit ancestry graph starting from the commits named -with <rev>s or <globs>s (or all refs under refs/heads +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> nor <glob> is given on the command line. +no <rev> or <glob> is given on the command line. OPTIONS @@ -60,7 +60,7 @@ OPTIONS are shown before their parents). --date-order:: - This option is similar to '--topo-order' in the sense that no + 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. @@ -167,14 +167,14 @@ $ git show-branch master fixes mhf ------------------------------------------------ These three branches all forked from a common commit, [master], -whose commit message is "Add {apostrophe}git show-branch{apostrophe}". +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". -EXAMPLE -------- +EXAMPLES +-------- If you keep your primary branches immediately under `refs/heads`, and topic branches in subdirectories of diff --git a/Documentation/git-show-index.txt b/Documentation/git-show-index.txt index fbdc8adae5..39b1d8eaa1 100644 --- a/Documentation/git-show-index.txt +++ b/Documentation/git-show-index.txt @@ -9,17 +9,41 @@ git-show-index - Show packed archive index SYNOPSIS -------- [verse] -'git show-index' < idx-file +'git show-index' [--object-format=<hash-algorithm>] DESCRIPTION ----------- -Reads given idx file for packed Git archive created with -'git pack-objects' command, and dumps its contents. +Read the `.idx` file for a Git packfile (created with +linkgit:git-pack-objects[1] or linkgit:git-index-pack[1]) from the +standard input, and dump its contents. The output consists of one object +per line, with each line containing two or three space-separated +columns: -The information it outputs is subset of what you can get from -'git verify-pack -v'; this command only shows the packfile -offset and SHA-1 of each object. + - the first column is the offset in bytes of the object within the + corresponding packfile + + - the second column is the object id of the object + + - if the index version is 2 or higher, the third column contains the + CRC32 of the object data + +The objects are output in the order in which they are found in the index +file, which should be (in a correctly constructed file) sorted by object +id. + +Note that you can get more information on a packfile by calling +linkgit:git-verify-pack[1]. However, as this command considers only the +index file itself, it's both faster and more flexible. + +OPTIONS +------- + +--object-format=<hash-algorithm>:: + Specify the given object format (hash algorithm) for the index file. The + valid values are 'sha1' and (if enabled) 'sha256'. The default is the + algorithm for the current repository (set by `extensions.objectFormat`), or + 'sha1' if no value is set or outside a repository.. GIT --- diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt index b0a309b117..ab4d271925 100644 --- a/Documentation/git-show-ref.txt +++ b/Documentation/git-show-ref.txt @@ -11,7 +11,7 @@ SYNOPSIS 'git show-ref' [-q|--quiet] [--verify] [--head] [-d|--dereference] [-s|--hash[=<n>]] [--abbrev[=<n>]] [--tags] [--heads] [--] [<pattern>...] -'git show-ref' --exclude-existing[=<pattern>] < ref-list +'git show-ref' --exclude-existing[=<pattern>] DESCRIPTION ----------- @@ -23,8 +23,9 @@ particular ref exists. By default, shows the tags, heads, and remote refs. -The --exclude-existing form is a filter that does the inverse, it shows the -refs from stdin that don't exist in the local repository. +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. @@ -36,8 +37,8 @@ OPTIONS Show the HEAD reference, even if it would normally be filtered out. ---tags:: --heads:: +--tags:: Limit to "refs/heads" and "refs/tags", respectively. These options are not mutually exclusive; when given both, references stored in @@ -59,7 +60,7 @@ OPTIONS 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. + message if `--quiet` was not specified. --abbrev[=<n>]:: @@ -69,7 +70,7 @@ OPTIONS -q:: --quiet:: - Do not print any results to stdout. When combined with '--verify' this + 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>]:: @@ -89,7 +90,7 @@ OPTIONS 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' nor + 'refs/tags/jedi/master' but not 'refs/heads/mymaster' or 'refs/remotes/master/jedi'. OUTPUT @@ -119,8 +120,8 @@ $ git show-ref --heads --hash ... ----------------------------------------------------------------------------- -EXAMPLE -------- +EXAMPLES +-------- To show all references called "master", whether tags or heads or anything else, and regardless of how deep in the reference naming hierarchy they are, @@ -133,7 +134,7 @@ use: 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: +When using the `--verify` flag, the command requires an exact path: ----------------------------------------------------------------------------- git show-ref --verify refs/heads/master @@ -175,6 +176,7 @@ FILES SEE ALSO -------- +linkgit:git-for-each-ref[1], linkgit:git-ls-remote[1], linkgit:git-update-ref[1], linkgit:gitrepository-layout[5] diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt index 4e617e6979..fcf528c1b3 100644 --- a/Documentation/git-show.txt +++ b/Documentation/git-show.txt @@ -9,7 +9,7 @@ git-show - Show various types of objects SYNOPSIS -------- [verse] -'git show' [options] <object>... +'git show' [<options>] [<object>...] DESCRIPTION ----------- @@ -22,7 +22,7 @@ presents the merge commit in a special format as produced by 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). +with --name-only). For plain blobs, it shows the plain contents. @@ -35,7 +35,7 @@ This manual page describes only the most frequently used options. OPTIONS ------- <object>...:: - The names of objects to show. + 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]. @@ -77,7 +77,7 @@ EXAMPLES Concatenates the contents of said Makefiles in the head of the branch `master`. -Discussion +DISCUSSION ---------- include::i18n.txt[] diff --git a/Documentation/git-sparse-checkout.txt b/Documentation/git-sparse-checkout.txt new file mode 100644 index 0000000000..a0eeaeb02e --- /dev/null +++ b/Documentation/git-sparse-checkout.txt @@ -0,0 +1,239 @@ +git-sparse-checkout(1) +====================== + +NAME +---- +git-sparse-checkout - Initialize and modify the sparse-checkout +configuration, which reduces the checkout to a set of paths +given by a list of patterns. + + +SYNOPSIS +-------- +[verse] +'git sparse-checkout <subcommand> [options]' + + +DESCRIPTION +----------- + +Initialize and modify the sparse-checkout configuration, which reduces +the checkout to a set of paths given by a list of patterns. + +THIS COMMAND IS EXPERIMENTAL. ITS BEHAVIOR, AND THE BEHAVIOR OF OTHER +COMMANDS IN THE PRESENCE OF SPARSE-CHECKOUTS, WILL LIKELY CHANGE IN +THE FUTURE. + + +COMMANDS +-------- +'list':: + Describe the patterns in the sparse-checkout file. + +'init':: + Enable the `core.sparseCheckout` setting. If the + sparse-checkout file does not exist, then populate it with + patterns that match every file in the root directory and + no other directories, then will remove all directories tracked + by Git. Add patterns to the sparse-checkout file to + repopulate the working directory. ++ +To avoid interfering with other worktrees, it first enables the +`extensions.worktreeConfig` setting and makes sure to set the +`core.sparseCheckout` setting in the worktree-specific config file. ++ +When `--cone` is provided, the `core.sparseCheckoutCone` setting is +also set, allowing for better performance with a limited set of +patterns (see 'CONE PATTERN SET' below). + +'set':: + Write a set of patterns to the sparse-checkout file, as given as + a list of arguments following the 'set' subcommand. Update the + working directory to match the new patterns. Enable the + core.sparseCheckout config setting if it is not already enabled. ++ +When the `--stdin` option is provided, the patterns are read from +standard in as a newline-delimited list instead of from the arguments. ++ +When `core.sparseCheckoutCone` is enabled, the input list is considered a +list of directories instead of sparse-checkout patterns. The command writes +patterns to the sparse-checkout file to include all files contained in those +directories (recursively) as well as files that are siblings of ancestor +directories. The input format matches the output of `git ls-tree --name-only`. +This includes interpreting pathnames that begin with a double quote (") as +C-style quoted strings. + +'add':: + Update the sparse-checkout file to include additional patterns. + By default, these patterns are read from the command-line arguments, + but they can be read from stdin using the `--stdin` option. When + `core.sparseCheckoutCone` is enabled, the given patterns are interpreted + as directory names as in the 'set' subcommand. + +'reapply':: + Reapply the sparsity pattern rules to paths in the working tree. + Commands like merge or rebase can materialize paths to do their + work (e.g. in order to show you a conflict), and other + sparse-checkout commands might fail to sparsify an individual file + (e.g. because it has unstaged changes or conflicts). In such + cases, it can make sense to run `git sparse-checkout reapply` later + after cleaning up affected paths (e.g. resolving conflicts, undoing + or committing changes, etc.). + +'disable':: + Disable the `core.sparseCheckout` config setting, and restore the + working directory to include all files. Leaves the sparse-checkout + file intact so a later 'git sparse-checkout init' command may + return the working directory to the same state. + +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. If +the skip-worktree bit is set, then the file is ignored in the working +directory. Git will not populate the contents of those files, which +makes a sparse checkout helpful when working in a repository with many +files, but only a few are important to the current user. + +The `$GIT_DIR/info/sparse-checkout` file is used to define the +skip-worktree reference bitmap. When Git updates the working +directory, it updates the skip-worktree bits in the index based +on this file. The files matching the patterns in the file will +appear in the working directory, and the rest will not. + +To enable the sparse-checkout feature, run `git sparse-checkout init` to +initialize a simple sparse-checkout file and enable the `core.sparseCheckout` +config setting. Then, run `git sparse-checkout set` to modify the patterns in +the sparse-checkout file. + +To repopulate the working directory with all files, use the +`git sparse-checkout disable` command. + + +FULL PATTERN SET +---------------- + +By default, the sparse-checkout file uses the same syntax as `.gitignore` +files. + +While `$GIT_DIR/info/sparse-checkout` is usually used to specify what +files are included, you can also specify what files are _not_ included, +using negative patterns. For example, to remove the file `unwanted`: + +---------------- +/* +!unwanted +---------------- + + +CONE PATTERN SET +---------------- + +The full pattern set allows for arbitrary pattern matches and complicated +inclusion/exclusion rules. These can result in O(N*M) pattern matches when +updating the index, where N is the number of patterns and M is the number +of paths in the index. To combat this performance issue, a more restricted +pattern set is allowed when `core.sparseCheckoutCone` is enabled. + +The accepted patterns in the cone pattern set are: + +1. *Recursive:* All paths inside a directory are included. + +2. *Parent:* All files immediately inside a directory are included. + +In addition to the above two patterns, we also expect that all files in the +root directory are included. If a recursive pattern is added, then all +leading directories are added as parent patterns. + +By default, when running `git sparse-checkout init`, the root directory is +added as a parent pattern. At this point, the sparse-checkout file contains +the following patterns: + +---------------- +/* +!/*/ +---------------- + +This says "include everything in root, but nothing two levels below root." + +When in cone mode, the `git sparse-checkout set` subcommand takes a list of +directories instead of a list of sparse-checkout patterns. In this mode, +the command `git sparse-checkout set A/B/C` sets the directory `A/B/C` as +a recursive pattern, the directories `A` and `A/B` are added as parent +patterns. The resulting sparse-checkout file is now + +---------------- +/* +!/*/ +/A/ +!/A/*/ +/A/B/ +!/A/B/*/ +/A/B/C/ +---------------- + +Here, order matters, so the negative patterns are overridden by the positive +patterns that appear lower in the file. + +If `core.sparseCheckoutCone=true`, then Git will parse the sparse-checkout file +expecting patterns of these types. Git will warn if the patterns do not match. +If the patterns do match the expected format, then Git will use faster hash- +based algorithms to compute inclusion in the sparse-checkout. + +In the cone mode case, the `git sparse-checkout list` subcommand will list the +directories that define the recursive patterns. For the example sparse-checkout +file above, the output is as follows: + +-------------------------- +$ git sparse-checkout list +A/B/C +-------------------------- + +If `core.ignoreCase=true`, then the pattern-matching algorithm will use a +case-insensitive check. This corrects for case mismatched filenames in the +'git sparse-checkout set' command to reflect the expected cone in the working +directory. + + +SUBMODULES +---------- + +If your repository contains one or more submodules, then submodules +are populated based on interactions with the `git submodule` command. +Specifically, `git submodule init -- <path>` will ensure the submodule +at `<path>` is present, while `git submodule deinit [-f] -- <path>` +will remove the files for the submodule at `<path>` (including any +untracked files, uncommitted changes, and unpushed history). Similar +to how sparse-checkout removes files from the working tree but still +leaves entries in the index, deinitialized submodules are removed from +the working directory but still have an entry in the index. + +Since submodules may have unpushed changes or untracked files, +removing them could result in data loss. Thus, changing sparse +inclusion/exclusion rules will not cause an already checked out +submodule to be removed from the working copy. Said another way, just +as `checkout` will not cause submodules to be automatically removed or +initialized even when switching between branches that remove or add +submodules, using `sparse-checkout` to reduce or expand the scope of +"interesting" files will not cause submodules to be automatically +deinitialized or initialized either. + +Further, the above facts mean that there are multiple reasons that +"tracked" files might not be present in the working copy: sparsity +pattern application from sparse-checkout, and submodule initialization +state. Thus, commands like `git grep` that work on tracked files in +the working copy may return results that are limited by either or both +of these restrictions. + + +SEE ALSO +-------- + +linkgit:git-read-tree[1] +linkgit:gitignore[5] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-stage.txt b/Documentation/git-stage.txt index ba3fe0d7f5..25bcda936d 100644 --- a/Documentation/git-stage.txt +++ b/Documentation/git-stage.txt @@ -1,5 +1,5 @@ git-stage(1) -============== +============ NAME ---- diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index db7e803038..31f1beb65b 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -9,12 +9,14 @@ SYNOPSIS -------- [verse] 'git stash' list [<options>] -'git stash' show [<stash>] +'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' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] - [-u|--include-untracked] [-a|--all] [<message>]] +'git stash' [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] + [-u|--include-untracked] [-a|--all] [-m|--message <message>] + [--pathspec-from-file=<file> [--pathspec-file-nul]] + [--] [<pathspec>...]] 'git stash' clear 'git stash' create [<message>] 'git stash' store [-m|--message <message>] [-q|--quiet] <commit> @@ -30,7 +32,7 @@ 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 save`. +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. @@ -39,45 +41,38 @@ The latest stash you created is stored in `refs/stash`; older stashes are found in the reflog of this reference and can be named using the usual reflog syntax (e.g. `stash@{0}` is the most recently created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}` -is also possible). +is also possible). Stashes may also be referenced by specifying just the +stash index (e.g. the integer `n` is equivalent to `stash@{n}`). -OPTIONS -------- +COMMANDS +-------- -save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]:: +push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [-m|--message <message>] [--pathspec-from-file=<file> [--pathspec-file-nul]] [--] [<pathspec>...]:: - Save your local modifications to a new 'stash', and run `git reset - --hard` to revert them. The <message> part is optional and gives - the description along with the stashed state. For quickly making - a snapshot, you can omit _both_ "save" and <message>, but giving - only <message> does not trigger this action to prevent a misspelled - subcommand from making an unwanted stash. -+ -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. + 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. + -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. +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 pathspec elements, +which are allowed after a double hyphen `--` for disambiguation. + +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 pathspec. + Instead, all non-option arguments are concatenated to form the stash + message. list [<options>]:: - List the stashes that you currently have. Each 'stash' is listed - with its name (e.g. `stash@{0}` is the latest stash, `stash@{1}` is + 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 - stash was made, and a short description of the commit the stash was + entry was made, and a short description of the commit the entry was based on. + ---------------------------------------------------------------- @@ -88,38 +83,33 @@ 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 [<stash>]:: +show [<options>] [<stash>]:: - Show the changes recorded in the stash as a diff between the - stashed state and its original parent. When no `<stash>` is given, - 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 stash in patch form). + 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. + 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 save`. The working directory must + 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 save` or `stash create`. + `stash push` or `stash create`. branch <branchname> [<stash>]:: @@ -127,48 +117,137 @@ branch <branchname> [<stash>]:: 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. + `stash@{<revision>}`, it then drops the `<stash>`. + -This is useful if the branch on which you ran `git stash save` has +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 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. +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 stashed states. Note that those states will then + 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 stashed state from the stash list. 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>}`. + Remove a single stash entry from the list of stash entries. create:: - Create a stash (which is a regular commit object) and return its - object name, without storing it anywhere in the ref namespace. + 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 "save" above. + 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 "save" above. + probably not the command you want to use; see "push" above. + +OPTIONS +------- +-a:: +--all:: + This option is only valid for `push` and `save` commands. ++ +All ignored and untracked files are also stashed and then cleaned +up with `git clean`. + +-u:: +--include-untracked:: + This option is only valid for `push` and `save` commands. ++ +All untracked files are also stashed and then cleaned up with +`git clean`. + +--index:: + This option is only valid for `pop` and `apply` commands. ++ +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). + +-k:: +--keep-index:: +--no-keep-index:: + This option is only valid for `push` and `save` commands. ++ +All changes already added to the index are left intact. + +-p:: +--patch:: + This option is only valid for `push` and `save` commands. ++ +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. + +--pathspec-from-file=<file>:: + This option is only valid for `push` command. ++ +Pathspec is passed in `<file>` instead of commandline args. If +`<file>` is exactly `-` then standard input is used. Pathspec +elements are separated by LF or CR/LF. Pathspec elements can be +quoted as explained for the configuration variable `core.quotePath` +(see linkgit:git-config[1]). See also `--pathspec-file-nul` and +global `--literal-pathspecs`. + +--pathspec-file-nul:: + This option is only valid for `push` command. ++ +Only meaningful with `--pathspec-from-file`. Pathspec elements are +separated with NUL character and all other characters are taken +literally (including newlines and quotes). + +-q:: +--quiet:: + This option is only valid for `apply`, `drop`, `pop`, `push`, + `save`, `store` commands. ++ +Quiet, suppress feedback messages. + +\--:: + This option is only valid for `push` command. ++ +Separates pathspec from options for disambiguation purposes. + +<pathspec>...:: + This option is only valid for `push` command. ++ +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. ++ +For more details, see the 'pathspec' entry in linkgit:gitglossary[7]. + +<stash>:: + This option is only valid for `apply`, `branch`, `drop`, `pop`, + `show` commands. ++ +A reference of the form `stash@{<revision>}`. When no `<stash>` is +given, the latest stash is assumed (that is, `stash@{0}`). DISCUSSION ---------- -A stash 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 stash was created. The tree of the second parent records the -state of the index when the stash is made, and it is made a child of +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 @@ -213,12 +292,12 @@ return to your original branch to make the emergency fix, like this: + ---------------------------------------------------------------- # ... hack hack hack ... -$ git checkout -b my_wip +$ git switch -c my_wip $ git commit -a -m "WIP" -$ git checkout master +$ git switch master $ edit emergency fix $ git commit -a -m "Fix in a hurry" -$ git checkout my_wip +$ git switch my_wip $ git reset --soft HEAD^ # ... continue hacking ... ---------------------------------------------------------------- @@ -236,14 +315,14 @@ $ git stash pop Testing partial commits:: -You can use `git stash save --keep-index` when you want to make two or +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 save --keep-index # save all other changes to the stash +$ 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 @@ -252,12 +331,12 @@ $ edit/build/test remaining parts $ git commit foo -m 'Remaining parts' ---------------------------------------------------------------- -Recovering stashes that were cleared/dropped erroneously:: +Recovering stash entries that were cleared/dropped erroneously:: -If you mistakenly drop or clear stashes, they cannot be recovered +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 stashes that are still in your -repository, but not reachable any more: +following incantation to get a list of stash entries that are still in +your repository, but not reachable any more: + ---------------------------------------------------------------- git fsck --unreachable | @@ -271,7 +350,8 @@ SEE ALSO linkgit:git-checkout[1], linkgit:git-commit[1], linkgit:git-reflog[1], -linkgit:git-reset[1] +linkgit:git-reset[1], +linkgit:git-switch[1] GIT --- diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index a4acaa038c..7731b45f07 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -32,37 +32,57 @@ OPTIONS --branch:: Show the branch and tracking info even in short-format. ---porcelain:: +--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 optional (defaults to 'all'), and is used to -specify the handling of 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. You can use `no` to have `git status` +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 @@ -77,14 +97,35 @@ configuration variable documented in linkgit:git-config[1]. 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). + `status.submoduleSummary` is set). ---ignored:: +--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` output format if no other format is given. + the `--porcelain=v1` output format if no other format is given. --column[=<options>]:: --no-column:: @@ -93,11 +134,28 @@ configuration variable documented in linkgit:git-config[1]. 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, and all the output lines are prefixed with '#'. +template comment. The default, long format, is designed to be human readable, verbose and descriptive. Its contents and format are subject to change at any time. @@ -110,14 +168,15 @@ the status.relativePaths config option below. Short Format ~~~~~~~~~~~~ -In the short-format, the status of each path is shown as +In the short-format, the status of each path is shown as one of these +forms - XY PATH1 -> PATH2 + XY PATH + XY ORIG_PATH -> PATH -where `PATH1` is the path in the `HEAD`, and the " `-> PATH2`" part is -shown only when `PATH1` corresponds to a different path in the -index/worktree (i.e. the file is renamed). The 'XY' is a two-letter -status code. +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 @@ -125,7 +184,7 @@ 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 +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 @@ -142,38 +201,53 @@ codes can be interpreted as follows: Ignored files are not listed, unless `--ignored` option is in effect, in which case `XY` are `!!`. - X Y Meaning - ------------------------------------------------- - [MD] not updated - M [ MD] updated in index - A [ MD] added to index - D [ M] 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 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 - ------------------------------------------------- +.... +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 + ## branchname tracking info -Porcelain Format -~~~~~~~~~~~~~~~~ +Porcelain Format Version 1 +~~~~~~~~~~~~~~~~~~~~~~~~~~ -The porcelain format is similar to the short format, but is guaranteed +Version 1 porcelain format is similar to the short format, but is guaranteed not to change in a backwards-incompatible way between Git versions or based on user configuration. This makes it ideal for parsing by scripts. The description of the short format above also describes the porcelain @@ -195,6 +269,135 @@ 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 ------------- @@ -207,7 +410,7 @@ 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 +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 @@ -218,6 +421,19 @@ 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] diff --git a/Documentation/git-stripspace.txt b/Documentation/git-stripspace.txt index c87bfcb674..2438f76da0 100644 --- a/Documentation/git-stripspace.txt +++ b/Documentation/git-stripspace.txt @@ -9,13 +9,15 @@ git-stripspace - Remove unnecessary whitespace SYNOPSIS -------- [verse] -'git stripspace' [-s | --strip-comments] < input +'git stripspace' [-s | --strip-comments] +'git stripspace' [-c | --comment-lines] DESCRIPTION ----------- -Clean the input in the manner used by Git for text such as commit -messages, notes, tags and branch descriptions. +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: @@ -48,7 +50,7 @@ EXAMPLES Given the following noisy input with '$' indicating the end of a line: --------- +--------- |A brief introduction $ | $ |$ @@ -64,7 +66,7 @@ Given the following noisy input with '$' indicating the end of a line: Use 'git stripspace' with no arguments to obtain: --------- +--------- |A brief introduction$ |$ |A new paragraph$ @@ -78,7 +80,7 @@ Use 'git stripspace' with no arguments to obtain: Use 'git stripspace --strip-comments' to obtain: --------- +--------- |A brief introduction$ |$ |A new paragraph$ diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index bfef8a0c62..7e5f995f77 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -9,114 +9,81 @@ git-submodule - Initialize, update or inspect submodules SYNOPSIS -------- [verse] -'git submodule' [--quiet] add [-b <branch>] [-f|--force] [--name <name>] - [--reference <repository>] [--depth <depth>] [--] <repository> [<path>] +'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] [--] <path>... -'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] - [-f|--force] [--rebase] [--reference <repository>] [--depth <depth>] - [--merge] [--recursive] [--] [<path>...] -'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>] - [commit] [--] [<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] set-url [--] <path> <newurl> +'git submodule' [--quiet] summary [<options>] [--] [<path>...] 'git submodule' [--quiet] foreach [--recursive] <command> -'git submodule' [--quiet] sync [--] [<path>...] +'git submodule' [--quiet] sync [--recursive] [--] [<path>...] +'git submodule' [--quiet] absorbgitdirs [--] [<path>...] DESCRIPTION ----------- -Submodules allow foreign repositories to be embedded within -a dedicated subdirectory of the source tree, always pointed -at a particular commit. - -They are not to be confused with remotes, which are meant mainly -for branches of the same project; submodules are meant for -different projects you would like to make part of your source tree, -while the history of the two projects still stays completely -independent and you cannot modify the contents of the submodule -from within the main project. -If you want to merge the project histories and want to treat the -aggregated whole as a single project from then on, you may want to -add a remote for the other project and use the 'subtree' merge strategy, -instead of treating the other project as a submodule. Directories -that come from both projects can be cloned and checked out as a whole -if you choose to go that route. - -Submodules are composed from a so-called `gitlink` tree entry -in the main repository that refers to a particular commit object -within the inner repository that is completely separate. -A record in the `.gitmodules` (see linkgit:gitmodules[5]) file at the -root of the source tree assigns a logical name to the submodule and -describes the default URL the submodule shall be cloned from. -The logical name can be used for overriding this URL within your -local repository configuration (see 'submodule init'). - -This command will manage the tree entries and contents of the -gitmodules file for you, as well as inspect the status of your -submodules and update them. -When adding a new submodule to the tree, the 'add' subcommand -is to be used. However, when pulling a tree containing submodules, -these will not be checked out by default; -the 'init' and 'update' subcommands will maintain submodules -checked out and at appropriate revision in your working tree. -You can briefly inspect the up-to-date status of your submodules -using the 'status' subcommand and get a detailed overview of the -difference between the index and checkouts using the 'summary' -subcommand. +Inspects, updates and manages submodules. +For more information about submodules, see linkgit:gitsubmodules[7]. COMMANDS -------- -add:: +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". + -This requires at least one argument: <repository>. The optional -argument <path> is the relative location for the cloned submodule -to exist in the superproject. If <path> is not given, the -"humanish" part of the source repository is used ("repo" for -"/path/to/repo.git" and "foo" for "host.xz:foo/.git"). -The <path> is also used as the submodule's logical name in its -configuration entries unless `--name` is used to specify a logical name. -+ <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 origin +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 +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). -If the superproject doesn't have an origin configured ++ +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. + -<path> is the relative location for the cloned submodule to -exist in the superproject. If <path> does not exist, then the -submodule is created by cloning from the named URL. If <path> does -exist and is already a valid Git repository, then this is added -to the changeset without cloning. This second form is provided -to ease creating a new submodule from scratch, and presumes -the user will later push the submodule to the given URL. +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. + -In either case, 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:: +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 be prefixed with `-` if the submodule is not - initialized, `+` if the currently checked out submodule commit + 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 `--cached` is specified, this command will instead print the SHA-1 +recorded in the superproject for each submodule. ++ If `--recursive` is specified, this command will recurse into nested submodules, and show their status as well. + @@ -125,57 +92,105 @@ 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:: +init [--] [<path>...]:: Initialize the submodules recorded in the index (which were - added and committed elsewhere) by copying submodule - names and urls from .gitmodules to .git/config. - Optional <path> arguments limit which submodules will be initialized. - It will also copy the value of `submodule.$name.update` into - .git/config. - The key used in .git/config is `submodule.$name.url`. - 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. - -deinit:: + 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 work tree anymore. If - you really want to remove a submodule from the repository and commit - that use linkgit:git-rm[1] instead. + have a local checkout of the submodule in your working tree anymore. + -If `--force` is specified, the submodule's work tree will be removed even if -it contains local modifications. - -update:: - Update the registered submodules, i.e. clone missing submodules and - checkout the commit specified in the index of the containing repository. - This will make the submodules HEAD be detached unless `--rebase` or - `--merge` is specified or the key `submodule.$name.update` is set to - `rebase`, `merge` or `none`. `none` can be overridden by specifying - `--checkout`. Setting the key `submodule.$name.update` to `!command` - will cause `command` to be run. `command` can be any arbitrary shell - command that takes a single argument, namely the sha1 to update to. +When the command is run without pathspec, it errors out, +instead of deinit-ing everything, to prevent mistakes. + -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 `--force` is specified, the submodule's working tree will +be removed even if it contains local modifications. + -If `--recursive` is specified, this command will recurse into the -registered submodules, and update any nested submodules within. +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>] [--[no-]single-branch] [--] [<path>...]:: ++ +-- +Update the registered submodules to match what the superproject +expects by cloning missing submodules, fetching missing commits +in 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` if appropriate), even if the commit specified in the -index of the containing repository already matches the commit checked out in -the submodule. +`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. -summary:: + 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 (-b|--branch) <branch> [--] <path>:: +set-branch (-d|--default) [--] <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 the remote 'HEAD'. + +set-url [--] <path> <newurl>:: + Sets the URL of the specified submodule to <newurl>. Then, it will + automatically synchronize the submodule's new remote URL + configuration. + +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 @@ -188,14 +203,19 @@ summary:: Using the `--submodule=log` option with linkgit:git-diff[1] will provide that information too. -foreach:: +foreach [--recursive] <command>:: Evaluates an arbitrary shell command in each checked out submodule. - The command has access to the variables $name, $path, $sha1 and - $toplevel: - $name is the name of the relevant submodule section in .gitmodules, - $path is the name of the submodule directory relative to the - superproject, $sha1 is the commit as recorded in the superproject, - and $toplevel is the absolute path to the top-level of the superproject. + 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. @@ -205,20 +225,40 @@ foreach:: the processing to terminate. This can be overridden by adding '|| :' to the end of the command. + -As an example, +git submodule foreach \'echo $path {backtick}git -rev-parse HEAD{backtick}'+ will show the path and currently checked out -commit for each submodule. +As an example, the command below will show the path and currently +checked out commit for each submodule: ++ +-------------- +git submodule foreach 'echo $sm_path `git rev-parse HEAD`' +-------------- -sync:: +sync [--recursive] [--] [<path>...]:: Synchronizes submodules' remote URL configuration setting - to the value specified in .gitmodules. It will only affect those + 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. +`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 superproject's + `$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 ------- @@ -226,22 +266,38 @@ OPTIONS --quiet:: Only print error messages. --b:: ---branch:: +--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.<path>.branch` in - `.gitmodules` for `update --remote`. + 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 the remote 'HEAD'. -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 work trees will be removed even if - they contain local changes. - When running update, 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. + 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 @@ -266,10 +322,10 @@ OPTIONS 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). + The remote branch used defaults to the remote `HEAD`, 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. @@ -281,12 +337,31 @@ In order to ensure a current tracking branch state, `update --remote` fetches the submodule's remote repository before calculating the SHA-1. If you don't want to fetch, you should use `submodule update --remote --no-fetch`. ++ +Use this option to integrate changes from the upstream subproject with +your submodule's current HEAD. Alternatively, you can run `git pull` +from the submodule, which is equivalent except for the remote branch +name: `update --remote` uses the default upstream repository and +`submodule.<name>.branch`, while `git pull` uses the submodule's +`branch.<name>.merge`. Prefer `submodule.<name>.branch` if you want +to distribute the default upstream branch with the superproject and +`branch.<name>.merge` if you want a more native feel while working in +the submodule itself. -N:: --no-fetch:: This option is only valid for the update command. Don't fetch new objects from the remote site. +--checkout:: + This option is only valid for the update command. + Checkout the commit recorded in the superproject on a detached HEAD + in the submodule. This is the default behavior, the main use of + this option is to override `submodule.$name.update` when set to + 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 @@ -322,10 +397,18 @@ SHA-1. If you don't want to fetch, you should use `submodule update this option will be passed to the linkgit:git-clone[1] command. + *NOTE*: Do *not* use this option unless you have read the note -for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully. +for linkgit:git-clone[1]'s `--reference`, `--shared`, and `--dissociate` +options carefully. + +--dissociate:: + This option is only valid for add and update commands. These + commands sometimes need to clone a remote repository. In this case, + this option will be passed to the linkgit:git-clone[1] command. ++ +*NOTE*: see the NOTE for the `--reference` option. --recursive:: - This option is only valid for foreach, update and status commands. + 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). @@ -335,6 +418,21 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully. clone with a history truncated to the specified number of revisions. See linkgit:git-clone[1] +--[no-]recommend-shallow:: + This option is only valid for the update command. + The initial clone of a submodule will use the recommended + `submodule.<name>.shallow` as provided by the `.gitmodules` file + by default. To ignore the suggestions use `--no-recommend-shallow`. + +-j <n>:: +--jobs <n>:: + This option is only valid for the update command. + Clone new submodules in parallel with as many jobs. + Defaults to the `submodule.fetchJobs` option. + +--[no-]single-branch:: + This option is only valid for the update command. + Clone only one branch during update: HEAD or one specified by --branch. <path>...:: Paths to submodule(s). When specified this will restrict the command @@ -343,12 +441,16 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully. FILES ----- -When initializing submodules, a .gitmodules file in the top-level directory +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/Documentation/git-svn.txt b/Documentation/git-svn.txt index 2a3847649d..6624a14fbd 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -8,7 +8,7 @@ git-svn - Bidirectional operation between a Subversion repository and Git SYNOPSIS -------- [verse] -'git svn' <command> [options] [arguments] +'git svn' <command> [<options>] [<arguments>] DESCRIPTION ----------- @@ -70,8 +70,8 @@ COMMANDS --username=<user>;; For transports that SVN handles authentication for (http, https, and plain svn), specify the username. For other - transports (eg svn+ssh://), you must include the username in - the URL, eg svn+ssh://foo@svn.bar.com/project + 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 @@ -86,22 +86,27 @@ COMMANDS (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: In Git v2.0, the default prefix will CHANGE from "" (no prefix) -to "origin/". This is done to put SVN-tracking refs at -"refs/remotes/origin/*" instead of "refs/remotes/*", and make them -more compatible with how Git's own remote-tracking refs are organized -(i.e. refs/remotes/$remote/*). You can enjoy the same benefits today, -by using the --prefix option. +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'. + 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'. + of `--include-paths`. --no-minimize-url;; When tracking multiple directories (using --stdlayout, --branches, or --tags options), git svn will attempt to connect @@ -109,7 +114,7 @@ by using the --prefix option. 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 + 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). @@ -121,34 +126,46 @@ by using the --prefix option. command-line argument. + This automatically updates the rev_map if needed (see -'$GIT_DIR/svn/\*\*/.rev_map.*' in the FILES section below for details). +'$GIT_DIR/svn/\**/.rev_map.*' in the FILES section below for details). --localtime;; - Store Git commit times in the local timezone instead of UTC. This + 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 timezone. + 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 timezone. +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' + 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 config key is set and the command line option is -also given, both regular expressions will be used. +If the ignore-paths configuration key is set, and the command-line +option is also given, both regular expressions will be used. + Examples: + @@ -169,17 +186,20 @@ Skip "branches" and "tags" of first level directories;; --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' + 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'. + '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. + 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 @@ -187,7 +207,7 @@ Skip "branches" and "tags" of first level directories;; 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, + `--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. @@ -212,14 +232,14 @@ 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 +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). +'$GIT_DIR/svn/\**/.rev_map.*' in the FILES section below for details). -l;; --local;; @@ -251,6 +271,10 @@ Use of 'dcommit' is preferred to 'set-tree' (below). 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. @@ -274,9 +298,9 @@ first have already been pushed into SVN. 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. ++ +'git svn dcommit' returns immediately if answer is "no" or "quit", without +committing anything to SVN. 'branch':: Create a branch in the SVN repository. @@ -366,12 +390,12 @@ 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'. + 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 @@ -385,11 +409,13 @@ Any other arguments are passed directly to 'git log' 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 @@ -398,7 +424,7 @@ Any other arguments are passed directly to 'git log' '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 + 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 @@ -426,13 +452,28 @@ Any other arguments are passed directly to 'git log' 'commit-diff':: Commits the diff of two tree-ish arguments from the - command-line. This command does not rely on being inside an `git svn + 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 @@ -449,6 +490,20 @@ Any other arguments are passed directly to 'git log' 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. @@ -469,7 +524,7 @@ Any other arguments are passed directly to 'git log' 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). +'$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. @@ -580,7 +635,8 @@ config key: svn.findcopiesharder -A<filename>:: --authors-file=<filename>:: - Syntax is compatible with the file used by 'git cvsimport': + Syntax is compatible with the file used by 'git cvsimport' but + an empty email address can be supplied with '<>': + ------------------------------------------------------------------------ loginname = Joe User <user@example.com> @@ -599,35 +655,30 @@ config key: svn.authorsfile If this option is specified, for each SVN committer name that does not exist in the authors file, the given file is executed with the committer name as the first argument. The program is - expected to return a single line of the form "Name <email>", - which will be treated as if included in the authors file. + expected to return a single line of the form "Name <email>" or + "Name <>", which will be treated as if included in the authors + file. ++ +Due to historical reasons a relative 'filename' is first searched +relative to the current directory for 'init' and 'clone' and relative +to the root of the working tree for 'fetch'. If 'filename' is +not found, it is searched like any other command in '$PATH'. ++ +[verse] +config key: svn.authorsProg -q:: --quiet:: Make 'git svn' less verbose. Specify a second time to make it even less verbose. ---repack[=<n>]:: ---repack-flags=<flags>:: - These should help keep disk usage sane for large fetches with - many revisions. -+ ---repack takes an optional argument for the number of revisions -to fetch before repacking. This defaults to repacking every -1000 commits fetched if no argument is specified. -+ ---repack-flags are passed directly to 'git repack'. -+ -[verse] -config key: svn.repack -config key: svn.repackflags - -m:: --merge:: -s<strategy>:: --strategy=<strategy>:: -p:: ---preserve-merges:: +--rebase-merges:: +--preserve-merges (DEPRECATED):: These are only used with the 'dcommit' and 'rebase' commands. + Passed directly to 'git rebase' when using 'dcommit' if a @@ -652,13 +703,19 @@ creating the branch or tag. 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 'commit-diff', 'set-tree' or 'dcommit' + When committing to svn from Git (as part of 'set-tree' or 'dcommit' operations), if the existing log message doesn't already have a `From:` or `Signed-off-by:` line, append a `From:` line based on the Git commit's author string. If you use this, then `--use-log-author` will retrieve a valid author string for all commits. - ++ +[verse] +config key: svn.addAuthorFrom ADVANCED OPTIONS ---------------- @@ -704,7 +761,7 @@ svn-remote.<name>.noMetadata:: + 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 +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 @@ -713,11 +770,11 @@ 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. +reports, and archives. If you plan to eventually migrate from SVN to +Git and are certain about dropping SVN history, consider +https://github.com/newren/git-filter-repo[git-filter-repo] instead. +filter-repo also allows reformatting of metadata for ease-of-reading +and rewriting authorship info for non-"svn.authorsFile" users. svn.useSvmProps:: svn-remote.<name>.useSvmProps:: @@ -753,7 +810,7 @@ svn-remote.<name>.rewriteUUID:: svn-remote.<name>.pushurl:: - Similar to Git's 'remote.<name>.pushurl', this key is designed + 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 @@ -830,7 +887,7 @@ Tracking and contributing to an entire Subversion-managed project # View all branches and tags you have cloned: git branch -r # Create a new branch in SVN - git svn branch waldo + git svn branch waldo # Reset your master to trunk (or any other branch, replacing 'trunk' # with the appropriate name): git reset --hard svn/trunk @@ -910,7 +967,7 @@ 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 +`--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 @@ -987,22 +1044,12 @@ 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 +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 the options for describing the repository layout (--trunk, ---tags, --branches, --stdlayout), please also specify the --prefix -option (e.g. '--prefix=origin/') to cause your SVN-tracking refs to be -placed at refs/remotes/origin/* rather than the default refs/remotes/*. -The former is more compatible with the layout of Git's "regular" -remote-tracking refs (refs/remotes/$remote/*), and may potentially -prevent similarly named SVN branches and Git remotes from clobbering -each other. In Git v2.0 the default prefix used (i.e. when no --prefix -is given) will change from "" (no prefix) to "origin/". +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 @@ -1049,16 +1096,28 @@ listed below are allowed: 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; +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 +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: @@ -1096,7 +1155,7 @@ fetching, then $GIT_DIR/svn/.metadata must be manually edited to remove FILES ----- -$GIT_DIR/svn/\*\*/.rev_map.*:: +$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 diff --git a/Documentation/git-switch.txt b/Documentation/git-switch.txt new file mode 100644 index 0000000000..3759c3a265 --- /dev/null +++ b/Documentation/git-switch.txt @@ -0,0 +1,273 @@ +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 + active submodules according to the commit recorded in the + superproject. If nothing (or `--no-recurse-submodules`) is + used, submodules working trees 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/Documentation/git-tag.txt b/Documentation/git-tag.txt index c418c44d40..f6d9791780 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -9,13 +9,14 @@ git-tag - Create, list, delete or verify a tag object signed with GPG SYNOPSIS -------- [verse] -'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] +'git tag' [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>] [-e] <tagname> [<commit> | <object>] 'git tag' -d <tagname>... -'git tag' [-n[<num>]] -l [--contains <commit>] [--points-at <object>] - [--column[=<options>] | --no-column] [<pattern>...] - [<pattern>...] -'git tag' -v <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 ----------- @@ -25,24 +26,24 @@ to delete, list or verify tags. Unless `-f` is given, the named tag must not yet exist. -If one of `-a`, `-s`, or `-u <key-id>` is passed, the command +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 <key-id>` +If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <keyid>` are absent, `-a` is implied. -Otherwise just a tag reference for the SHA-1 object name of the commit object is -created (i.e. a lightweight tag). +Otherwise, a tag reference that points directly at the given object +(i.e., a lightweight tag) is created. A GnuPG signed tag object will be created when `-s` or `-u -<key-id>` is used. When `-u <key-id>` is not used, the +<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" +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 @@ -63,9 +64,16 @@ OPTIONS -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 otherwise. + See linkgit:git-config[1]. --u <key-id>:: ---local-user=<key-id>:: +--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:: @@ -78,22 +86,50 @@ OPTIONS -v:: --verify:: - Verify the gpg signature of the given tag names. + 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. - 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 <pattern>:: ---list <pattern>:: - List tags with names that match the given pattern (or all if no - pattern is given). 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. + 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:: @@ -103,27 +139,47 @@ OPTIONS + This option is only applicable when listing tags without annotation lines. ---contains <commit>:: - Only list tags which contain the specified commit. +--contains [<commit>]:: + Only list tags which contain the specified commit (HEAD if not + specified). 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. + 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 <key-id>` + 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 <key-id>` + 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 @@ -131,6 +187,19 @@ This option is only applicable when listing tags without annotation lines. 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 @@ -142,19 +211,21 @@ This option is only applicable when listing tags without annotation lines. 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 +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-key-id> + 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 ---------- @@ -173,16 +244,16 @@ 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. + 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. + 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 @@ -226,9 +297,8 @@ On Automatic following ~~~~~~~~~~~~~~~~~~~~~~ If you are following somebody else's tree, you are most likely -using remote-tracking branches (`refs/heads/origin` in traditional -layout, or `refs/remotes/origin/master` in the separate-remote -layout). You usually want the tags from the other end. +using remote-tracking branches (eg. `refs/remotes/origin/master`). +You usually want the tags from the other end. On the other hand, if you are fetching because you would want a one-shot merge from somebody else, you typically do not want to @@ -310,6 +380,7 @@ include::date-formats.txt[] SEE ALSO -------- linkgit:git-check-ref-format[1]. +linkgit:git-config[1]. GIT --- diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt deleted file mode 100644 index f7362dc2d1..0000000000 --- a/Documentation/git-tar-tree.txt +++ /dev/null @@ -1,82 +0,0 @@ -git-tar-tree(1) -=============== - -NAME ----- -git-tar-tree - Create a tar archive of the files in the named tree object - - -SYNOPSIS --------- -[verse] -'git tar-tree' [--remote=<repo>] <tree-ish> [ <base> ] - -DESCRIPTION ------------ -THIS COMMAND IS DEPRECATED. Use 'git archive' with `--format=tar` -option instead (and move the <base> argument to `--prefix=base/`). - -Creates a tar archive containing the tree structure for the named tree. -When <base> is specified it is added as a leading path to the files in the -generated tar archive. - -'git tar-tree' behaves differently when given a tree ID versus when given -a commit ID or tag ID. In the first case the current time is used as -modification time of each file in the archive. In the latter case the -commit time as recorded in the referenced commit object is used instead. -Additionally the commit ID is stored in a global extended pax header. -It can be extracted using 'git get-tar-commit-id'. - -OPTIONS -------- - -<tree-ish>:: - The tree or commit to produce tar archive for. If it is - the object name of a commit object. - -<base>:: - Leading path to the files in the resulting tar archive. - ---remote=<repo>:: - Instead of making a tar archive from local repository, - retrieve a tar archive from a remote repository. - -CONFIGURATION -------------- - -tar.umask:: - This variable can be used to restrict the permission bits of - tar archive entries. The default is 0002, which turns off the - world write bit. The special value "user" indicates that the - archiving user's umask will be used instead. See umask(2) for - details. - -EXAMPLES --------- -`git tar-tree HEAD junk | (cd /var/tmp/ && tar xf -)`:: - - Create a tar archive that contains the contents of the - latest commit on the current branch, and extracts it in - `/var/tmp/junk` directory. - -`git tar-tree v1.4.0 git-1.4.0 | gzip >git-1.4.0.tar.gz`:: - - Create a tarball for v1.4.0 release. - -`git tar-tree v1.4.0^{tree} git-1.4.0 | gzip >git-1.4.0.tar.gz`:: - - Create a tarball for v1.4.0 release, but without a - global extended pax header. - -`git tar-tree --remote=example.com:git.git v1.4.0 >git-1.4.0.tar`:: - - Get a tarball v1.4.0 from example.com. - -`git tar-tree HEAD:Documentation/ git-docs > git-1.4.0-docs.tar`:: - - Put everything in the current head's Documentation/ directory - into 'git-1.4.0-docs.tar', with the prefix 'git-docs/'. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt index 78a0d955ec..d0fec4cddd 100644 --- a/Documentation/git-tools.txt +++ b/Documentation/git-tools.txt @@ -1,118 +1,10 @@ -A short Git tools survey -======================== +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. -Introduction ------------- - -Apart from Git contrib/ area there are some others third-party tools -you may want to look. - -This document presents a brief summary of each tool and the corresponding -link. - - -Alternative/Augmentative Porcelains ------------------------------------ - - - *Cogito* (http://www.kernel.org/pub/software/scm/cogito/) - - Cogito is a version control system layered on top of the Git tree history - storage system. It aims at seamless user interface and ease of use, - providing generally smoother user experience than the "raw" Core Git - itself and indeed many other version control systems. - - Cogito is no longer maintained as most of its functionality - is now in core Git. - - - - *pg* (http://www.spearce.org/category/projects/scm/pg/) - - pg is a shell script wrapper around Git to help the user manage a set of - patches to files. pg is somewhat like quilt or StGit, but it does have a - slightly different feature set. - - - - *StGit* (http://www.procode.org/stgit/) - - Stacked Git provides a quilt-like patch management functionality in the - Git environment. You can easily manage your patches in the scope of Git - until they get merged upstream. - - -History Viewers ---------------- - - - *gitk* (shipped with git-core) - - gitk is a simple Tk GUI for browsing history of Git repositories easily. - - - - *gitview* (contrib/) - - gitview is a GTK based repository browser for Git - - - - *gitweb* (shipped with git-core) - - Gitweb provides full-fledged web interface for Git repositories. - - - - *qgit* (http://digilander.libero.it/mcostalba/) - - QGit is a git/StGit GUI viewer built on Qt/C++. QGit could be used - to browse history and directory tree, view annotated files, commit - changes cherry picking single files or applying patches. - Currently it is the fastest and most feature rich among the Git - viewers and commit tools. - - - *tig* (http://jonas.nitro.dk/tig/) - - tig by Jonas Fonseca is a simple Git repository browser - written using ncurses. Basically, it just acts as a front-end - for git-log and git-show/git-diff. Additionally, you can also - use it as a pager for Git commands. - - -Foreign SCM interface ---------------------- - - - *git-svn* (shipped with git-core) - - git-svn is a simple conduit for changesets between a single Subversion - branch and Git. - - - - *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc) - - These utilities convert patch series in a quilt repository and commit - series in Git back and forth. - - - - *hg-to-git* (contrib/) - - hg-to-git converts a Mercurial repository into a Git one, and - preserves the full branch history in the process. hg-to-git can - also be used in an incremental way to keep the Git repository - in sync with the master Mercurial repository. - - -Others ------- - - - *(h)gct* (http://www.cyd.liu.se/users/~freku045/gct/) - - Commit Tool or (h)gct is a GUI enabled commit tool for Git and - Mercurial (hg). It allows the user to view diffs, select which files - to committed (or ignored / reverted) write commit messages and - perform the commit itself. - - - *git.el* (contrib/) - - This is an Emacs interface for Git. The user interface is modelled on - pcl-cvs. It has been developed on Emacs 21 and will probably need some - tweaking to work on XEmacs. - - -http://git.or.cz/gitwiki/InterfacesFrontendsAndTools has more -comprehensive list. +See also the `contrib/` area, and the Git wiki: +https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt index ff23494e70..b3de50d710 100644 --- a/Documentation/git-unpack-objects.txt +++ b/Documentation/git-unpack-objects.txt @@ -9,7 +9,7 @@ git-unpack-objects - Unpack objects from a packed archive SYNOPSIS -------- [verse] -'git unpack-objects' [-n] [-q] [-r] [--strict] <pack-file +'git unpack-objects' [-n] [-q] [-r] [--strict] DESCRIPTION @@ -19,8 +19,8 @@ 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 pack-file. Therefore, nothing will be unpacked if you use -this command on a pack-file that exists within the target repository. +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. @@ -44,6 +44,9 @@ OPTIONS --strict:: Don't write objects with broken content or links. +--max-input-size=<size>:: + Die, if the pack is larger than <size>. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index e0a87029cd..1489cb09a0 100644 --- a/Documentation/git-update-index.txt +++ b/Documentation/git-update-index.txt @@ -12,11 +12,16 @@ SYNOPSIS 'git update-index' [--add] [--remove | --force-remove] [--replace] [--refresh] [-q] [--unmerged] [--ignore-missing] - [(--cacheinfo <mode> <object> <file>)...] + [(--cacheinfo <mode>,<object>,<file>)...] [--chmod=(+|-)x] [--[no-]assume-unchanged] [--[no-]skip-worktree] + [--[no-]ignore-skip-worktree-entries] + [--[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>] @@ -68,8 +73,12 @@ OPTIONS --ignore-missing:: Ignores missing files during a --refresh +--cacheinfo <mode>,<object>,<path>:: --cacheinfo <mode> <object> <path>:: - Directly insert the specified info into the index. + Directly insert the specified info into the index. For + backward compatibility, you can also give these three + arguments as three separate parameters, but new users are + encouraged to use a single-parameter form. --index-info:: Read index information from stdin. @@ -78,27 +87,25 @@ OPTIONS Set the execute permissions on the updated files. --[no-]assume-unchanged:: - When these flags are specified, the object names recorded - for the paths are not updated. Instead, these options - set and unset the "assume unchanged" bit for the - paths. When the "assume unchanged" bit is on, Git stops - checking the working tree files for possible - modifications, so you need to manually unset the bit to - tell Git when you change the working tree file. This is + 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). + -This option can be also used as a coarse file-level mechanism -to ignore uncommitted changes in tracked files (akin to what -`.gitignore` does for untracked files). 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, + Like `--refresh`, but checks stat information unconditionally, without regard to the "assume unchanged" setting. --[no-]skip-worktree:: @@ -107,6 +114,17 @@ you will need to handle the situation manually. set and unset the "skip-worktree" bit for the paths. See section "Skip-worktree bit" below for more information. + +--[no-]ignore-skip-worktree-entries:: + Do not remove skip-worktree (AKA "index-only") entries even when + the `--remove` option was specified. + +--[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 @@ -149,7 +167,7 @@ you will need to handle the situation manually. + 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 in 1.8.0 in +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. @@ -157,6 +175,55 @@ may not support it yet. 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. @@ -167,10 +234,10 @@ may not support it yet. cleaner names. The same applies to directories ending '/' and paths with '//' -Using --refresh +USING --REFRESH --------------- -'--refresh' does not calculate a new sha1 file or bring the index -up-to-date for mode/content changes. But what it *does* do is to +`--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. @@ -178,52 +245,49 @@ the stat entry is out of date. For example, you'd want to do this after doing a 'git read-tree', to link up the stat index details with the proper files. -Using --cacheinfo or --info-only +USING --CACHEINFO OR --INFO-ONLY -------------------------------- -'--cacheinfo' is used to register a file that is not in the +`--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 with mode and sha1 at path, say: +To pretend you have a file at path with mode and sha1, say: ---------------- -$ git update-index --cacheinfo mode sha1 path +$ git update-index --add --cacheinfo <mode>,<sha1>,<path> ---------------- -'--info-only' is used to register files without placing them in the object +`--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 +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 +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 sha1 TAB path -+ -The first format is what "git-apply --index-info" -reports, and used to reconstruct a partial tree -that is used for phony merge base tree when falling -back on 3-way merge. - . mode SP type SP sha1 TAB path + -The second format is to stuff 'git ls-tree' output -into the index file. +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. @@ -256,7 +320,7 @@ $ git ls-files -s ------------ -Using ``assume unchanged'' bit +USING ``ASSUME UNCHANGED'' BIT ------------------------------ Many operations in Git depend on your filesystem to have an @@ -289,7 +353,7 @@ the index (use `git update-index --really-refresh` if you want to mark them as "assume unchanged"). -Examples +EXAMPLES -------- To update and refresh only the files already checked out: @@ -326,7 +390,7 @@ M foo.c <9> now it checks with lstat(2) and finds it has been changed. -Skip-worktree bit +SKIP-WORKTREE BIT ----------------- Skip-worktree bit can be defined in one (long) sentence: When reading @@ -346,8 +410,118 @@ 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 every time 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 +---------------- -Configuration +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 @@ -371,6 +545,25 @@ 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]). + +NOTES +----- + +Users often try to use the assume-unchanged and skip-worktree bits +to tell Git to ignore changes to files that are tracked. This does not +work as expected, since Git may still check working tree files against +the index when performing certain operations. In general, Git does not +provide a way to ignore changes to tracked files, so alternate solutions +are recommended. + +For example, if the file you want to change is some sort of config file, +the repository can include a sample config file that can then be copied +into the ignored name and modified. The repository can even include a +script to treat the sample file as a template, modifying and copying it +automatically. SEE ALSO -------- diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt index 0a0a5512b3..3e737c2360 100644 --- a/Documentation/git-update-ref.txt +++ b/Documentation/git-update-ref.txt @@ -8,7 +8,7 @@ git-update-ref - Update the object name stored in a ref safely SYNOPSIS -------- [verse] -'git update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>] | --stdin [-z]) +'git update-ref' [-m <reason>] [--no-deref] (-d <ref> [<oldvalue>] | [--create-reflog] <ref> <newvalue> [<oldvalue>] | --stdin [-z]) DESCRIPTION ----------- @@ -66,18 +66,38 @@ performs all modifications together. Specify commands of the form: delete SP <ref> [SP <oldvalue>] LF verify SP <ref> [SP <oldvalue>] LF option SP <opt> LF + start LF + prepare LF + commit LF + abort 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. Alternatively, use `-z` to specify commands without quoting: +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 + start NUL + prepare NUL + commit NUL + abort NUL -Lines of any other format or a repeated <ref> produce an error. -Command meanings are: +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. @@ -95,15 +115,30 @@ delete:: verify:: Verify <ref> against <oldvalue> but do not change it. If - <oldvalue> zero or missing, the ref must not exist. + <oldvalue> is 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. -Use 40 "0" or the empty string to specify a zero value, except that -with `-z` an empty <oldvalue> is considered missing. +start:: + Start a transaction. In contrast to a non-transactional session, a + transaction will automatically abort if the session ends without an + explicit commit. + +prepare:: + Prepare to commit the transaction. This will create lock files for all + queued reference updates. If one reference could not be locked, the + transaction will be aborted. + +commit:: + Commit all reference updates queued for the transaction, ending the + transaction. + +abort:: + Abort the transaction, releasing all locks if the transaction is in + prepared state. If all <ref>s can be locked with matching <oldvalue>s simultaneously, all modifications are performed. Otherwise, no @@ -111,7 +146,7 @@ modifications are performed. Note that while each individual <ref> is updated or deleted atomically, a concurrent reader may still see a subset of the modifications. -Logging Updates +LOGGING UPDATES --------------- If config parameter "core.logAllRefUpdates" is true and the ref is one under "refs/heads/", "refs/remotes/", "refs/notes/", or the symbolic ref HEAD; or @@ -120,8 +155,8 @@ 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 -+ + 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 @@ -129,8 +164,8 @@ and date in the standard Git committer ident format. Optionally with -m: - . oldsha1 SP newsha1 SP committer TAB message LF -+ + 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. diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt index bd0e36492f..969bb2e15f 100644 --- a/Documentation/git-update-server-info.txt +++ b/Documentation/git-update-server-info.txt @@ -9,7 +9,7 @@ git-update-server-info - Update auxiliary info file to help dumb servers SYNOPSIS -------- [verse] -'git update-server-info' [--force] +'git update-server-info' DESCRIPTION ----------- @@ -19,15 +19,6 @@ $GIT_OBJECT_DIRECTORY/info directories to help clients discover what references and packs the server has. This command generates such auxiliary files. - -OPTIONS -------- - --f:: ---force:: - Update the info files from scratch. - - OUTPUT ------ diff --git a/Documentation/git-upload-archive.txt b/Documentation/git-upload-archive.txt index d09bbb52b1..fba0f1c1b2 100644 --- a/Documentation/git-upload-archive.txt +++ b/Documentation/git-upload-archive.txt @@ -1,5 +1,5 @@ git-upload-archive(1) -==================== +===================== NAME ---- @@ -20,6 +20,38 @@ This command is usually not invoked directly by the end user. The UI for the protocol is on the 'git archive' side, and the program pair is meant to be used to get an archive from a remote repository. +SECURITY +-------- + +In order to protect the privacy of objects that have been removed from +history but may not yet have been pruned, `git-upload-archive` avoids +serving archives for commits and trees that are not reachable from the +repository's refs. However, because calculating object reachability is +computationally expensive, `git-upload-archive` implements a stricter +but easier-to-check set of rules: + + 1. Clients may request a commit or tree that is pointed to directly by + a ref. E.g., `git archive --remote=origin v1.0`. + + 2. Clients may request a sub-tree within a commit or tree using the + `ref:path` syntax. E.g., `git archive --remote=origin v1.0:Documentation`. + + 3. Clients may _not_ use other sha1 expressions, even if the end + result is reachable. E.g., neither a relative commit like `master^` + nor a literal sha1 like `abcd1234` is allowed, even if the result + is reachable from the refs. + +Note that rule 3 disallows many cases that do not have any privacy +implications. These rules are subject to change in future versions of +git, and the server accessed by `git archive --remote` may or may not +follow these exact rules. + +If the config option `uploadArchive.allowUnreachable` is true, these +rules are ignored, and clients may use arbitrary sha1 expressions. +This is useful if you do not care about the privacy of unreachable +objects, or if your object database is already publicly available for +access via non-smart-http. + OPTIONS ------- <directory>:: diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt index 0abc806ea9..9822c1eb1a 100644 --- a/Documentation/git-upload-pack.txt +++ b/Documentation/git-upload-pack.txt @@ -9,7 +9,8 @@ git-upload-pack - Send objects packed back to git-fetch-pack SYNOPSIS -------- [verse] -'git-upload-pack' [--strict] [--timeout=<n>] <directory> +'git-upload-pack' [--[no-]strict] [--timeout=<n>] [--stateless-rpc] + [--advertise-refs] <directory> DESCRIPTION ----------- @@ -21,16 +22,25 @@ 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 ------- ---strict:: +--[no-]strict:: Do not try <directory>/.git/ if <directory> is no Git directory. --timeout=<n>:: Interrupt transfer after <n> seconds of inactivity. +--stateless-rpc:: + Perform only a single read-write cycle with stdin and stdout. + This fits with the HTTP POST request processing model where + a program may read the request, write a response, and must exit. + +--advertise-refs:: + Only the initial ref advertisement is output, and the program exits + immediately. This fits with the HTTP GET request model, where + no request content is received but a response must be produced. + <directory>:: The repository to sync from. diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt index 44ff9541df..6072f936ab 100644 --- a/Documentation/git-var.txt +++ b/Documentation/git-var.txt @@ -23,14 +23,14 @@ OPTIONS as well. (However, the configuration variables listing functionality is deprecated in favor of `git config -l`.) -EXAMPLE +EXAMPLES -------- $ git var GIT_AUTHOR_IDENT Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600 VARIABLES ----------- +--------- GIT_AUTHOR_IDENT:: The author of a piece of code. diff --git a/Documentation/git-verify-commit.txt b/Documentation/git-verify-commit.txt new file mode 100644 index 0000000000..92097f6673 --- /dev/null +++ b/Documentation/git-verify-commit.txt @@ -0,0 +1,32 @@ +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/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt index 526ba7be9c..61ca6d04c2 100644 --- a/Documentation/git-verify-pack.txt +++ b/Documentation/git-verify-pack.txt @@ -40,7 +40,7 @@ OUTPUT FORMAT ------------- When specifying the -v option the format used is: - SHA-1 type size size-in-pack-file offset-in-packfile + SHA-1 type size size-in-packfile offset-in-packfile for objects that are not deltified in the pack, and diff --git a/Documentation/git-verify-tag.txt b/Documentation/git-verify-tag.txt index f88ba96f02..0b8075dad9 100644 --- a/Documentation/git-verify-tag.txt +++ b/Documentation/git-verify-tag.txt @@ -8,7 +8,7 @@ git-verify-tag - Check the GPG signature of tags SYNOPSIS -------- [verse] -'git verify-tag' <tag>... +'git verify-tag' [--format=<format>] <tag>... DESCRIPTION ----------- @@ -16,6 +16,10 @@ 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. diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt index 5aec4ecffb..8d162b56c5 100644 --- a/Documentation/git-web--browse.txt +++ b/Documentation/git-web--browse.txt @@ -8,7 +8,7 @@ git-web--browse - Git helper script to launch a web browser SYNOPSIS -------- [verse] -'git web{litdd}browse' [OPTIONS] URL/FILE ... +'git web{litdd}browse' [<options>] <url|file>... DESCRIPTION ----------- @@ -35,6 +35,7 @@ The following browsers (or commands) are currently supported: * 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. @@ -61,14 +62,14 @@ 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' +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, +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. @@ -78,21 +79,21 @@ 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 +`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 +NOTE ABOUT KONQUEROR -------------------- -When 'konqueror' is specified by a command line option or a +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. +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: @@ -109,7 +110,7 @@ Note about git-config --global ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Note that these configuration variables should probably be set using -the '--global' flag, for example like this: +the `--global` flag, for example like this: ------------------------------------------------ $ git config --global web.browser firefox diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt new file mode 100644 index 0000000000..4796c3c05e --- /dev/null +++ b/Documentation/git-worktree.txt @@ -0,0 +1,384 @@ +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. If the destination is already assigned to some other working tree but is +missing (for instance, if `<new-path>` was deleted manually), then `--force` +allows the move to proceed; use --force twice if the destination is locked. ++ +`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/Documentation/git.txt b/Documentation/git.txt index 4f7e07f2e0..3e50065198 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -11,8 +11,9 @@ SYNOPSIS [verse] 'git' [--version] [--help] [-C <path>] [-c <name>=<value>] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] - [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] + [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare] [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] + [--super-prefix=<path>] <command> [<args>] DESCRIPTION @@ -22,363 +23,19 @@ unusually rich command set that provides both high-level operations and full access to internals. See linkgit:gittutorial[7] to get started, then see -link:everyday.html[Everyday Git] for a useful minimum set of +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. - -Formatted and hyperlinked version of the latest Git documentation -can be viewed at `http://git-htmldocs.googlecode.com/git/git.html`. - -ifdef::stalenotes[] -[NOTE] -============ - -You are reading the documentation for the latest (possibly -unreleased) version of Git, that is available from 'master' -branch of the `git.git` repository. -Documentation for older releases are available here: - -* link:v1.8.4.1/git.html[documentation for release 1.8.4.1] - -* release notes for - link:RelNotes/1.8.4.1.txt[1.8.4.1], - link:RelNotes/1.8.4.txt[1.8.4]. - -* link:v1.8.3.4/git.html[documentation for release 1.8.3.4] - -* release notes for - link:RelNotes/1.8.3.4.txt[1.8.3.4], - link:RelNotes/1.8.3.3.txt[1.8.3.3], - link:RelNotes/1.8.3.2.txt[1.8.3.2], - link:RelNotes/1.8.3.1.txt[1.8.3.1], - link:RelNotes/1.8.3.txt[1.8.3]. - -* link:v1.8.2.3/git.html[documentation for release 1.8.2.3] - -* release notes for - link:RelNotes/1.8.2.3.txt[1.8.2.3], - link:RelNotes/1.8.2.2.txt[1.8.2.2], - link:RelNotes/1.8.2.1.txt[1.8.2.1], - link:RelNotes/1.8.2.txt[1.8.2]. - -* link:v1.8.1.6/git.html[documentation for release 1.8.1.6] - -* release notes for - link:RelNotes/1.8.1.6.txt[1.8.1.6], - link:RelNotes/1.8.1.5.txt[1.8.1.5], - link:RelNotes/1.8.1.4.txt[1.8.1.4], - link:RelNotes/1.8.1.3.txt[1.8.1.3], - link:RelNotes/1.8.1.2.txt[1.8.1.2], - link:RelNotes/1.8.1.1.txt[1.8.1.1], - link:RelNotes/1.8.1.txt[1.8.1]. - -* link:v1.8.0.3/git.html[documentation for release 1.8.0.3] - -* release notes for - link:RelNotes/1.8.0.3.txt[1.8.0.3], - link:RelNotes/1.8.0.2.txt[1.8.0.2], - link:RelNotes/1.8.0.1.txt[1.8.0.1], - link:RelNotes/1.8.0.txt[1.8.0]. - -* link:v1.7.12.4/git.html[documentation for release 1.7.12.4] - -* release notes for - link:RelNotes/1.7.12.4.txt[1.7.12.4], - link:RelNotes/1.7.12.3.txt[1.7.12.3], - link:RelNotes/1.7.12.2.txt[1.7.12.2], - link:RelNotes/1.7.12.1.txt[1.7.12.1], - link:RelNotes/1.7.12.txt[1.7.12]. - -* link:v1.7.11.7/git.html[documentation for release 1.7.11.7] - -* release notes for - link:RelNotes/1.7.11.7.txt[1.7.11.7], - link:RelNotes/1.7.11.6.txt[1.7.11.6], - link:RelNotes/1.7.11.5.txt[1.7.11.5], - link:RelNotes/1.7.11.4.txt[1.7.11.4], - link:RelNotes/1.7.11.3.txt[1.7.11.3], - link:RelNotes/1.7.11.2.txt[1.7.11.2], - link:RelNotes/1.7.11.1.txt[1.7.11.1], - link:RelNotes/1.7.11.txt[1.7.11]. - -* link:v1.7.10.5/git.html[documentation for release 1.7.10.5] - -* release notes for - link:RelNotes/1.7.10.5.txt[1.7.10.5], - link:RelNotes/1.7.10.4.txt[1.7.10.4], - link:RelNotes/1.7.10.3.txt[1.7.10.3], - link:RelNotes/1.7.10.2.txt[1.7.10.2], - link:RelNotes/1.7.10.1.txt[1.7.10.1], - link:RelNotes/1.7.10.txt[1.7.10]. - -* link:v1.7.9.7/git.html[documentation for release 1.7.9.7] - -* release notes for - link:RelNotes/1.7.9.7.txt[1.7.9.7], - link:RelNotes/1.7.9.6.txt[1.7.9.6], - link:RelNotes/1.7.9.5.txt[1.7.9.5], - link:RelNotes/1.7.9.4.txt[1.7.9.4], - link:RelNotes/1.7.9.3.txt[1.7.9.3], - link:RelNotes/1.7.9.2.txt[1.7.9.2], - link:RelNotes/1.7.9.1.txt[1.7.9.1], - link:RelNotes/1.7.9.txt[1.7.9]. - -* link:v1.7.8.6/git.html[documentation for release 1.7.8.6] - -* release notes for - link:RelNotes/1.7.8.6.txt[1.7.8.6], - link:RelNotes/1.7.8.5.txt[1.7.8.5], - link:RelNotes/1.7.8.4.txt[1.7.8.4], - link:RelNotes/1.7.8.3.txt[1.7.8.3], - link:RelNotes/1.7.8.2.txt[1.7.8.2], - link:RelNotes/1.7.8.1.txt[1.7.8.1], - link:RelNotes/1.7.8.txt[1.7.8]. - -* link:v1.7.7.7/git.html[documentation for release 1.7.7.7] - -* release notes for - link:RelNotes/1.7.7.7.txt[1.7.7.7], - link:RelNotes/1.7.7.6.txt[1.7.7.6], - link:RelNotes/1.7.7.5.txt[1.7.7.5], - link:RelNotes/1.7.7.4.txt[1.7.7.4], - link:RelNotes/1.7.7.3.txt[1.7.7.3], - link:RelNotes/1.7.7.2.txt[1.7.7.2], - link:RelNotes/1.7.7.1.txt[1.7.7.1], - link:RelNotes/1.7.7.txt[1.7.7]. - -* link:v1.7.6.6/git.html[documentation for release 1.7.6.6] - -* release notes for - link:RelNotes/1.7.6.6.txt[1.7.6.6], - link:RelNotes/1.7.6.5.txt[1.7.6.5], - link:RelNotes/1.7.6.4.txt[1.7.6.4], - link:RelNotes/1.7.6.3.txt[1.7.6.3], - link:RelNotes/1.7.6.2.txt[1.7.6.2], - link:RelNotes/1.7.6.1.txt[1.7.6.1], - link:RelNotes/1.7.6.txt[1.7.6]. - -* link:v1.7.5.4/git.html[documentation for release 1.7.5.4] - -* release notes for - link:RelNotes/1.7.5.4.txt[1.7.5.4], - link:RelNotes/1.7.5.3.txt[1.7.5.3], - link:RelNotes/1.7.5.2.txt[1.7.5.2], - link:RelNotes/1.7.5.1.txt[1.7.5.1], - link:RelNotes/1.7.5.txt[1.7.5]. - -* link:v1.7.4.5/git.html[documentation for release 1.7.4.5] - -* release notes for - link:RelNotes/1.7.4.5.txt[1.7.4.5], - link:RelNotes/1.7.4.4.txt[1.7.4.4], - link:RelNotes/1.7.4.3.txt[1.7.4.3], - link:RelNotes/1.7.4.2.txt[1.7.4.2], - link:RelNotes/1.7.4.1.txt[1.7.4.1], - link:RelNotes/1.7.4.txt[1.7.4]. - -* link:v1.7.3.5/git.html[documentation for release 1.7.3.5] - -* release notes for - link:RelNotes/1.7.3.5.txt[1.7.3.5], - link:RelNotes/1.7.3.4.txt[1.7.3.4], - link:RelNotes/1.7.3.3.txt[1.7.3.3], - link:RelNotes/1.7.3.2.txt[1.7.3.2], - link:RelNotes/1.7.3.1.txt[1.7.3.1], - link:RelNotes/1.7.3.txt[1.7.3]. - -* link:v1.7.2.5/git.html[documentation for release 1.7.2.5] - -* release notes for - link:RelNotes/1.7.2.5.txt[1.7.2.5], - link:RelNotes/1.7.2.4.txt[1.7.2.4], - link:RelNotes/1.7.2.3.txt[1.7.2.3], - link:RelNotes/1.7.2.2.txt[1.7.2.2], - link:RelNotes/1.7.2.1.txt[1.7.2.1], - link:RelNotes/1.7.2.txt[1.7.2]. - -* link:v1.7.1.4/git.html[documentation for release 1.7.1.4] - -* release notes for - link:RelNotes/1.7.1.4.txt[1.7.1.4], - link:RelNotes/1.7.1.3.txt[1.7.1.3], - link:RelNotes/1.7.1.2.txt[1.7.1.2], - link:RelNotes/1.7.1.1.txt[1.7.1.1], - link:RelNotes/1.7.1.txt[1.7.1]. - -* link:v1.7.0.9/git.html[documentation for release 1.7.0.9] - -* release notes for - link:RelNotes/1.7.0.9.txt[1.7.0.9], - link:RelNotes/1.7.0.8.txt[1.7.0.8], - link:RelNotes/1.7.0.7.txt[1.7.0.7], - link:RelNotes/1.7.0.6.txt[1.7.0.6], - link:RelNotes/1.7.0.5.txt[1.7.0.5], - link:RelNotes/1.7.0.4.txt[1.7.0.4], - link:RelNotes/1.7.0.3.txt[1.7.0.3], - link:RelNotes/1.7.0.2.txt[1.7.0.2], - link:RelNotes/1.7.0.1.txt[1.7.0.1], - link:RelNotes/1.7.0.txt[1.7.0]. - -* link:v1.6.6.3/git.html[documentation for release 1.6.6.3] - -* release notes for - link:RelNotes/1.6.6.3.txt[1.6.6.3], - link:RelNotes/1.6.6.2.txt[1.6.6.2], - link:RelNotes/1.6.6.1.txt[1.6.6.1], - link:RelNotes/1.6.6.txt[1.6.6]. - -* link:v1.6.5.9/git.html[documentation for release 1.6.5.9] - -* release notes for - link:RelNotes/1.6.5.9.txt[1.6.5.9], - link:RelNotes/1.6.5.8.txt[1.6.5.8], - link:RelNotes/1.6.5.7.txt[1.6.5.7], - link:RelNotes/1.6.5.6.txt[1.6.5.6], - link:RelNotes/1.6.5.5.txt[1.6.5.5], - link:RelNotes/1.6.5.4.txt[1.6.5.4], - link:RelNotes/1.6.5.3.txt[1.6.5.3], - link:RelNotes/1.6.5.2.txt[1.6.5.2], - link:RelNotes/1.6.5.1.txt[1.6.5.1], - link:RelNotes/1.6.5.txt[1.6.5]. - -* link:v1.6.4.5/git.html[documentation for release 1.6.4.5] - -* release notes for - link:RelNotes/1.6.4.5.txt[1.6.4.5], - link:RelNotes/1.6.4.4.txt[1.6.4.4], - link:RelNotes/1.6.4.3.txt[1.6.4.3], - link:RelNotes/1.6.4.2.txt[1.6.4.2], - link:RelNotes/1.6.4.1.txt[1.6.4.1], - link:RelNotes/1.6.4.txt[1.6.4]. - -* link:v1.6.3.4/git.html[documentation for release 1.6.3.4] - -* release notes for - link:RelNotes/1.6.3.4.txt[1.6.3.4], - link:RelNotes/1.6.3.3.txt[1.6.3.3], - link:RelNotes/1.6.3.2.txt[1.6.3.2], - link:RelNotes/1.6.3.1.txt[1.6.3.1], - link:RelNotes/1.6.3.txt[1.6.3]. - -* release notes for - link:RelNotes/1.6.2.5.txt[1.6.2.5], - link:RelNotes/1.6.2.4.txt[1.6.2.4], - link:RelNotes/1.6.2.3.txt[1.6.2.3], - link:RelNotes/1.6.2.2.txt[1.6.2.2], - link:RelNotes/1.6.2.1.txt[1.6.2.1], - link:RelNotes/1.6.2.txt[1.6.2]. - -* link:v1.6.1.3/git.html[documentation for release 1.6.1.3] - -* release notes for - link:RelNotes/1.6.1.3.txt[1.6.1.3], - link:RelNotes/1.6.1.2.txt[1.6.1.2], - link:RelNotes/1.6.1.1.txt[1.6.1.1], - link:RelNotes/1.6.1.txt[1.6.1]. - -* link:v1.6.0.6/git.html[documentation for release 1.6.0.6] - -* release notes for - link:RelNotes/1.6.0.6.txt[1.6.0.6], - link:RelNotes/1.6.0.5.txt[1.6.0.5], - link:RelNotes/1.6.0.4.txt[1.6.0.4], - link:RelNotes/1.6.0.3.txt[1.6.0.3], - link:RelNotes/1.6.0.2.txt[1.6.0.2], - link:RelNotes/1.6.0.1.txt[1.6.0.1], - link:RelNotes/1.6.0.txt[1.6.0]. - -* link:v1.5.6.6/git.html[documentation for release 1.5.6.6] - -* release notes for - link:RelNotes/1.5.6.6.txt[1.5.6.6], - link:RelNotes/1.5.6.5.txt[1.5.6.5], - link:RelNotes/1.5.6.4.txt[1.5.6.4], - link:RelNotes/1.5.6.3.txt[1.5.6.3], - link:RelNotes/1.5.6.2.txt[1.5.6.2], - link:RelNotes/1.5.6.1.txt[1.5.6.1], - link:RelNotes/1.5.6.txt[1.5.6]. - -* link:v1.5.5.6/git.html[documentation for release 1.5.5.6] - -* release notes for - link:RelNotes/1.5.5.6.txt[1.5.5.6], - link:RelNotes/1.5.5.5.txt[1.5.5.5], - link:RelNotes/1.5.5.4.txt[1.5.5.4], - link:RelNotes/1.5.5.3.txt[1.5.5.3], - link:RelNotes/1.5.5.2.txt[1.5.5.2], - link:RelNotes/1.5.5.1.txt[1.5.5.1], - link:RelNotes/1.5.5.txt[1.5.5]. - -* link:v1.5.4.7/git.html[documentation for release 1.5.4.7] - -* release notes for - link:RelNotes/1.5.4.7.txt[1.5.4.7], - link:RelNotes/1.5.4.6.txt[1.5.4.6], - link:RelNotes/1.5.4.5.txt[1.5.4.5], - link:RelNotes/1.5.4.4.txt[1.5.4.4], - link:RelNotes/1.5.4.3.txt[1.5.4.3], - link:RelNotes/1.5.4.2.txt[1.5.4.2], - link:RelNotes/1.5.4.1.txt[1.5.4.1], - link:RelNotes/1.5.4.txt[1.5.4]. - -* link:v1.5.3.8/git.html[documentation for release 1.5.3.8] - -* release notes for - link:RelNotes/1.5.3.8.txt[1.5.3.8], - link:RelNotes/1.5.3.7.txt[1.5.3.7], - link:RelNotes/1.5.3.6.txt[1.5.3.6], - link:RelNotes/1.5.3.5.txt[1.5.3.5], - link:RelNotes/1.5.3.4.txt[1.5.3.4], - link:RelNotes/1.5.3.3.txt[1.5.3.3], - link:RelNotes/1.5.3.2.txt[1.5.3.2], - link:RelNotes/1.5.3.1.txt[1.5.3.1], - link:RelNotes/1.5.3.txt[1.5.3]. - -* link:v1.5.2.5/git.html[documentation for release 1.5.2.5] - -* release notes for - link:RelNotes/1.5.2.5.txt[1.5.2.5], - link:RelNotes/1.5.2.4.txt[1.5.2.4], - link:RelNotes/1.5.2.3.txt[1.5.2.3], - link:RelNotes/1.5.2.2.txt[1.5.2.2], - link:RelNotes/1.5.2.1.txt[1.5.2.1], - link:RelNotes/1.5.2.txt[1.5.2]. - -* link:v1.5.1.6/git.html[documentation for release 1.5.1.6] - -* release notes for - link:RelNotes/1.5.1.6.txt[1.5.1.6], - link:RelNotes/1.5.1.5.txt[1.5.1.5], - link:RelNotes/1.5.1.4.txt[1.5.1.4], - link:RelNotes/1.5.1.3.txt[1.5.1.3], - link:RelNotes/1.5.1.2.txt[1.5.1.2], - link:RelNotes/1.5.1.1.txt[1.5.1.1], - link:RelNotes/1.5.1.txt[1.5.1]. - -* link:v1.5.0.7/git.html[documentation for release 1.5.0.7] - -* release notes for - link:RelNotes/1.5.0.7.txt[1.5.0.7], - link:RelNotes/1.5.0.6.txt[1.5.0.6], - link:RelNotes/1.5.0.5.txt[1.5.0.5], - link:RelNotes/1.5.0.3.txt[1.5.0.3], - link:RelNotes/1.5.0.2.txt[1.5.0.2], - link:RelNotes/1.5.0.1.txt[1.5.0.1], - link:RelNotes/1.5.0.txt[1.5.0]. - -* documentation for release link:v1.4.4.4/git.html[1.4.4.4], - link:v1.3.3/git.html[1.3.3], - link:v1.2.6/git.html[1.2.6], - link:v1.0.13/git.html[1.0.13]. - -============ - -endif::stalenotes[] +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 ------- @@ -387,7 +44,7 @@ OPTIONS --help:: Prints the synopsis and a list of the most commonly used - commands. If the option '--all' or '-a' is given then all + 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. + @@ -400,7 +57,8 @@ help ...`. 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>`. + <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 @@ -415,6 +73,12 @@ example the following invocations are equivalent: 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. @@ -441,13 +105,28 @@ example the following invocations are equivalent: 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. + Set the path to the repository (".git" directory). 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. ++ +Specifying the location of the ".git" directory using this +option (or `GIT_DIR` environment variable) turns off the +repository discovery that tries to find a directory with +".git" subdirectory (which is how the repository and the +top-level of the working tree are discovered), and tells Git +that you are at the top level of the working tree. If you +are not at the top-level directory of the working tree, you +should tell Git where the top-level of the working tree is, +with the `--work-tree=<path>` option (or `GIT_WORK_TREE` +environment variable) ++ +If you just want to run git as if it was started in `<path>` then use +`git -C <path>`. --work-tree=<path>:: Set the path to the working tree. It can be an absolute path @@ -462,6 +141,11 @@ example the following invocations are equivalent: 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 @@ -492,6 +176,20 @@ example the following invocations are equivalent: 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 ------------ @@ -528,6 +226,26 @@ 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) ----------------------------- @@ -567,8 +285,8 @@ In general, the interrogate commands do not touch the files in the working tree. -Synching repositories -~~~~~~~~~~~~~~~~~~~~~ +Syncing repositories +~~~~~~~~~~~~~~~~~~~~ include::cmds-synchingrepositories.txt[] @@ -694,42 +412,54 @@ 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 Cogito etc. +Git so take care if using a foreign front-end. -'GIT_INDEX_FILE':: +`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_OBJECT_DIRECTORY':: +`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':: +`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. - -'GIT_DIR':: - If the 'GIT_DIR' environment variable is set then it ++ +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. + The `--git-dir` command-line option also sets this value. -'GIT_WORK_TREE':: +`GIT_WORK_TREE`:: Set the path to the root of the working tree. - This can also be controlled by the '--work-tree' command line + This can also be controlled by the `--work-tree` command-line option and the core.worktree configuration variable. -'GIT_NAMESPACE':: +`GIT_NAMESPACE`:: Set the Git namespace; see linkgit:gitnamespaces[7] for details. - The '--namespace' command-line option also sets this value. + The `--namespace` command-line option also sets this value. -'GIT_CEILING_DIRECTORIES':: +`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 @@ -742,42 +472,80 @@ Git so take care if using Cogito etc. 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_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink`. -'GIT_DISCOVERY_ACROSS_FILESYSTEM':: +`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 + 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_DEFAULT_HASH`:: + If this variable is set, the default hash algorithm for new + repositories will be set to this value. This value is currently + ignored when cloning; the setting of the remote repository + is used instead. The default is "sha1". + 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_AUTHOR_NAME`:: + The human-readable name used in the author identity when creating commit or + tag objects, or when writing reflogs. Overrides the `user.name` and + `author.name` configuration settings. + +`GIT_AUTHOR_EMAIL`:: + The email address used in the author identity when creating commit or + tag objects, or when writing reflogs. Overrides the `user.email` and + `author.email` configuration settings. + +`GIT_AUTHOR_DATE`:: + The date used for the author identity when creating commit or tag objects, or + when writing reflogs. See linkgit:git-commit[1] for valid formats. + +`GIT_COMMITTER_NAME`:: + The human-readable name used in the committer identity when creating commit or + tag objects, or when writing reflogs. Overrides the `user.name` and + `committer.name` configuration settings. + +`GIT_COMMITTER_EMAIL`:: + The email address used in the author identity when creating commit or + tag objects, or when writing reflogs. Overrides the `user.email` and + `committer.email` configuration settings. + +`GIT_COMMITTER_DATE`:: + The date used for the committer identity when creating commit or tag objects, or + when writing reflogs. See linkgit:git-commit[1] for valid formats. + +`EMAIL`:: + The email address used in the author and committer identities if no other + relevant environment variable or configuration setting has been set. Git Diffs ~~~~~~~~~ -'GIT_DIFF_OPTS':: +`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 +`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: + `GIT_EXTERNAL_DIFF` is called with 7 parameters: path old-file old-hex old-mode new-file new-hex new-mode + @@ -791,58 +559,81 @@ where: 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. +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 +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':: +`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':: +`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':: +`GIT_PROGRESS_DELAY`:: + A number controlling how many seconds to delay before showing + optional progress indicators. Defaults to 2. + +`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':: - If this environment variable is set then 'git fetch' - and 'git push' will use this command instead - of 'ssh' when they need to connect to a remote system. - The '$GIT_SSH' command will be given exactly two or - four arguments: the 'username@host' (or just 'host') - from the URL and the shell command to execute on that - remote system, optionally preceded by '-p' (literally) and - the 'port' from the URL when it specifies something other - than the default SSH port. +`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. + -To pass options to the program that you want to list in GIT_SSH -you will need to wrap the program and options into a shell script, -then set GIT_SSH to refer to the shell script. +`$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_ASKPASS':: +`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' + 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_CONFIG_NOSYSTEM':: +`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 @@ -850,7 +641,7 @@ for further details. temporarily to avoid using a buggy `/etc/gitconfig` file while waiting for someone with sufficient permissions to fix it. -'GIT_FLUSH':: +`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 @@ -861,34 +652,135 @@ for further details. 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':: - If this variable is set to "1", "2" or "true" (comparison - is case insensitive), Git will print `trace:` messages on - stderr telling about alias expansion, built-in command - execution and external command execution. - If this variable is set to an integer value greater than 1 - 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 this variable is set to an absolute path - (starting with a '/' character), Git will interpret this - as a file path and will try to write the trace messages - into it. - -'GIT_TRACE_PACK_ACCESS':: - If this variable is set to a path, a file will be created at - the given path logging all accesses to any packs. For each +`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. + 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_TRACE_PACKET':: - If this variable is set, it shows a trace of 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". -GIT_LITERAL_PATHSPECS:: +`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_TRACE_REDACT`:: + By default, when tracing is activated, Git redacts the values of + cookies, the "Authorization:" header, and the "Proxy-Authorization:" + header. Set this variable to `0` to prevent this redaction. + +`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 @@ -897,19 +789,19 @@ GIT_LITERAL_PATHSPECS:: literal paths to Git (e.g., paths previously given to you by `git ls-tree`, `--raw` diff output, etc). -GIT_GLOB_PATHSPECS:: +`GIT_GLOB_PATHSPECS`:: Setting this variable to `1` will cause Git to treat all pathspecs as glob patterns (aka "glob" magic). -GIT_NOGLOB_PATHSPECS:: +`GIT_NOGLOB_PATHSPECS`:: Setting this variable to `1` will cause Git to treat all pathspecs as literal (aka "literal" magic). -GIT_ICASE_PATHSPECS:: +`GIT_ICASE_PATHSPECS`:: Setting this variable to `1` will cause Git to treat all pathspecs as case-insensitive. -'GIT_REFLOG_ACTION':: +`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 @@ -919,6 +811,73 @@ GIT_ICASE_PATHSPECS:: 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]] ------------------------ @@ -1000,7 +959,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.ohloh.net/p/git/contributors/summary +<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 @@ -1012,12 +971,17 @@ 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. +subscribed to the list to send a message there. See the list archive +at https://lore.kernel.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], -link:everyday.html[Everyday Git], linkgit:gitcvs-migration[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] diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index b322a2666c..2d0a03715b 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -3,7 +3,7 @@ gitattributes(5) NAME ---- -gitattributes - defining attributes per path +gitattributes - Defining attributes per path SYNOPSIS -------- @@ -18,12 +18,14 @@ A `gitattributes` file is a simple text file that gives Each line in `gitattributes` file is of form: - pattern attr1 attr2 ... + pattern attr1 attr2 ... That is, a pattern followed by an attributes list, -separated by whitespaces. When the pattern matches the -path in question, the attributes listed on the line are given to -the path. +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: @@ -54,9 +56,16 @@ Unspecified:: When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per -attribute. The rules how the pattern matches paths are the -same as in `.gitignore` files; see linkgit:gitignore[5]. -Unlike `.gitignore`, negative patterns are forbidden. +attribute. + +The rules by which the pattern matches paths are the same as in +`.gitignore` files (see linkgit:gitignore[5]), with a few exceptions: + + - negative patterns are forbidden + + - patterns that match a directory do not recursively match paths + inside that directory (so using the trailing-slash `path/` syntax is + pointless in an attributes file; use `path/**` instead) When deciding what attributes are assigned to a path, Git consults `$GIT_DIR/info/attributes` file (which has the highest @@ -80,13 +89,13 @@ 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]). +`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 an setting of an attribute +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 `!`. @@ -103,7 +112,8 @@ 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 checkout' and 'git merge' run. They also affect how +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'. @@ -115,6 +125,9 @@ 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:: @@ -130,8 +143,9 @@ Unset:: Set to string value "auto":: When `text` is set to "auto", the path is marked for automatic - end-of-line normalization. If Git decides that the content is - text, its line endings are normalized to LF on checkin. + 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:: @@ -146,8 +160,11 @@ unspecified. ^^^^^ This attribute sets a specific line-ending style to be used in the -working directory. It enables end-of-line normalization without any -content checks, effectively setting the `text` attribute. +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":: @@ -180,65 +197,53 @@ While Git normally leaves file contents alone, it can be configured to normalize line endings to LF in the repository and, optionally, to convert them to CRLF when files are checked out. -Here is an example that will make Git normalize .txt, .vcproj and .sh -files, ensure that .vcproj files have CRLF and .sh files have LF in -the working directory, and prevent .jpg files from being normalized -regardless of their content. - ------------------------- -*.txt text -*.vcproj eol=crlf -*.sh eol=lf -*.jpg -text ------------------------- - -Other source code management systems normalize all text files in their -repositories, and there are two ways to enable similar automatic -normalization in Git. - If you simply want to have CRLF line endings in your working directory regardless of the repository you are working with, you can set the -config variable "core.autocrlf" without changing any attributes. +config variable "core.autocrlf" without using any attributes. ------------------------ [core] autocrlf = true ------------------------ -This does not force normalization of all text files, but does ensure +This does not force normalization of text files, but does ensure that text files that you introduce to the repository have their line endings normalized to LF when they are added, and that files that are already normalized in the repository stay normalized. -If you want to interoperate with a source code management system that -enforces end-of-line normalization, or you simply want all text files -in your repository to be normalized, you should instead set the `text` -attribute to "auto" for _all_ files. +If you want to ensure that text files that any contributor introduces to +the repository have their line endings normalized, you can set the +`text` attribute to "auto" for _all_ files. ------------------------ * text=auto ------------------------ -This ensures that all files that Git considers to be text will have -normalized (LF) line endings in the repository. The `core.eol` -configuration variable controls which line endings Git will use for -normalized files in your working directory; the default is to use the -native line ending for your platform, or CRLF if `core.autocrlf` is -set. +The attributes allow a fine-grained control, how the line endings +are converted. +Here is an example that will make Git normalize .txt, .vcproj and .sh +files, ensure that .vcproj files have CRLF and .sh files have LF in +the working directory, and prevent .jpg files from being normalized +regardless of their content. + +------------------------ +* text=auto +*.txt text +*.vcproj text eol=crlf +*.sh text eol=lf +*.jpg -text +------------------------ + +NOTE: When `text=auto` conversion is enabled in a cross-platform +project using push and pull to a central repository the text files +containing CRLFs should be normalized. -NOTE: When `text=auto` normalization is enabled in an existing -repository, any text files containing CRLFs should be normalized. If -they are not they will be normalized the next time someone tries to -change them, causing unfortunate misattribution. From a clean working -directory: +From a clean working directory: ------------------------------------------------- -$ echo "* text=auto" >>.gitattributes -$ rm .git/index # Remove the index to force Git to -$ git reset # re-scan the working directory +$ echo "* text=auto" >.gitattributes +$ git add --renormalize . $ git status # Show files that will be normalized -$ git add -u -$ git add .gitattributes $ git commit -m "Introduce end-of-line normalization" ------------------------------------------------- @@ -277,6 +282,96 @@ few exceptions. Even though... catch potential problems early, safety triggers. +`working-tree-encoding` +^^^^^^^^^^^^^^^^^^^^^^^ + +Git recognizes files encoded in ASCII or one of its supersets (e.g. +UTF-8, ISO-8859-1, ...) as text files. Files encoded in certain other +encodings (e.g. UTF-16) are interpreted as binary and consequently +built-in Git text processing tools (e.g. 'git diff') as well as most Git +web front ends do not visualize the contents of these files by default. + +In these cases you can tell Git the encoding of a file in the working +directory with the `working-tree-encoding` attribute. If a file with this +attribute is added to Git, then Git re-encodes 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 re-encoded 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` ^^^^^^^ @@ -300,7 +395,15 @@ checkout, when the `smudge` command is specified, the command is fed the blob object from its standard input, and its standard output is used to update the worktree file. Similarly, the `clean` command is used to convert the contents of worktree file -upon checkin. +upon checkin. By default these commands process only a single +blob and terminate. If a long running `process` filter is used +in place of `clean` and/or `smudge` filters, then Git can process +all blobs with a single filter command invocation for the entire +life of a single Git command, for example `git add --all`. If a +long running `process` filter is configured then it always takes +precedence over a configured single blob filter. See section +below for the description of the protocol used to communicate with +a `process` filter. One use of the content filtering is to massage the content into a shape that is more convenient for the platform, filesystem, and the user to use. @@ -324,6 +427,9 @@ 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. @@ -374,6 +480,183 @@ substitution. For example: 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 +supported, 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -440,8 +723,8 @@ Unspecified:: A path to which the `diff` attribute is unspecified first gets its contents inspected, and if it looks like - text, it is treated as text. Otherwise it would - generate `Binary files differ`. + text and is smaller than core.bigFileThreshold, it is treated + as text. Otherwise it would generate `Binary files differ`. String:: @@ -525,13 +808,25 @@ patterns are available: - `csharp` suitable for source code in the C# language. +- `css` suitable for cascading style sheets. + +- `dts` suitable for devicetree (DTS) files. + +- `elixir` suitable for source code in the Elixir language. + - `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 language. +- `markdown` suitable for Markdown documents. + +- `matlab` suitable for source code in the MATLAB and Octave languages. - `objc` suitable for source code in the Objective-C language. @@ -545,6 +840,8 @@ patterns are available: - `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. @@ -665,7 +962,7 @@ 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 +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 @@ -680,7 +977,7 @@ 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 +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: @@ -774,7 +1071,7 @@ To define a custom merge driver `filfre`, add a section to your ---------------------------------------------------------------- [merge "filfre"] name = feel-free merge driver - driver = filfre %O %A %B + driver = filfre %O %A %B %L %P recursive = binary ---------------------------------------------------------------- @@ -800,6 +1097,9 @@ 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` ^^^^^^^^^^^^^^^^^^^^^^ @@ -930,17 +1230,20 @@ state. DEFINING MACRO ATTRIBUTES ------------------------- -Custom macro attributes can be defined only in the `.gitattributes` -file at the toplevel (i.e. not in any subdirectory). The built-in -macro attribute "binary" is equivalent to: +Custom macro attributes can be defined only in top-level gitattributes +files (`$GIT_DIR/info/attributes`, the `.gitattributes` file at the +top level of the working tree, or the global or system-wide +gitattributes files), not in `.gitattributes` files in working tree +subdirectories. The built-in macro attribute "binary" is equivalent +to: ------------ [attr]binary -diff -merge -text ------------ -EXAMPLE -------- +EXAMPLES +-------- If you have these three `gitattributes` file: diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index 3146413cce..92e4ba6a2f 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -3,7 +3,7 @@ gitcli(7) NAME ---- -gitcli - Git command line interface and conventions +gitcli - Git command-line interface and conventions SYNOPSIS -------- @@ -28,7 +28,7 @@ arguments. Here are the rules: they can be disambiguated by placing `--` between them. E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work tree. Please show changes between the version I staged in the index - and what I have in the work tree for that file". not "show difference + and what I have in the work tree for that file", not "show difference between the HEAD commit and the work tree as a whole". You can say `git diff HEAD --` to ask for the latter. @@ -37,6 +37,12 @@ arguments. Here are the rules: 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. + + * Because `--` disambiguates revisions and paths in some commands, it + cannot be used for those commands to separate options and revisions. + You can use `--end-of-options` for this (it also works for commands + that do not distinguish between revisions in paths, in which case it + is simply an alias for `--`). + 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 @@ -47,8 +53,8 @@ disambiguating `--` at appropriate places. things: + -------------------------------- -$ git checkout -- *.c -$ git checkout -- \*.c +$ git restore *.c +$ git restore \*.c -------------------------------- + The former lets your shell expand the fileglob, and you are asking @@ -66,29 +72,29 @@ you will. 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 + * 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 'sticked' form. In + * when a command-line option takes an argument, use the 'stuck' form. In other words, write `git foo -oArg` instead of `git foo -o Arg` for short options, and `git foo --long-opt=Arg` instead of `git foo --long-opt Arg` for long options. An option that takes optional option-argument must be - written in the 'sticked' form. + written in the 'stuck' form. * when you give a revision parameter to a command, make sure the parameter is not ambiguous with a name of a file in the work tree. E.g. do not write `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 + * 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 + 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", + new option whose name shares the same prefix, e.g. `--optimize`, to make a short prefix that used to be unique no longer unique. @@ -103,15 +109,15 @@ 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: +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 +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 @@ -120,6 +126,11 @@ usage: git describe [options] <commit-ish>* --long always use long format --abbrev[=<n>] use <n> digits to display SHA-1s --------------------------------------------- ++ +Note that some subcommand (e.g. `git grep`) may behave differently +when there are things on the command line other than `-h`, but `git +subcmd -h` without anything else on the command line is meant to +consistently give the usage. --help-all:: Some Git commands take options that are only used for plumbing or that @@ -149,7 +160,7 @@ 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. +e.g. `git commit --amenity` option. Separating argument from the option @@ -165,7 +176,7 @@ $ git foo -o Arg ---------------------------- However, this is *NOT* allowed for switches with an optional value, where the -'sticked' form must be used: +'stuck' form must be used: ---------------------------- $ git describe --abbrev HEAD # correct $ git describe --abbrev=10 HEAD # correct @@ -194,7 +205,7 @@ different things. * 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 to the working tree, + 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. @@ -205,10 +216,22 @@ only affects the files in the working tree, but with 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 +See also https://lore.kernel.org/git/7v64clg5u9.fsf@assigned-by-dhcp.cox.net/ and +https://lore.kernel.org/git/7vy7ej9g38.fsf@gitster.siamese.dyndns.org/ 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/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 058a352980..c0b95256cc 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -25,7 +25,7 @@ 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 for when the porcelain isn't flushing. +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 @@ -259,7 +259,7 @@ index 557db03..263414f 100644 @@ -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`. @@ -631,7 +631,7 @@ 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. +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 @@ -701,7 +701,7 @@ $ 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 +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 @@ -710,7 +710,7 @@ files). Again, this can all be simplified with ---------------- -$ git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git +$ git clone git://git.kernel.org/pub/scm/git/git.git/ my-git $ cd my-git $ git checkout ---------------- @@ -741,7 +741,7 @@ 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 checkout -b mybranch +$ git switch -c mybranch ------------ will create a new branch based at the current `HEAD` position, and switch @@ -751,11 +751,11 @@ to it. ================================================ 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. +just telling 'git switch' what the base of the checkout would be. In other words, if you have an earlier tag or branch, you'd just do ------------ -$ git checkout -b mybranch earlier-commit +$ git switch -c mybranch earlier-commit ------------ and it would create the new branch `mybranch` at the earlier commit, @@ -765,7 +765,7 @@ and check out the state at that time. You can always just jump back to your original `master` branch by doing ------------ -$ git checkout master +$ git switch master ------------ (or any other branch-name, for that matter) and if you forget which @@ -794,7 +794,7 @@ $ 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 checkout' +on that branch -- switch to that branch with a regular 'git switch' with the branchname as the argument. @@ -808,7 +808,7 @@ being the same as the original `master` branch, let's make sure we're in that branch, and do some work there. ------------------------------------------------ -$ git checkout mybranch +$ git switch mybranch $ echo "Work, work, work" >>hello $ git commit -m "Some work." -i hello ------------------------------------------------ @@ -825,7 +825,7 @@ 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 checkout master +$ git switch master ------------ Here, take a moment to look at the contents of `hello`, and notice how they @@ -949,7 +949,7 @@ 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 +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 @@ -958,7 +958,7 @@ to the `master` branch. Let's go back to `mybranch`, and run 'git merge' to get the "upstream changes" back to your branch. ------------ -$ git checkout mybranch +$ git switch mybranch $ git merge -m "Merge upstream changes." master ------------ @@ -1011,20 +1011,6 @@ $ git fetch <remote-repository> One of the following transports can be used to name the repository to download from: -Rsync:: - `rsync://remote.machine/path/to/repo.git/` -+ -Rsync transport is usable for both uploading and downloading, -but is completely unaware of what git does, and can produce -unexpected results when you download from the public repository -while the repository owner is uploading into it via `rsync` -transport. Most notably, it could update the files under -`refs/` which holds the object name of the topmost commits -before uploading the files in `objects/` -- the downloader would -obtain head commit object name while that object itself is still -not available in the repository. For this reason, it is -considered deprecated. - SSH:: `remote.machine:/path/to/repo.git/` or + @@ -1147,9 +1133,8 @@ Remember, before running 'git merge', our `master` head was at work." commit. ------------ -$ git checkout mybranch -$ git reset --hard master^2 -$ git checkout master +$ git switch -C mybranch master^2 +$ git switch master $ git reset --hard master^ ------------ @@ -1297,7 +1282,7 @@ 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 +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. @@ -1382,7 +1367,7 @@ $ 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 `.git/objects/pack` +packed, and stores the packed file in the `.git/objects/pack` directory. [NOTE] @@ -1430,7 +1415,7 @@ 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, unless rsync transport is used. +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. @@ -1443,7 +1428,7 @@ Although Git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There is a nice illustration (page 17, "Merges to Mainline") in -link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation]. +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 @@ -1464,7 +1449,7 @@ transport protocols (HTTP), you need to keep this repository 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. +'git update-server-info' keeps the necessary files up to date. 3. Push into the public repository from your primary repository. @@ -1492,7 +1477,7 @@ You can repack this private repository whenever you feel like. 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 'git clone' the public +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. @@ -1557,9 +1542,9 @@ like this: Working with Others, Shared Repository Style -------------------------------------------- -If you are coming from CVS background, the style of cooperation +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 "shared public repository" style of +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. @@ -1649,7 +1634,7 @@ $ git show-branch ++* [master~2] Pretty-print messages. ------------ -Note that you should not do Octopus because you can. An octopus +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 @@ -1667,9 +1652,9 @@ linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcvs-migration[7], linkgit:git-help[1], -link:everyday.html[Everyday git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT --- -Part of the linkgit:git[1] suite. +Part of the linkgit:git[1] suite diff --git a/Documentation/gitcredentials.txt b/Documentation/gitcredentials.txt index 47576be5db..9e481aec85 100644 --- a/Documentation/gitcredentials.txt +++ b/Documentation/gitcredentials.txt @@ -32,7 +32,7 @@ strategies to ask the user for usernames and passwords: 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 +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 @@ -101,11 +101,6 @@ $ git help credential-foo $ git config --global credential.helper foo ------------------------------------------- -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. - CREDENTIAL CONTEXTS ------------------- @@ -136,7 +131,15 @@ context would not match: 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. +match: Git compares the protocols exactly. However, you may use wildcards in +the domain name and other pattern matching techniques as with the `http.<url>.*` +options. + +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 @@ -157,6 +160,16 @@ helper:: 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:: @@ -175,8 +188,110 @@ 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. +which you keep credentials. + +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" +[credential] + helper = foo + +# same as above, but pass an argument to the helper +[credential] + helper = "foo --bar=baz" + +# the arguments are parsed by the shell, so use shell +# quoting if necessary +[credential] + helper = "foo --bar='whitespace arg'" + +# you can also use an absolute path, which will not use the git wrapper +[credential] + helper = "/path/to/my/helper --with-arguments" + +# or you can specify your own shell snippet +[credential "https://example.com"] + username = your_user + helper = "!f() { test \"$1\" = get && 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 (see linkgit:git-credential[1] for common +attributes). 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's credential subsystem. + +While it is possible to override all attributes, well behaving helpers +should refrain from doing so for any attribute other than username and +password. + +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). + +Similarly, no more helpers will be consulted once both username and +password had been provided. + +For a `store` or `erase` operation, the helper's output is ignored. + +If a helper fails to perform the requested operation or needs to notify +the user of a potential issue, it may write to stderr. + +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). GIT --- diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt index 5ea94cbceb..1cd1283d0f 100644 --- a/Documentation/gitcvs-migration.txt +++ b/Documentation/gitcvs-migration.txt @@ -116,8 +116,12 @@ they create are writable and searchable by other group members. Importing a CVS archive ----------------------- +NOTE: These instructions use the `git-cvsimport` script which ships with +git, but other importers may provide better results. See the note in +linkgit:git-cvsimport[1] for other options. + First, install version 2.1 or higher of cvsps from -link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make +https://github.com/andreyvit/cvsps[https://github.com/andreyvit/cvsps] and make sure it is in your path. Then cd to a checked out CVS working directory of the project you are interested in and run linkgit:git-cvsimport[1]: @@ -194,9 +198,9 @@ linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcore-tutorial[7], linkgit:gitglossary[7], -link:everyday.html[Everyday Git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT --- -Part of the linkgit:git[1] suite. +Part of the linkgit:git[1] suite diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt index c8b3e51c84..c970d9fe43 100644 --- a/Documentation/gitdiffcore.txt +++ b/Documentation/gitdiffcore.txt @@ -28,8 +28,8 @@ 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 + 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 @@ -84,8 +84,8 @@ format sections of the manual for 'git diff-{asterisk}' commands) or diff-patch format. -diffcore-break: For Splitting Up "Complete Rewrites" ----------------------------------------------------- +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 @@ -119,7 +119,7 @@ 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 Detection Renames and Copies +diffcore-rename: For Detecting Renames and Copies ------------------------------------------------- This transformation is used to detect renames and copies, and is @@ -142,7 +142,7 @@ merges these filepairs and creates: 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 +"--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: @@ -177,8 +177,8 @@ the expense of making it slower. Without `--find-copies-harder`, copied happened to have been modified in the same changeset. -diffcore-merge-broken: For Putting "Complete Rewrites" Back Together --------------------------------------------------------------------- +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 @@ -242,7 +242,8 @@ 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. +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 @@ -288,4 +289,4 @@ link:user-manual.html[The Git User's Manual] GIT --- -Part of the linkgit:git[1] suite. +Part of the linkgit:git[1] suite diff --git a/Documentation/everyday.txt b/Documentation/giteveryday.txt index 2a18c1f6f2..faba2ef088 100644 --- a/Documentation/everyday.txt +++ b/Documentation/giteveryday.txt @@ -1,22 +1,37 @@ +giteveryday(7) +============== + +NAME +---- +giteveryday - A useful minimum set of commands for Everyday Git + +SYNOPSIS +-------- + Everyday Git With 20 Commands Or So -=================================== -<<Individual Developer (Standalone)>> commands are essential for -anybody who makes a commit, even for somebody who works alone. +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. -If you work with other people, you will need commands listed in -the <<Individual Developer (Participant)>> section as well. +* <<STANDALONE,Individual Developer (Standalone)>> commands are essential + for anybody who makes a commit, even for somebody who works alone. -People who play the <<Integrator>> role need to learn some more -commands in addition to the above. +* If you work with other people, you will need commands listed in + the <<PARTICIPANT,Individual Developer (Participant)>> section as well. -<<Repository Administration>> commands are for system -administrators who are responsible for the care and feeding -of Git repositories. +* 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)[[Individual Developer (Standalone)]] ----------------------------------------------------------------------- + +Individual Developer (Standalone)[[STANDALONE]] +----------------------------------------------- A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the @@ -24,11 +39,9 @@ following commands. * linkgit:git-init[1] to create a new repository. - * linkgit:git-show-branch[1] to see where you are. - * linkgit:git-log[1] to see what happened. - * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch + * linkgit:git-switch[1] and linkgit:git-branch[1] to switch branches. * linkgit:git-add[1] to manage the index file. @@ -38,14 +51,13 @@ following commands. * linkgit:git-commit[1] to advance the current branch. - * linkgit:git-reset[1] and linkgit:git-checkout[1] (with - pathname parameters) to undo changes. + * 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 known point. + * linkgit:git-tag[1] to mark a known point. Examples ~~~~~~~~ @@ -67,22 +79,20 @@ $ git tag v2.43 <2> Create a topic branch and develop.:: + ------------ -$ git checkout -b alsa-audio <1> +$ git switch -c alsa-audio <1> $ edit/compile/test -$ git checkout -- curses/ux_audio_oss.c <2> +$ 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 reset --soft HEAD^ <6> -$ edit/compile/test -$ git diff ORIG_HEAD <7> -$ git commit -a -c ORIG_HEAD <8> -$ git checkout master <9> -$ git merge alsa-audio <10> -$ git log --since='3 days ago' <11> -$ git log v2.43.. curses/ <12> +$ 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. @@ -90,22 +100,21 @@ $ git log v2.43.. curses/ <12> <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> take the last commit back, keeping what is in the working tree. -<7> look at the changes since the premature commit we took back. -<8> redo the commit undone in the previous step, using the message -you originally wrote. -<9> switch to the master branch. -<10> merge a topic branch into your master branch. -<11> review commit logs; other forms to limit output can be -combined and include `--max-count=10` (show 10 commits), +<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. -<12> view only the changes that touch what's in `curses/` +<11> view only the changes that touch what's in `curses/` directory, since `v2.43` tag. -Individual Developer (Participant)[[Individual Developer (Participant)]] ------------------------------------------------------------------------- +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 @@ -123,6 +132,13 @@ addition to the ones needed by a standalone developer. * 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 ~~~~~~~~ @@ -131,28 +147,34 @@ 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 -$ edit/compile/test; git commit -a -s <1> -$ git format-patch origin <2> -$ git pull <3> -$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4> -$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5> -$ git reset --hard ORIG_HEAD <6> -$ git gc <7> -$ git fetch --tags <8> +$ 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> repeat as needed. -<2> extract patches from your branch for e-mail submission. -<3> `git pull` fetches from `origin` by default and merges into the +<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. -<4> immediately after pulling, look at the changes done upstream +<7> immediately after pulling, look at the changes done upstream since last time we checked, only in the area we are interested in. -<5> fetch from a specific branch from a specific repository and merge. -<6> revert the pull. -<7> garbage collect leftover objects from reverted pull. -<8> from time to time, obtain official tags from the `origin` -and store them under `.git/refs/tags/`. +<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.:: @@ -166,12 +188,12 @@ remote.origin.fetch refs/heads/*:refs/remotes/origin/* branch.master.remote origin branch.master.merge refs/heads/master satellite$ git config remote.origin.push \ - master:refs/remotes/satellite/master <3> + +refs/heads/*:refs/remotes/satellite/* <3> satellite$ edit/compile/test/commit satellite$ git push origin <4> mothership$ cd frotz -mothership$ git checkout master +mothership$ git switch master mothership$ git merge satellite/master <5> ------------ + @@ -181,31 +203,37 @@ 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 local `master` branch to -`remotes/satellite/master` branch of the mothership machine. -<4> push will stash our work away on `remotes/satellite/master` -remote-tracking branch on the mothership machine. You could use this -as a back-up method. +<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 checkout -b private2.6.14 v2.6.14 <1> +$ git switch -c private2.6.14 v2.6.14 <1> $ edit/compile/test; git commit -a $ git checkout master -$ git format-patch -k -m --stdout v2.6.14..private2.6.14 | - git am -3 -k <2> +$ 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". +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]] +Integrator[[INTEGRATOR]] ------------------------ A fairly central person acting as the integrator in a group @@ -213,6 +241,13 @@ 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. @@ -229,71 +264,72 @@ commands in addition to the ones needed by participants. Examples ~~~~~~~~ -My typical Git day.:: +A typical integrator's Git day.:: + ------------ $ git status <1> -$ git show-branch <2> +$ git branch --no-merged master <2> $ mailx <3> & s 2 3 4 5 ./+to-apply & s 7 8 ./+hold-linus & q -$ git checkout -b topic/one master -$ git am -3 -i -s -u ./+to-apply <4> +$ git switch -c topic/one master +$ git am -3 -i -s ./+to-apply <4> $ compile/test -$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5> -$ git checkout topic/one && git rebase master <6> -$ git checkout pu && git reset --hard next <7> +$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5> +$ git switch topic/one && git rebase master <6> +$ git switch -C seen next <7> $ git merge topic/one topic/two && git merge hold/linus <8> -$ git checkout maint +$ 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 && git show-branch master maint 'tags/ko-*' <11> -$ git push ko <12> -$ git push ko v0.99.9x <13> +$ git fetch ko && for branch in master maint next seen <11> + do + git show-branch ko/$branch $branch <12> + done +$ git push --follow-tags ko <13> ------------ + -<1> see what I was in the middle of doing, if any. -<2> see what topic branches I have and think about how ready -they are. +<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 `seen`. <3> read mails, save ones that are applicable, and save others -that are not quite ready. -<4> apply them, interactively, with my sign-offs. -<5> create topic branch as needed and apply, again with my -sign-offs. +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, nor exposed as a part of a stable branch. -<7> restart `pu` every time from the next. +master or exposed as a part of a stable branch. +<7> restart `seen` 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 I did not accidentally rewind master beyond what I -already pushed out. `ko` shorthand points at the repository I have -at kernel.org, and looks like this: -+ +<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: + ------------ -$ cat .git/remotes/ko -URL: kernel.org:/pub/scm/git/git.git -Pull: master:refs/tags/ko-master -Pull: next:refs/tags/ko-next -Pull: maint:refs/tags/ko-maint -Push: master -Push: next -Push: +pu -Push: maint +(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/seen + push = refs/heads/maint ------------ -+ -In the output from `git show-branch`, `master` should have -everything `ko-master` has, and `next` should have -everything `ko-next` has. -<12> push out the bleeding edge. -<13> push the tag out, too. - -Repository Administration[[Repository Administration]] ------------------------------------------------------- +Repository Administration[[ADMINISTRATION]] +------------------------------------------- A repository administrator uses the following tools to set up and maintain access to the repository by developers. @@ -304,9 +340,19 @@ and maintain access to the repository by developers. * 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 ~~~~~~~~ @@ -335,22 +381,25 @@ $ cat /etc/xinetd.d/git-daemon # 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 + 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.:: +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> @@ -363,8 +412,8 @@ $ grep git /etc/shells <2> ------------ + <1> log-in shell is set to /usr/bin/git-shell, which does not -allow anything but `git push` and `git pull`. The users should -get an ssh access to the machine. +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. @@ -401,13 +450,6 @@ for branch policy control. david is the release manager and is the only person who can create and push version tags. -HTTP server to support dumb protocol transfer.:: -+ ------------- -dev$ git update-server-info <1> -dev$ ftp user@isp.example.com <2> -ftp> cp -r .git /home/user/myproject.git ------------- -+ -<1> make sure your info/refs and objects/info/packs are up-to-date -<2> upload to public HTTP server hosted by your ISP. +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt new file mode 100644 index 0000000000..9cd7a592ac --- /dev/null +++ b/Documentation/gitfaq.txt @@ -0,0 +1,355 @@ +gitfaq(7) +========= + +NAME +---- +gitfaq - Frequently asked questions about using Git + +SYNOPSIS +-------- +gitfaq + +DESCRIPTION +----------- + +The examples in this FAQ assume a standard POSIX shell, like `bash` or `dash`, +and a user, A U Thor, who has the account `author` on the hosting provider +`git.example.org`. + +Configuration +------------- + +[[user-name]] +What should I put in `user.name`?:: + You should put your personal name, generally a form using a given name + and family name. For example, the current maintainer of Git uses "Junio + C Hamano". This will be the name portion that is stored in every commit + you make. ++ +This configuration doesn't have any effect on authenticating to remote services; +for that, see `credential.username` in linkgit:git-config[1]. + +[[http-postbuffer]] +What does `http.postBuffer` really do?:: + This option changes the size of the buffer that Git uses when pushing + data to a remote over HTTP or HTTPS. If the data is larger than this + size, libcurl, which handles the HTTP support for Git, will use chunked + transfer encoding since it isn't known ahead of time what the size of + the pushed data will be. ++ +Leaving this value at the default size is fine unless you know that either the +remote server or a proxy in the middle doesn't support HTTP/1.1 (which +introduced the chunked transfer encoding) or is known to be broken with chunked +data. This is often (erroneously) suggested as a solution for generic push +problems, but since almost every server and proxy supports at least HTTP/1.1, +raising this value usually doesn't solve most push problems. A server or proxy +that didn't correctly support HTTP/1.1 and chunked transfer encoding wouldn't be +that useful on the Internet today, since it would break lots of traffic. ++ +Note that increasing this value will increase the memory used on every relevant +push that Git does over HTTP or HTTPS, since the entire buffer is allocated +regardless of whether or not it is all used. Thus, it's best to leave it at the +default unless you are sure you need a different value. + +[[configure-editor]] +How do I configure a different editor?:: + If you haven't specified an editor specifically for Git, it will by default + use the editor you've configured using the `VISUAL` or `EDITOR` environment + variables, or if neither is specified, the system default (which is usually + `vi`). Since some people find `vi` difficult to use or prefer a different + editor, it may be desirable to change the editor used. ++ +If you want to configure a general editor for most programs which need one, you +can edit your shell configuration (e.g., `~/.bashrc` or `~/.zshenv`) to contain +a line setting the `EDITOR` or `VISUAL` environment variable to an appropriate +value. For example, if you prefer the editor `nano`, then you could write the +following: ++ +---- +export VISUAL=nano +---- ++ +If you want to configure an editor specifically for Git, you can either set the +`core.editor` configuration value or the `GIT_EDITOR` environment variable. You +can see linkgit:git-var[1] for details on the order in which these options are +consulted. ++ +Note that in all cases, the editor value will be passed to the shell, so any +arguments containing spaces should be appropriately quoted. Additionally, if +your editor normally detaches from the terminal when invoked, you should specify +it with an argument that makes it not do that, or else Git will not see any +changes. An example of a configuration addressing both of these issues on +Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`, +which quotes the filename with spaces and specifies the `--nofork` option to +avoid backgrounding the process. + +Credentials +----------- + +[[http-credentials]] +How do I specify my credentials when pushing over HTTP?:: + The easiest way to do this is to use a credential helper via the + `credential.helper` configuration. Most systems provide a standard + choice to integrate with the system credential manager. For example, + Git for Windows provides the `wincred` credential manager, macOS has the + `osxkeychain` credential manager, and Unix systems with a standard + desktop environment can use the `libsecret` credential manager. All of + these store credentials in an encrypted store to keep your passwords or + tokens secure. ++ +In addition, you can use the `store` credential manager which stores in a file +in your home directory, or the `cache` credential manager, which does not +permanently store your credentials, but does prevent you from being prompted for +them for a certain period of time. ++ +You can also just enter your password when prompted. While it is possible to +place the password (which must be percent-encoded) in the URL, this is not +particularly secure and can lead to accidental exposure of credentials, so it is +not recommended. + +[[http-credentials-environment]] +How do I read a password or token from an environment variable?:: + The `credential.helper` configuration option can also take an arbitrary + shell command that produces the credential protocol on standard output. + This is useful when passing credentials into a container, for example. ++ +Such a shell command can be specified by starting the option value with an +exclamation point. If your password or token were stored in the `GIT_TOKEN`, +you could run the following command to set your credential helper: ++ +---- +$ git config credential.helper \ + '!f() { echo username=author; echo "password=$GIT_TOKEN"; };f' +---- + +[[http-reset-credentials]] +How do I change the password or token I've saved in my credential manager?:: + Usually, if the password or token is invalid, Git will erase it and + prompt for a new one. However, there are times when this doesn't always + happen. To change the password or token, you can erase the existing + credentials and then Git will prompt for new ones. To erase + credentials, use a syntax like the following (substituting your username + and the hostname): ++ +---- +$ echo url=https://author@git.example.org | git credential reject +---- + +[[multiple-accounts-http]] +How do I use multiple accounts with the same hosting provider using HTTP?:: + Usually the easiest way to distinguish between these accounts is to use + the username in the URL. For example, if you have the accounts `author` + and `committer` on `git.example.org`, you can use the URLs + https://author@git.example.org/org1/project1.git and + https://committer@git.example.org/org2/project2.git. This way, when you + use a credential helper, it will automatically try to look up the + correct credentials for your account. If you already have a remote set + up, you can change the URL with something like `git remote set-url + origin https://author@git.example.org/org1/project1.git` (see + linkgit:git-remote[1] for details). + +[[multiple-accounts-ssh]] +How do I use multiple accounts with the same hosting provider using SSH?:: + With most hosting providers that support SSH, a single key pair uniquely + identifies a user. Therefore, to use multiple accounts, it's necessary + to create a key pair for each account. If you're using a reasonably + modern OpenSSH version, you can create a new key pair with something + like `ssh-keygen -t ed25519 -f ~/.ssh/id_committer`. You can then + register the public key (in this case, `~/.ssh/id_committer.pub`; note + the `.pub`) with the hosting provider. ++ +Most hosting providers use a single SSH account for pushing; that is, all users +push to the `git` account (e.g., `git@git.example.org`). If that's the case for +your provider, you can set up multiple aliases in SSH to make it clear which key +pair to use. For example, you could write something like the following in +`~/.ssh/config`, substituting the proper private key file: ++ +---- +# This is the account for author on git.example.org. +Host example_author + HostName git.example.org + User git + # This is the key pair registered for author with git.example.org. + IdentityFile ~/.ssh/id_author + IdentitiesOnly yes +# This is the account for committer on git.example.org. +Host example_committer + HostName git.example.org + User git + # This is the key pair registered for committer with git.example.org. + IdentityFile ~/.ssh/id_committer + IdentitiesOnly yes +---- ++ +Then, you can adjust your push URL to use `git@example_author` or +`git@example_committer` instead of `git@example.org` (e.g., `git remote set-url +git@example_author:org1/project1.git`). + +Common Issues +------------- + +[[last-commit-amend]] +I've made a mistake in the last commit. How do I change it?:: + You can make the appropriate change to your working tree, run `git add + <file>` or `git rm <file>`, as appropriate, to stage it, and then `git + commit --amend`. Your change will be included in the commit, and you'll + be prompted to edit the commit message again; if you wish to use the + original message verbatim, you can use the `--no-edit` option to `git + commit` in addition, or just save and quit when your editor opens. + +[[undo-previous-change]] +I've made a change with a bug and it's been included in the main branch. How should I undo it?:: + The usual way to deal with this is to use `git revert`. This preserves + the history that the original change was made and was a valuable + contribution, but also introduces a new commit that undoes those changes + because the original had a problem. The commit message of the revert + indicates the commit which was reverted and is usually edited to include + an explanation as to why the revert was made. + +[[ignore-tracked-files]] +How do I ignore changes to a tracked file?:: + Git doesn't provide a way to do this. The reason is that if Git needs + to overwrite this file, such as during a checkout, it doesn't know + whether the changes to the file are precious and should be kept, or + whether they are irrelevant and can safely be destroyed. Therefore, it + has to take the safe route and always preserve them. ++ +It's tempting to try to use certain features of `git update-index`, namely the +assume-unchanged and skip-worktree bits, but these don't work properly for this +purpose and shouldn't be used this way. ++ +If your goal is to modify a configuration file, it can often be helpful to have +a file checked into the repository which is a template or set of defaults which +can then be copied alongside and modified as appropriate. This second, modified +file is usually ignored to prevent accidentally committing it. + +[[files-in-gitignore-are-tracked]] +I asked Git to ignore various files, yet they are still tracked:: + A `gitignore` file ensures that certain file(s) which are not + tracked by Git remain untracked. However, sometimes particular + file(s) may have been tracked before adding them into the + `.gitignore`, hence they still remain tracked. To untrack and + ignore files/patterns, use `git rm --cached <file/pattern>` + and add a pattern to `.gitignore` that matches the <file>. + See linkgit:gitignore[5] for details. + +[[fetching-and-pulling]] +How do I know if I want to do a fetch or a pull?:: + A fetch stores a copy of the latest changes from the remote + repository, without modifying the working tree or current branch. + You can then at your leisure inspect, merge, rebase on top of, or + ignore the upstream changes. A pull consists of a fetch followed + immediately by either a merge or rebase. See linkgit:git-pull[1]. + +Hooks +----- + +[[restrict-with-hooks]] +How do I use hooks to prevent users from making certain changes?:: + The only safe place to make these changes is on the remote repository + (i.e., the Git server), usually in the `pre-receive` hook or in a + continuous integration (CI) system. These are the locations in which + policy can be enforced effectively. ++ +It's common to try to use `pre-commit` hooks (or, for commit messages, +`commit-msg` hooks) to check these things, which is great if you're working as a +solo developer and want the tooling to help you. However, using hooks on a +developer machine is not effective as a policy control because a user can bypass +these hooks with `--no-verify` without being noticed (among various other ways). +Git assumes that the user is in control of their local repositories and doesn't +try to prevent this or tattle on the user. ++ +In addition, some advanced users find `pre-commit` hooks to be an impediment to +workflows that use temporary commits to stage work in progress or that create +fixup commits, so it's better to push these kinds of checks to the server +anyway. + +Cross-Platform Issues +--------------------- + +[[windows-text-binary]] +I'm on Windows and my text files are detected as binary.:: + Git works best when you store text files as UTF-8. Many programs on + Windows support UTF-8, but some do not and only use the little-endian + UTF-16 format, which Git detects as binary. If you can't use UTF-8 with + your programs, you can specify a working tree encoding that indicates + which encoding your files should be checked out with, while still + storing these files as UTF-8 in the repository. This allows tools like + linkgit:git-diff[1] to work as expected, while still allowing your tools + to work. ++ +To do so, you can specify a linkgit:gitattributes[5] pattern with the +`working-tree-encoding` attribute. For example, the following pattern sets all +C files to use UTF-16LE-BOM, which is a common encoding on Windows: ++ +---- +*.c working-tree-encoding=UTF-16LE-BOM +---- ++ +You will need to run `git add --renormalize` to have this take effect. Note +that if you are making these changes on a project that is used across platforms, +you'll probably want to make it in a per-user configuration file or in the one +in `$GIT_DIR/info/attributes`, since making it in a `.gitattributes` file in the +repository will apply to all users of the repository. ++ +See the following entry for information about normalizing line endings as well, +and see linkgit:gitattributes[5] for more information about attribute files. + +[[windows-diff-control-m]] +I'm on Windows and git diff shows my files as having a `^M` at the end.:: + By default, Git expects files to be stored with Unix line endings. As such, + the carriage return (`^M`) that is part of a Windows line ending is shown + because it is considered to be trailing whitespace. Git defaults to showing + trailing whitespace only on new lines, not existing ones. ++ +You can store the files in the repository with Unix line endings and convert +them automatically to your platform's line endings. To do that, set the +configuration option `core.eol` to `native` and see the following entry for +information about how to configure files as text or binary. ++ +You can also control this behavior with the `core.whitespace` setting if you +don't wish to remove the carriage returns from your line endings. + +[[recommended-storage-settings]] +What's the recommended way to store files in Git?:: + While Git can store and handle any file of any type, there are some + settings that work better than others. In general, we recommend that + text files be stored in UTF-8 without a byte-order mark (BOM) with LF + (Unix-style) endings. We also recommend the use of UTF-8 (again, + without BOM) in commit messages. These are the settings that work best + across platforms and with tools such as `git diff` and `git merge`. ++ +Additionally, if you have a choice between storage formats that are text based +or non-text based, we recommend storing files in the text format and, if +necessary, transforming them into the other format. For example, a text-based +SQL dump with one record per line will work much better for diffing and merging +than an actual database file. Similarly, text-based formats such as Markdown +and AsciiDoc will work better than binary formats such as Microsoft Word and +PDF. ++ +Similarly, storing binary dependencies (e.g., shared libraries or JAR files) or +build products in the repository is generally not recommended. Dependencies and +build products are best stored on an artifact or package server with only +references, URLs, and hashes stored in the repository. ++ +We also recommend setting a linkgit:gitattributes[5] file to explicitly mark +which files are text and which are binary. If you want Git to guess, you can +set the attribute `text=auto`. For example, the following might be appropriate +in some projects: ++ +---- +# By default, guess. +* text=auto +# Mark all C files as text. +*.c text +# Mark all JPEG files as binary. +*.jpg binary +---- ++ +These settings help tools pick the right format for output such as patches and +result in files being checked out in the appropriate line ending for the +platform. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt index e52de7dbb4..571f640f5c 100644 --- a/Documentation/gitglossary.txt +++ b/Documentation/gitglossary.txt @@ -19,9 +19,9 @@ SEE ALSO linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcvs-migration[7], -link:everyday.html[Everyday Git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT --- -Part of the linkgit:git[1] suite. +Part of the linkgit:git[1] suite diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index d48bf4d6fa..31b601e4bc 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -7,24 +7,37 @@ githooks - Hooks used by Git SYNOPSIS -------- -$GIT_DIR/hooks/* +$GIT_DIR/hooks/* (or \`git config core.hooksPath`/*) DESCRIPTION ----------- -Hooks are little scripts you can place in `$GIT_DIR/hooks` -directory to trigger action at certain points. When -'git init' is run, a handful of example hooks are copied into the -`hooks` directory of the new repository, but by default they are -all disabled. To enable a hook, rename it by removing its `.sample` -suffix. +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. -NOTE: It is also a requirement for a given hook to be executable. -However - in a freshly initialized repository - the `.sample` files are -executable by default. +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]). -This document describes the currently defined hooks. +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 ----- @@ -32,15 +45,15 @@ HOOKS applypatch-msg ~~~~~~~~~~~~~~ -This hook is invoked by 'git am' script. It takes a single +This hook is invoked by linkgit:git-am[1]. It takes a single parameter, the name of the file that holds the proposed commit -log message. Exiting with non-zero status causes -'git am' to abort before applying the patch. +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 (if the project has one). It can also be used to refuse -the commit after inspecting the message file. +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. @@ -48,7 +61,7 @@ The default 'applypatch-msg' hook, when enabled, runs the pre-applypatch ~~~~~~~~~~~~~~ -This hook is invoked by 'git am'. It takes no parameter, and is +This hook is invoked by linkgit:git-am[1]. It takes no parameter, and is invoked after the patch is applied, but before a commit is made. If it exits with non-zero status, then the working tree will not be @@ -63,33 +76,59 @@ The default 'pre-applypatch' hook, when enabled, runs the post-applypatch ~~~~~~~~~~~~~~~ -This hook is invoked by 'git am'. It takes no parameter, +This hook is invoked by linkgit:git-am[1]. It takes no parameter, and is invoked after the patch is applied and a commit is made. This hook is meant primarily for notification, and cannot affect -the outcome of 'git am'. +the outcome of `git am`. pre-commit ~~~~~~~~~~ -This hook is invoked by 'git commit', and can be bypassed -with `--no-verify` option. It takes no parameter, and is +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 non-zero status from this script -causes the 'git commit' to abort. +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 +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. + +pre-merge-commit +~~~~~~~~~~~~~~~~ + +This hook is invoked by linkgit:git-merge[1], and can be bypassed +with the `--no-verify` option. It takes no parameters, and is +invoked after the merge has been carried out successfully and before +obtaining the proposed commit log message to +make a commit. Exiting with a non-zero status from this script +causes the `git merge` command to abort before creating a commit. + +The default 'pre-merge-commit' hook, when enabled, runs the +'pre-commit' hook, if the latter is enabled. + +This hook is invoked with the environment variable +`GIT_EDITOR=:` if the command will not bring up an editor +to modify the commit message. + +If the merge cannot be carried out automatically, the conflicts +need to be resolved and the result committed separately (see +linkgit:git-merge[1]). At that point, this hook will not be executed, +but the 'pre-commit' hook will, if it is enabled. + prepare-commit-msg ~~~~~~~~~~~~~~~~~~ -This hook is invoked by 'git commit' right after preparing the +This hook is invoked by linkgit:git-commit[1] right after preparing the default log message, and before the editor is started. It takes one to three parameters. The first is the name of the file @@ -101,29 +140,28 @@ commit is a merge or a `.git/MERGE_MSG` file exists); `squash` (if a `.git/SQUASH_MSG` file exists); or `commit`, followed by a commit SHA-1 (if a `-c`, `-C` or `--amend` option was given). -If the exit status is non-zero, 'git commit' will abort. +If the exit status is non-zero, `git commit` will abort. The purpose of the hook is to edit the message file in place, and it is not suppressed by the `--no-verify` option. A non-zero exit 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 comments -out the `Conflicts:` part of a merge's commit message. +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 'git commit', and can be bypassed -with `--no-verify` option. It takes a single parameter, the -name of the file that holds the proposed commit log message. -Exiting with non-zero status causes the 'git commit' to -abort. +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 (if the project has one). It can also be used to refuse -the commit after inspecting the message file. +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. @@ -131,16 +169,16 @@ The default 'commit-msg' hook, when enabled, detects duplicate post-commit ~~~~~~~~~~~ -This hook is invoked by 'git commit'. It takes no -parameter, and is invoked after a commit is made. +This hook is invoked by linkgit:git-commit[1]. It takes no parameters, and is +invoked after a commit is made. This hook is meant primarily for notification, and cannot affect -the outcome of 'git commit'. +the outcome of `git commit`. pre-rebase ~~~~~~~~~~ -This hook is called by 'git rebase' and can be used to prevent a +This hook is called by linkgit:git-rebase[1] and can be used to prevent a branch from getting rebased. The hook may be called with one or two parameters. The first parameter is the upstream from which the series was forked. The second parameter is the branch being @@ -149,16 +187,18 @@ rebased, and is not set when rebasing the current branch. post-checkout ~~~~~~~~~~~~~ -This hook is invoked when a 'git checkout' is run after having updated the +This hook is invoked when a linkgit:git-checkout[1] 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 checkout'. +This hook cannot affect the outcome of `git switch` or `git checkout`. -It is also run after 'git clone', unless the --no-checkout (-n) option is +It is also run after linkgit:git-clone[1], unless the `--no-checkout` (`-n`) option is used. The first parameter given to the hook is the null-ref, the second the -ref of the new HEAD and the flag is always 1. +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 @@ -167,24 +207,24 @@ properties. post-merge ~~~~~~~~~~ -This hook is invoked by 'git merge', which happens when a 'git pull' +This hook is invoked by linkgit:git-merge[1], which happens when a `git pull` is done on a local repository. The hook takes a single parameter, a status flag specifying whether or not the merge being done was a squash merge. -This hook cannot affect the outcome of 'git merge' and is not executed, +This hook cannot affect the outcome of `git merge` and is not executed, if the merge failed due to conflicts. This hook can be used in conjunction with a corresponding pre-commit hook to save and restore any form of metadata associated with the working tree -(eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl +(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 'git push' and can be used to prevent a push from taking -place. The hook is called with two parameters which provide the name and -location of the destination remote, if a named remote is not being used both -values will be the same. +This hook is called by linkgit:git-push[1] and can be used to prevent +a push from taking place. The hook is called with two parameters +which provide the name and location of the destination remote, if a +named remote is not being used both values will be the same. Information about what is to be pushed is provided on the hook's standard input with lines of the form: @@ -203,7 +243,7 @@ SHA-1>` will be 40 `0`. If the local commit was specified by something other than a name which could be expanded (such as `HEAD~`, or a SHA-1) it will be supplied as it was originally given. -If this hook exits with a non-zero status, 'git push' will abort without +If this hook exits with a non-zero status, `git push` will abort without pushing anything. Information about why the push is rejected may be sent to the user by writing to standard error. @@ -211,8 +251,8 @@ to the user by writing to standard error. pre-receive ~~~~~~~~~~~ -This hook is invoked by 'git-receive-pack' on the remote repository, -which happens when a 'git push' is done on a local repository. +This hook is invoked by linkgit:git-receive-pack[1] when it reacts to +`git push` and updates reference(s) in its repository. Just before starting to update refs on the remote repository, the pre-receive hook is invoked. Its exit status determines the success or failure of the update. @@ -233,15 +273,27 @@ updated. If the hook exits with zero, updating of individual refs can still be prevented by the <<update,'update'>> hook. Both standard output and standard error output are forwarded to -'git send-pack' on the other end, so you can simply `echo` messages +`git send-pack` on the other end, so you can simply `echo` messages for the user. +The number of push options given on the command line of +`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 'git-receive-pack' on the remote repository, -which happens when a 'git push' is done on a local repository. +This hook is invoked by linkgit:git-receive-pack[1] when it reacts to +`git push` and updates reference(s) in its repository. Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. @@ -251,10 +303,10 @@ three parameters: - the name of the ref being updated, - the old object name stored in the ref, - - and the new objectname to be stored in the ref. + - and the new object name to be stored in the ref. A zero exit from the update hook allows the ref to be updated. -Exiting with a non-zero status prevents 'git-receive-pack' +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 @@ -267,12 +319,14 @@ 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. -Another use suggested on the mailing list is to use this hook to -implement access control which is finer grained than the one -based on filesystem group. +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 +`git send-pack` on the other end, so you can simply `echo` messages for the user. The default 'update' hook, when enabled--and with @@ -283,8 +337,8 @@ unannotated tags to be pushed. post-receive ~~~~~~~~~~~~ -This hook is invoked by 'git-receive-pack' on the remote repository, -which happens when a 'git push' is done on a local repository. +This hook is invoked by linkgit:git-receive-pack[1] when it reacts to +`git push` and updates reference(s) in its repository. It executes on the remote repository once after all the refs have been updated. @@ -293,7 +347,7 @@ arguments, but gets the same information as the <<pre-receive,'pre-receive'>> hook does on its standard input. -This hook does not affect the outcome of 'git-receive-pack', as it +This hook does not affect the outcome of `git receive-pack`, as it is called after the real work is done. This supersedes the <<post-update,'post-update'>> hook in that it gets @@ -301,7 +355,7 @@ both old and new values of all the refs in addition to their names. Both standard output and standard error output are forwarded to -'git send-pack' on the other end, so you can simply `echo` messages +`git send-pack` on the other end, so you can simply `echo` messages for the user. The default 'post-receive' hook is empty, but there is @@ -309,12 +363,21 @@ 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 'git-receive-pack' on the remote repository, -which happens when a 'git push' is done on a local repository. +This hook is invoked by linkgit:git-receive-pack[1] when it reacts to +`git push` and updates reference(s) in its repository. It executes on the remote repository once after all the refs have been updated. @@ -322,7 +385,7 @@ It takes a variable number of parameters, each of which is the name of ref that was actually updated. This hook is meant primarily for notification, and cannot affect -the outcome of 'git-receive-pack'. +the outcome of `git receive-pack`. The 'post-update' hook can tell what are the heads that were pushed, but it does not know what their original and updated values are, @@ -332,30 +395,93 @@ 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 +`git update-server-info` to keep the information used by dumb +transports (e.g., HTTP) up to date. If you are publishing a Git repository that is accessible via HTTP, you should probably enable this hook. Both standard output and standard error output are forwarded to -'git send-pack' on the other end, so you can simply `echo` messages +`git send-pack` on the other end, so you can simply `echo` messages for the user. +reference-transaction +~~~~~~~~~~~~~~~~~~~~~ + +This hook is invoked by any Git command that performs reference +updates. It executes whenever a reference transaction is prepared, +committed or aborted and may thus get called multiple times. + +The hook takes exactly one argument, which is the current state the +given reference transaction is in: + + - "prepared": All reference updates have been queued to the + transaction and references were locked on disk. + + - "committed": The reference transaction was committed and all + references now have their respective new value. + + - "aborted": The reference transaction was aborted, no changes + were performed and the locks have been released. + +For each reference update that was added to the transaction, the hook +receives on standard input a line of the format: + + <old-value> SP <new-value> SP <ref-name> LF + +The exit status of the hook is ignored for any state except for the +"prepared" state. In the "prepared" state, a non-zero exit status will +cause the transaction to be aborted. The hook will not be called with +"aborted" state in that case. + +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'. It takes no parameter, and -exiting with non-zero status from this script causes the 'git gc --auto' -to abort. +This hook is invoked by `git gc --auto` (see linkgit:git-gc[1]). It +takes no parameter, and exiting with non-zero status from this script +causes the `git gc --auto` to abort. post-rewrite ~~~~~~~~~~~~ -This hook is invoked by commands that rewrite commits (`git commit ---amend`, 'git-rebase'; currently 'git-filter-branch' does 'not' call -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. +This hook is invoked by commands that rewrite commits +(linkgit:git-commit[1] when called with `--amend` and +linkgit:git-rebase[1]; however, full-history (re)writing tools like +linkgit:git-fast-import[1] or +https://github.com/newren/git-filter-repo[git-filter-repo] typically +do 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 @@ -367,7 +493,7 @@ 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.txt[1]) has happened, and +"notes.rewrite.<command>" in linkgit:git-config[1]) has happened, and thus has access to these notes. The following command-specific comments apply: @@ -381,6 +507,123 @@ rebase:: 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` or `.git/hooks/fsmonitor-watchmanv2` +depending on the version of the hook to use. + +Version 1 takes two arguments, a version (1) and the time in elapsed +nanoseconds since midnight, January 1, 1970. + +Version 2 takes two arguments, a version (2) and a token that is used +for identifying changes since the token. For watchman this would be +a clock id. This version must output to stdout the new token followed +by a NUL before the list of files. + +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-changelist +~~~~~~~~~~~~~ + +This hook is invoked by `git-p4 submit`. + +The `p4-changelist` hook is executed after the changelist +message has been edited by the user. It can be bypassed with the +`--no-verify` option. It takes a single parameter, the name +of the file that holds the proposed changelist text. Exiting +with a non-zero status causes the command to abort. + +The hook is allowed to edit the changelist file and can be used +to normalize the text into some project standard format. It can +also be used to refuse the Submit after inspect the message file. + +Run `git-p4 submit --help` for details. + +p4-prepare-changelist +~~~~~~~~~~~~~~~~~~~~~ + +This hook is invoked by `git-p4 submit`. + +The `p4-prepare-changelist` hook is executed right after preparing +the default changelist message and before the editor is started. +It takes one parameter, the name of the file that contains the +changelist text. Exiting with a non-zero status from the script +will abort the process. + +The purpose of the hook is to edit the message file in place, +and it is not supressed by the `--no-verify` option. This hook +is called even if `--prepare-p4-only` is set. + +Run `git-p4 submit --help` for details. + +p4-post-changelist +~~~~~~~~~~~~~~~~~~ + +This hook is invoked by `git-p4 submit`. + +The `p4-post-changelist` hook is invoked after the submit has +successfully occured in P4. It takes no parameters and is meant +primarily for notification and cannot affect the outcome of the +git p4 submit action. + +Run `git-p4 submit --help` for details. + +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. It can be bypassed with the `--no-verify` +command line option. 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 --- diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 54e334e3af..d47b1ae296 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -7,7 +7,7 @@ gitignore - Specifies intentionally untracked files to ignore SYNOPSIS -------- -$GIT_DIR/info/exclude, .gitignore +$XDG_CONFIG_HOME/git/ignore, $GIT_DIR/info/exclude, .gitignore DESCRIPTION ----------- @@ -38,7 +38,7 @@ precedence, the last matching pattern decides the outcome): * Patterns read from `$GIT_DIR/info/exclude`. * Patterns read from the file specified by the configuration - variable 'core.excludesfile'. + variable `core.excludesFile`. Which file to place a pattern in depends on how the pattern is meant to be used. @@ -56,7 +56,7 @@ be used. * 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 + `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. @@ -77,55 +77,68 @@ PATTERN FORMAT Put a backslash ("`\`") in front of the first hash for patterns that begin with a hash. + - Trailing spaces are ignored unless they are quoted with backslash + ("`\`"). + - An optional prefix "`!`" which negates the pattern; any matching file excluded by a previous pattern will become - included again. If a negated pattern matches, this will - override lower precedence patterns sources. + included again. It is not possible to re-include a file if a parent + directory of that file is excluded. Git doesn't list excluded + directories for performance reasons, so any patterns on contained + files have no effect, no matter where they are defined. Put a backslash ("`\`") in front of the first "`!`" for patterns that begin with a literal "`!`", for example, "`\!important!.txt`". - - If the pattern ends with a slash, it is removed for the - purpose of the following description, but it would only find - a match with a directory. In other words, `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). - - - If the pattern does not contain a slash '/', Git treats it as - a shell glob pattern and checks for a match against the - pathname relative to the location of the `.gitignore` file - (relative to the toplevel of the work tree if not from a - `.gitignore` file). - - - Otherwise, 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". - - - A leading slash matches the beginning of the pathname. - For example, "/{asterisk}.c" matches "cat-file.c" but not - "mozilla-sha1/sha1.c". + - 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" + "`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 + - 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. + - 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 ----- @@ -133,15 +146,34 @@ NOTES The purpose of gitignore files is to ensure that certain files not tracked by Git remain untracked. -To ignore uncommitted changes in a file that is already tracked, -use 'git update-index {litdd}assume-unchanged'. - 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 [...] @@ -182,10 +214,22 @@ Another example: The second .gitignore prevents Git from ignoring `arch/foo/kernel/vmlinux.lds.S`. +Example to exclude everything except a specific directory `foo/bar` +(note the `/*` - without the slash, the wildcard would also exclude +everything within `foo/bar`): + +-------------------------------------------------------------- + $ cat .gitignore + # exclude everything except directory foo/bar + /* + !/foo + /foo/* + !/foo/bar +-------------------------------------------------------------- + SEE ALSO -------- linkgit:git-rm[1], -linkgit:git-update-index[1], linkgit:gitrepository-layout[5], linkgit:git-check-ignore[1] diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index c17e760184..c653ebb6a8 100644 --- a/Documentation/gitk.txt +++ b/Documentation/gitk.txt @@ -8,7 +8,7 @@ gitk - The Git repository browser SYNOPSIS -------- [verse] -'gitk' [<option>...] [<revs>] [--] [<path>...] +'gitk' [<options>] [<revision range>] [--] [<path>...] DESCRIPTION ----------- @@ -16,21 +16,38 @@ 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. -Historically, gitk was the first repository browser. It's written in tcl/tk -and started off in a separate repository but was later merged into the main -Git repository. - OPTIONS ------- -To control which revisions to show, the command takes options applicable to -the 'git rev-list' command (see linkgit:git-rev-list[1]). -This manual page describes only the most -frequently used options. --n <number>:: ---max-count=<number>:: +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>]:: - Limits the number of commits to show. + 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>:: @@ -40,9 +57,9 @@ frequently used options. Show commits older than a specific date. ---all:: +--date-order:: - Show all branches. + Sort commits by date when possible. --merge:: @@ -51,19 +68,57 @@ frequently used options. that modify the conflicted files and do not exist on all the heads being merged. ---argscmd=<command>:: - Command to be run each time gitk has to determine the list of - <revs> to show. The command is expected to print on its standard - output a list of additional revs to be shown, one per line. - Use this instead of explicitly specifying <revs> if the set of - commits to show may vary between refreshes. - ---select-commit=<ref>:: - - Automatically select the specified commit after loading the graph. - Default behavior is equivalent to specifying '--select-commit=HEAD'. - -<revs>:: +--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, and + <start> and <end> (or <funcname>) must exist in the starting revision. + You can specify this option more than once. Implies `--patch`. + Patch output can be suppressed using `--no-patch`, but other diff formats + (namely `--raw`, `--numstat`, `--shortstat`, `--dirstat`, `--summary`, + `--name-only`, `--name-status`, `--check`) are not currently implemented. ++ +*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 @@ -78,6 +133,23 @@ frequently used options. 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:: @@ -98,18 +170,33 @@ gitk --max-count=100 --all \-- Makefile:: Files ----- -Gitk creates the .gitk file in your $HOME directory to store preferences -such as display options, font, and colors. +User configuration and preferences are stored at: + +* `$XDG_CONFIG_HOME/git/gitk` if it exists, otherwise +* `$HOME/.gitk` if it exists + +If neither of the above exist then `$XDG_CONFIG_HOME/git/gitk` is created and +used by default. If '$XDG_CONFIG_HOME' is not set it defaults to +`$HOME/.config` in all cases. + +History +------- +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. -'gitview(1)':: - A repository browser written in Python using Gtk. It's based on - 'bzrk(1)' and distributed in the contrib area of the Git repository. - 'tig(1)':: A minimal repository browser and Git tool output highlighter written in C using Ncurses. diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt index f7be93f631..539b4e1997 100644 --- a/Documentation/gitmodules.txt +++ b/Documentation/gitmodules.txt @@ -3,7 +3,7 @@ gitmodules(5) NAME ---- -gitmodules - defining submodule properties +gitmodules - Defining submodule properties SYNOPSIS -------- @@ -19,7 +19,7 @@ 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' +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: @@ -35,24 +35,25 @@ submodule.<name>.url:: 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 what to do when the submodule is updated by the superproject. - If 'checkout' (the default), the new commit specified in the - superproject will be checked out in the submodule on a detached HEAD. - If 'rebase', the current branch of the submodule will be rebased onto - the commit specified in the superproject. If 'merge', the commit - specified in the superproject will be merged into the current branch - in the submodule. - If 'none', the submodule with name `$name` will not be updated - by default. - - This config option is overridden if 'git submodule update' is given - the '--merge', '--rebase' or '--checkout' options. + 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. For security + reasons, the '!command' form is not accepted here. submodule.<name>.branch:: A remote branch name for tracking updates in the upstream submodule. - If the option is not specified, it defaults to 'master'. See the - `--remote` documentation in linkgit:git-submodule[1] for details. + If the option is not specified, it defaults to the remote 'HEAD'. + 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 @@ -64,19 +65,38 @@ submodule.<name>.fetchRecurseSubmodules:: 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, "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. - 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. + 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 modifications 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-submodules" 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 @@ -84,22 +104,23 @@ 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 +---- +[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 +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] +linkgit:git-submodule[1], linkgit:gitsubmodules[7], linkgit:git-config[1] GIT --- diff --git a/Documentation/gitnamespaces.txt b/Documentation/gitnamespaces.txt index 7685e3651a..b614969ad2 100644 --- a/Documentation/gitnamespaces.txt +++ b/Documentation/gitnamespaces.txt @@ -61,22 +61,4 @@ For a simple local test, you can use linkgit:git-remote-ext[1]: git clone ext::'git --namespace=foo %s /tmp/prefixed.git' ---------- -SECURITY --------- - -Anyone with access to any namespace within a repository can potentially -access objects from any other namespace stored in the same repository. -You can't directly say "give me object ABCD" if you don't have a ref to -it, but you can do some other sneaky things like: - -. Claiming to push ABCD, at which point the server will optimize out the - need for you to actually send it. Now you have a ref to ABCD and can - fetch it (claiming not to have it, of course). - -. Requesting other refs, claiming that you have ABCD, at which point the - server may generate deltas against ABCD. - -None of this causes a problem if you only host public repositories, or -if everyone who may read one namespace may also read everything in every -other namespace (for instance, if everyone in an organization has read -permission to every repository). +include::transfer-data-leaks.txt[] diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt index f1f4ca9727..6f1e269ae4 100644 --- a/Documentation/gitremote-helpers.txt +++ b/Documentation/gitremote-helpers.txt @@ -1,4 +1,4 @@ -gitremote-helpers(1) +gitremote-helpers(7) ==================== NAME @@ -43,7 +43,7 @@ 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 +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. @@ -61,10 +61,10 @@ 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 +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. +`remote.<name>.url`; otherwise, the second argument is omitted. INPUT FORMAT ------------ @@ -102,6 +102,14 @@ Capabilities for Pushing + Supported commands: 'connect'. +'stateless-connect':: + Experimental; for internal use only. + Can attempt to connect to a remote server for communication + using git's wire-protocol version 2. See the documentation + for the stateless-connect command for more information. ++ +Supported commands: 'stateless-connect'. + 'push':: Can discover remote refs and push local commits and the history leading up to them to new or existing remote refs. @@ -136,6 +144,14 @@ Capabilities for Fetching + Supported commands: 'connect'. +'stateless-connect':: + Experimental; for internal use only. + Can attempt to connect to a remote server for communication + using git's wire-protocol version 2. See the documentation + for the stateless-connect command for more information. ++ +Supported commands: 'stateless-connect'. + 'fetch':: Can discover remote refs and transfer objects reachable from them to the local object store. @@ -210,18 +226,21 @@ the remote repository. '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]. + 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]. + 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'. + `--signed-tags=verbatim` to linkgit:git-fast-export[1]. In the + absence of this capability, Git will use `--signed-tags=warn-strip`. +'object-format':: + This indicates that the helper is able to interact with the remote + side using an explicit hash algorithm extension. COMMANDS @@ -241,12 +260,14 @@ 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. + a symref, ":<keyword> <value>" for a key-value pair, 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. +See REF LIST KEYWORDS for a list of currently defined keywords. + Supported if the helper has the "fetch" or "import" capability. @@ -281,9 +302,13 @@ Supported if the helper has the "option" capability. 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. +Optionally may output a 'lock <file>' line indicating the full path of +a file under `$GIT_DIR/objects/pack` which is keeping a pack until +refs can be suitably updated. The path must end with `.keep`. This is +a mechanism to name a <pack,idx,keep> tuple by giving only the keep +component. The kept pack will not be deleted by a concurrent repack, +even though its objects may not be referenced until the fetch completes. +The `.keep` file will be deleted at the conclusion of the fetch. + If option 'check-connectivity' is requested, the helper must output 'connectivity-ok' if the clone is self-contained and connected. @@ -298,7 +323,7 @@ Supported if the helper has the "fetch" capability. 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 + the local `HEAD` to the remote 'branch', and the second asking to push ref 'foo' to ref 'bar' (forced update requested by the '+'). + @@ -375,6 +400,24 @@ Supported if the helper has the "export" capability. + Supported if the helper has the "connect" capability. +'stateless-connect' <service>:: + Experimental; for internal use only. + Connects to the given remote service for communication using + git's wire-protocol version 2. Valid replies to this command + are empty line (connection established), 'fallback' (no smart + transport support, fall back to dumb transports) and just + exiting with error message printed (can't connect, don't bother + trying to fall back). After line feed terminating the positive + (empty) response, the output of the service starts. Messages + (both request and response) must consist of zero or more + PKT-LINEs, terminating in a flush packet. Response messages will + then have a response end packet after the flush packet to + indicate the end of a response. 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 @@ -394,6 +437,18 @@ attributes are defined. This ref is unchanged since the last import or fetch, although the helper cannot necessarily determine what value that produced. +REF LIST KEYWORDS +----------------- + +The 'list' command may produce a list of key-value pairs. +The following keys are defined. + +'object-format':: + The refs are using the given hash algorithm. This keyword is only + used if the server and client both support the object-format + extension. + + OPTIONS ------- @@ -408,14 +463,25 @@ set by Git if the remote helper has the 'option' capability. of <n> correspond to the number of -v flags passed on the command line. -'option progress' \{'true'|'false'\}:: +'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 followtags' \{'true'|'false'\}:: +'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 @@ -423,9 +489,9 @@ set by Git if the remote helper has the 'option' capability. 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'\}: +'option dry-run' {'true'|'false'}: If true, pretend the operation completed successfully, - but don't actually change any repository data. For most + 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>':: @@ -434,14 +500,56 @@ set by Git if the remote helper has the 'option' capability. must not rely on this option being set before connect request occurs. -'option check-connectivity' \{'true'|'false'\}:: +'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. + +'option atomic' {'true'|'false'}:: + When pushing, request the remote server to update refs in a single atomic + transaction. If successful, all refs will be updated, or none will. If the + remote side does not support this capability, the push will fail. + +'option object-format' {'true'|algorithm}:: + If 'true', indicate that the caller wants hash algorithm information + to be passed back from the remote. This mode is used when fetching + refs. ++ +If set to an algorithm, indicate that the caller wants to interact with +the remote side using that algorithm. + SEE ALSO -------- linkgit:git-remote[1] -linkgit:git-remote-testgit[1] +linkgit:git-remote-ext[1] + +linkgit:git-remote-fd[1] + +linkgit:git-fast-import[1] GIT --- diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index aa03882ddb..1a2ef4c150 100644 --- a/Documentation/gitrepository-layout.txt +++ b/Documentation/gitrepository-layout.txt @@ -46,6 +46,9 @@ 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. @@ -56,7 +59,7 @@ objects/[0-9a-f][0-9a-f]:: here are often called 'unpacked' (or 'loose') objects. objects/pack:: - Packs (files that store many object in compressed form, + Packs (files that store many objects in compressed form, along with index files to allow them to be randomly accessed) are found in this directory. @@ -68,7 +71,7 @@ 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 + to keep this file up to date if the repository is published for dumb transports. 'git repack' does this by default. @@ -81,7 +84,7 @@ objects/info/alternates:: 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'. + is the same. See also `objects/info/http-alternates`. objects/info/http-alternates:: This file records URLs to alternate object stores that @@ -93,6 +96,9 @@ refs:: 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, + refs/rewritten 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` @@ -114,7 +120,8 @@ refs/replace/`<obj-sha1>`:: 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]. + 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 @@ -133,6 +140,16 @@ 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'. @@ -140,7 +157,10 @@ branches:: '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. + 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 @@ -149,15 +169,27 @@ hooks:: 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. + 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. + 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 @@ -176,6 +208,10 @@ info/grafts:: per line describes a commit and its fake parents by listing their 40-byte hexadecimal object names separated by a space and terminated by a newline. ++ +Note that the grafts mechanism is outdated and can lead to problems +transferring objects between repositories; see linkgit:git-replace[1] +for a more flexible and robust system to do the same thing. info/exclude:: This file, by convention among Porcelains, stores the @@ -184,6 +220,10 @@ info/exclude:: '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]. @@ -193,12 +233,15 @@ remotes:: 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. + 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. + Records of changes made to refs are stored in this directory. + See linkgit:git-update-ref[1] for more information. This + directory is ignored (except logs/HEAD) 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`. @@ -209,11 +252,46 @@ logs/refs/tags/`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]. + 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], @@ -227,4 +305,4 @@ link:user-manual.html[The Git User's Manual] GIT --- -Part of the linkgit:git[1] suite. +Part of the linkgit:git[1] suite diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevisions.txt index c0ed6d1925..d407b7dee1 100644 --- a/Documentation/gitrevisions.txt +++ b/Documentation/gitrevisions.txt @@ -1,9 +1,9 @@ gitrevisions(7) -================ +=============== NAME ---- -gitrevisions - specifying revisions and ranges for Git +gitrevisions - Specifying revisions and ranges for Git SYNOPSIS -------- @@ -15,13 +15,14 @@ DESCRIPTION Many Git commands take revision parameters as arguments. Depending on the command, they denote a specific commit or, for commands which -walk the revision graph (such as linkgit:git-log[1]), all commits which can -be reached from that commit. In the latter case one can also specify a -range of revisions explicitly. - -In addition, some Git commands (such as linkgit:git-show[1]) also take -revision parameters which denote other objects than commits, e.g. blobs -("files") or trees ("directories of files"). +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[] diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt new file mode 100644 index 0000000000..f9f4e65c9e --- /dev/null +++ b/Documentation/gitsubmodules.txt @@ -0,0 +1,284 @@ +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 (note that 'submodule.recurse' also +affects other git commands, see linkgit:git-config[1] for a complete list). + + +SEE ALSO +-------- +linkgit:git-submodule[1], linkgit:gitmodules[5]. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt index 3109ea8aad..8bdb7d0bd3 100644 --- a/Documentation/gittutorial-2.txt +++ b/Documentation/gittutorial-2.txt @@ -368,17 +368,18 @@ situation: ------------------------------------------------ $ git status -# On branch master -# Changes to be committed: -# (use "git reset HEAD <file>..." to unstage) -# -# new file: closing.txt -# -# Changes not staged for commit: -# (use "git add <file>..." to update what will be committed) -# -# modified: file.txt -# +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, @@ -403,7 +404,7 @@ 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 link:everyday.html[Everyday Git]. You +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 @@ -427,9 +428,9 @@ linkgit:gitcvs-migration[7], linkgit:gitcore-tutorial[7], linkgit:gitglossary[7], linkgit:git-help[1], -link:everyday.html[Everyday Git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT --- -Part of the linkgit:git[1] suite. +Part of the linkgit:git[1] suite diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 8262196318..59ef5cef1f 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -3,7 +3,7 @@ gittutorial(7) NAME ---- -gittutorial - A tutorial introduction to Git (for version 1.5.1 or newer) +gittutorial - A tutorial introduction to Git SYNOPSIS -------- @@ -107,14 +107,15 @@ summary of the situation with 'git status': ------------------------------------------------ $ git status -# On branch master -# Changes to be committed: -# (use "git reset HEAD <file>..." to unstage) -# -# modified: file1 -# modified: file2 -# modified: file3 -# +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 @@ -206,7 +207,7 @@ automatically. The asterisk marks the branch you are currently on; type ------------------------------------------------ -$ git checkout experimental +$ git switch experimental ------------------------------------------------ to switch to the experimental branch. Now edit a file, commit the @@ -215,7 +216,7 @@ change, and switch back to the master branch: ------------------------------------------------ (edit file) $ git commit -a -$ git checkout master +$ git switch master ------------------------------------------------ Check that the change you made is no longer visible, since it was @@ -450,7 +451,7 @@ 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 rsync or http; +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 @@ -656,7 +657,7 @@ digressions that may be interesting at this point are: * linkgit:gitworkflows[7]: Gives an overview of recommended workflows. - * link:everyday.html[Everyday Git with 20 Commands Or So] + * linkgit:giteveryday[7]: Everyday Git with 20 Commands Or So. * linkgit:gitcvs-migration[7]: Git for CVS users. @@ -668,9 +669,9 @@ linkgit:gitcore-tutorial[7], linkgit:gitglossary[7], linkgit:git-help[1], linkgit:gitworkflows[7], -link:everyday.html[Everyday Git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT --- -Part of the linkgit:git[1] suite. +Part of the linkgit:git[1] suite diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt index 305db633cc..7963a79ba9 100644 --- a/Documentation/gitweb.conf.txt +++ b/Documentation/gitweb.conf.txt @@ -19,10 +19,12 @@ 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'; +------------------------------------------------ +# 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 @@ -48,11 +50,11 @@ following order: * built-in values (some set during build stage), * common system-wide configuration file (defaults to - '/etc/gitweb-common.conf'), + `/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'). + 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. @@ -80,7 +82,7 @@ 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 +`/etc/gitweb-gitolite.conf`. To include it, put -------------------------------------------------- read_config_file("/etc/gitweb-gitolite.conf"); @@ -140,7 +142,7 @@ 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. +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 @@ -205,8 +207,8 @@ subsection on linkgit:gitweb[1] manpage. $strict_export:: Only allow viewing of repositories also shown on the overview page. - This for example makes `$gitweb_export_ok` file decide if repository is - available and not only if it is shown. If `$gitweb_list` points to + 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 @@ -232,9 +234,9 @@ $GIT:: $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 + 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 + 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. @@ -246,13 +248,20 @@ $highlight_bin:: Note that 'highlight' feature must be set for gitweb to actually use syntax highlighting. + -*NOTE*: if you want to add support for new file type (supported by -"highlight" but not used by gitweb), you need to modify `%highlight_ext` -or `%highlight_basename`, depending on whether you detect type of file -based on extension (for example "sh") or on its basename (for example -"Makefile"). The keys of these hashes are extension and basename, -respectively, and value for given key is name of syntax to be passed via -`--syntax <syntax>` to highlighter. +*NOTE*: for a file to be highlighted, its syntax type must be detected +and that syntax must be supported by "highlight". The default syntax +detection is minimal, and there are many supported syntax types with no +detection by default. There are three options for adding syntax +detection. The first and second priority are `%highlight_basename` and +`%highlight_ext`, which detect based on basename (the full filename, for +example "Makefile") and extension (for example "sh"). The keys of these +hashes are the basename and extension, respectively, and the value for a +given key is the name of the syntax to be passed via `--syntax <syntax>` +to "highlight". The last priority is the "highlight" configuration of +`Shebang` regular expressions to detect the language based on the first +line in the file, (for example, matching the line "#!/bin/bash"). See +the highlight documentation and the default config at +/etc/highlight/filetypes.conf for more details. + For example if repositories you are hosting use "phtml" extension for PHP files, and you want to have correct syntax-highlighting for those @@ -288,8 +297,8 @@ 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, +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 @@ -302,7 +311,7 @@ $logo:: 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'. + By default set to `static/git-logo.png`. $favicon:: Points to the location where you put 'git-favicon.png' on your web @@ -311,7 +320,7 @@ $favicon:: 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'. + By default set to `static/git-favicon.png`. $javascript:: Points to the location where you put 'gitweb.js' on your web server, @@ -319,7 +328,7 @@ $javascript:: 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 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". @@ -350,6 +359,7 @@ $home_link_str:: + 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/' ], @@ -361,8 +371,8 @@ $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, http://git-scm.com[]; in the past, they pointed - to Git documentation at http://www.kernel.org[]. + 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 @@ -376,7 +386,7 @@ $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", + `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). + @@ -434,7 +444,7 @@ $default_blob_plain_mimetype:: 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 + and `/etc/mime.types` files (see *mime.types*(5) manpage; only filename extension rules are supported by gitweb). $default_text_plain_charset:: @@ -476,18 +486,18 @@ affects how "summary" pages look like, or load limiting). (for example one for `git://` protocol, and one for `http://` protocol). + -Note that per repository configuration can be set in '$GIT_DIR/cloneurl' +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` built-time configuration variable. +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 enables the grouping of projects by category on the project + 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). @@ -510,7 +520,7 @@ $maxload:: 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 + 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. + @@ -526,7 +536,7 @@ $omit_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. + 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 + @@ -630,13 +640,13 @@ need to set this element to empty list i.e. `[]`. override:: If this field has a true value then the given feature is - overriddable, which means that it can be configured + overridable, which means that it can be configured (or enabled/disabled) on a per-repository basis. + Usually given "<feature>" is configurable via the `gitweb.<feature>` config variable in the per-repository Git configuration file. + -*Note* that no feature is overriddable by default. +*Note* that no feature is overridable by default. sub:: Internal detail of implementation. What is important is that @@ -674,7 +684,7 @@ 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.blame` configuration variable, which contains +repository's `gitweb.snapshot` configuration variable, which contains a comma separated list of formats or "none" to disable snapshots. Unknown values are ignored. @@ -706,7 +716,7 @@ show-sizes:: I/O. Enabled by default. + This feature can be configured on a per-repository basis via -repository's `gitweb.showsizes` configuration variable (boolean). +repository's `gitweb.showSizes` configuration variable (boolean). patches:: Enable and configure "patches" view, which displays list of commits in email @@ -729,7 +739,7 @@ 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. +installed; see `gitweb/INSTALL` for more details. + This feature can be configured on a per-repository basis via repository's `gitweb.avatar` configuration variable. @@ -776,9 +786,9 @@ forks:: 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 + 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 @@ -822,18 +832,18 @@ timed:: Project specific override is not supported. javascript-timezone:: - Enable and configure the ability to change a common timezone for dates + 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 timezone (for if the client -hasn't selected some other timezone and saved it in a cookie), a name of cookie -where to store selected timezone, and a CSS class used to mark up +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) timezone, +Typical gitweb config files will only change starting (default) time zone, and leave other elements at their default values: + --------------------------------------------------------------------------- @@ -843,12 +853,49 @@ $feature{'javascript-timezone'}{'default'}[0] = "utc"; The example configuration presented here is guaranteed to be backwards and forward compatible. + -Timezone values can be "local" (for local timezone that browser uses), "utc" +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 -timezones in the form of "+/-HHMM", such as "+0200". +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 -------- @@ -857,17 +904,19 @@ 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{'blame'}{'default'} = [1]; +$feature{'blame'}{'override'} = 1; - $feature{'pickaxe'}{'default'} = [1]; - $feature{'pickaxe'}{'override'} = 1; +$feature{'pickaxe'}{'default'} = [1]; +$feature{'pickaxe'}{'override'} = 1; - $feature{'snapshot'}{'default'} = ['zip', 'tgz']; - $feature{'snapshot'}{'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 +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: diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt index cca14b8cc3..3cc9b034c4 100644 --- a/Documentation/gitweb.txt +++ b/Documentation/gitweb.txt @@ -28,15 +28,14 @@ Gitweb provides a web interface to Git repositories. Its features include: revisions one at a time, viewing the history of the repository. * Finding commits which commit messages matches given search term. -See http://git.kernel.org/?p=git/git.git;a=tree;f=gitweb[] or -http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code, +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] +file `gitweb_config.perl` or `/etc/gitweb.conf`. See the linkgit:gitweb.conf[5] for details. Repositories @@ -51,7 +50,7 @@ projects' root" subsection). our $projectroot = '/path/to/parent/directory'; ----------------------------------------------------------------------- -The default value for `$projectroot` is '/pub/git'. You can change it during +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 @@ -84,7 +83,7 @@ separator (rules for Perl's "`split(" ", $line)`"). * Fields use modified URI encoding, defined in RFC 3986, section 2.1 (Percent-Encoding), or rather "Query string encoding" (see -link:http://en.wikipedia.org/wiki/Query_string#URL_encoding[]), the difference +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). + @@ -206,8 +205,8 @@ $export_auth_hook = sub { 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]). +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: @@ -231,7 +230,7 @@ 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 +`/usr/share/git-core/templates/`. You can use the `gitweb.description` repo configuration variable, but the file takes precedence. category (or `gitweb.category`):: @@ -407,7 +406,7 @@ 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' +which gitweb is installed. Let's assume that it is `/var/www/cgi-bin` directory. ----------------------------------------------------------------------- @@ -431,7 +430,7 @@ 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 +Assuming that gitweb is installed to `/var/www/perl`, the following Apache configuration (for mod_perl 2.x) is suitable. ----------------------------------------------------------------------- @@ -456,7 +455,7 @@ 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 +installed in `/usr/share/gitweb` directory. The following Apache configuration is suitable (UNTESTED!) ----------------------------------------------------------------------- @@ -503,22 +502,22 @@ repositories, you can configure Apache like this: ----------------------------------------------------------------------- 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`, +`/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 +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 +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): +(`/etc/gitweb.conf` following example): ---------------------------------------------------------------------------- @stylesheets = ("/some/absolute/path/gitweb.css"); $my_uri = "/"; @@ -575,7 +574,7 @@ like this: 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): +line in gitweb configuration file (`/etc/gitweb.conf` in above example): -------------------------------------------------------------------------- $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git"; -------------------------------------------------------------------------- @@ -585,7 +584,7 @@ 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: +`~/public_git/` with the following url: http://git.example.org/~<user>/ @@ -596,7 +595,7 @@ 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 +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. @@ -614,7 +613,7 @@ 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 +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): @@ -645,9 +644,9 @@ parameter. `@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: +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 @@ -681,7 +680,7 @@ cloned), while 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 +a named ref (branch, tag) starting with `git/`, then paths such as http://git.example.com/project/command/abranch..git/abranch @@ -697,7 +696,7 @@ SEE ALSO -------- linkgit:gitweb.conf[5], linkgit:git-instaweb[1] -'gitweb/README', 'gitweb/INSTALL' +`gitweb/README`, `gitweb/INSTALL` GIT --- diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt index f16c414ea7..47cf97f9be 100644 --- a/Documentation/gitworkflows.txt +++ b/Documentation/gitworkflows.txt @@ -40,7 +40,7 @@ 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 save --keep-index` to run the +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]. @@ -85,15 +85,15 @@ As a given feature goes from experimental to stable, it also 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). +* 'seen' (patches seen by the maintainer) 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 +or 'seen'), and "graduates" to 'master' for the next release once it is considered stable enough. @@ -107,7 +107,7 @@ the unstable branch into the stable one. Hence the following: .Merge upwards [caption="Rule: "] ===================================== -Always commit your fixes to the oldest supported branch that require +Always commit your fixes to the oldest supported branch that requires them. Then (periodically) merge the integration branches upwards into each other. ===================================== @@ -207,7 +207,7 @@ 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'. +has such an official throw-away integration branch called 'seen'. Branch management for a release @@ -291,8 +291,8 @@ 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Branch management for next and seen 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 @@ -301,8 +301,7 @@ topics on 'next': .Rewind and rebuild next [caption="Recipe: "] ===================================== -* `git checkout next` -* `git reset --hard master` +* `git switch -C next master` * `git merge ai/topic_in_next1` * `git merge ai/topic_in_next2` * ... @@ -320,8 +319,8 @@ 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 +The same rewind and rebuild process may be followed for 'seen'. A public +announcement is not necessary since 'seen' is a throw-away branch, as described above. @@ -407,8 +406,8 @@ follows. `git pull <url> <branch>` ===================================== -Occasionally, the maintainer may get merge conflicts when he tries to -pull changes from downstream. In this case, he can ask downstream to +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. @@ -477,4 +476,4 @@ linkgit:git-am[1] GIT --- -Part of the linkgit:git[1] suite. +Part of the linkgit:git[1] suite diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index e4706615be..090c888335 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -1,7 +1,7 @@ [[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 "alternate". + from another object database, which is called an "alternate". [[def_bare_repository]]bare repository:: A bare repository is normally an appropriately @@ -145,7 +145,7 @@ current branch integrates with) obviously do not work, as there is no 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 these cases, you do not make a new <<def_merge,merge>> + 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 @@ -176,6 +176,10 @@ current branch integrates with) obviously do not work, as there is no you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has is different from what was recorded when the commit was created. Configured via the `.git/info/grafts` file. ++ +Note that the grafts mechanism is outdated and can lead to problems +transferring objects between repositories; see linkgit:git-replace[1] +for a more flexible and robust system to do the same thing. [[def_hash]]hash:: In Git's context, synonym for <<def_object_name,object name>>. @@ -251,7 +255,7 @@ This commit is referred to as a "merge commit", or sometimes just a [[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 can not be changed. + object cannot be changed. [[def_object_database]]object database:: Stores a set of "objects", and an individual <<def_object,object>> is @@ -283,6 +287,15 @@ This commit is referred to as a "merge commit", or sometimes just a 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). @@ -323,24 +336,26 @@ including Documentation/chapter_1/figure_1.jpg. A pathspec that begins with a colon `:` has special meaning. In the short form, the leading colon `:` is followed by zero or more "magic signature" letters (which optionally is terminated by another colon `:`), -and the remainder is the pattern to match against the path. The optional -colon that terminates the "magic signature" can be omitted if the pattern -begins with a character that cannot be a "magic signature" and is not a -colon. +and the remainder is the pattern to match against the path. +The "magic signature" consists of ASCII symbols that are neither +alphanumeric, glob, regex special 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 a open +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. + -The "magic signature" consists of an ASCII symbol that is not -alphanumeric. +A pathspec with only a colon means "there is no pathspec". This form +should not be combined with other pathspec. + -- -top `/`;; - The magic word `top` (mnemonic: `/`) makes the pattern match - from the root of the working tree, even when you are running - the command from inside a subdirectory. +top;; + The magic word `top` (magic signature: `/`) makes the pattern + match from the root of the working tree, even when you are + running the command from inside a subdirectory. literal;; Wildcards in the pattern such as `*` or `?` are treated @@ -362,12 +377,12 @@ 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" + "`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 + - 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 @@ -377,14 +392,37 @@ full pathname may have special meaning: - 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]. + -Currently only the slash `/` is recognized as the "magic signature", -but it is envisioned that we will support more types of magic in later -versions of Git. +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. + -A pathspec with only a colon means "there is no pathspec". This form -should not be combined with other pathspec. +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 @@ -407,6 +445,28 @@ should not be combined with other pathspec. 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]. @@ -414,7 +474,7 @@ should not be combined with other pathspec. [[def_push]]push:: Pushing a <<def_branch,branch>> means to get the branch's <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, - find out if it is a direct ancestor to the branch's local + find out if it is an ancestor to the branch's local head ref, and in that case, putting all objects, which are <<def_reachable,reachable>> from the local head ref, and which are missing from the remote @@ -465,6 +525,11 @@ The most notable example is `HEAD`. <<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 @@ -500,6 +565,11 @@ The most notable example is `HEAD`. "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 @@ -511,6 +581,21 @@ The most notable example is `HEAD`. 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 diff --git a/Documentation/howto-index.sh b/Documentation/howto-index.sh index a2340864b5..167b363668 100755 --- a/Documentation/howto-index.sh +++ b/Documentation/howto-index.sh @@ -11,8 +11,8 @@ EOF for txt do - title=`expr "$txt" : '.*/\(.*\)\.txt$'` - from=`sed -ne ' + title=$(expr "$txt" : '.*/\(.*\)\.txt$') + from=$(sed -ne ' /^$/q /^From:[ ]/{ s/// @@ -21,9 +21,9 @@ do s/^/by / p } - ' "$txt"` + ' "$txt") - abstract=`sed -ne ' + abstract=$(sed -ne ' /^Abstract:[ ]/{ s/^[^ ]*// x @@ -39,11 +39,11 @@ do x p q - }' "$txt"` + }' "$txt") if grep 'Content-type: text/asciidoc' >/dev/null $txt then - file=`expr "$txt" : '\(.*\)\.txt$'`.html + file=$(expr "$txt" : '\(.*\)\.txt$').html else file="$txt" fi diff --git a/Documentation/howto/keep-canonical-history-correct.txt b/Documentation/howto/keep-canonical-history-correct.txt new file mode 100644 index 0000000000..35d48ef714 --- /dev/null +++ b/Documentation/howto/keep-canonical-history-correct.txt @@ -0,0 +1,216 @@ +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/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index 33ae69c11f..a67130debb 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -39,26 +39,26 @@ The policy on Integration is informally mentioned in "A Note from the maintainer" message, which is periodically posted to this mailing list after each feature release is made. - - Feature releases are numbered as vX.Y.Z and are meant to + - Feature releases are numbered as vX.Y.0 and are meant to contain bugfixes and enhancements in any area, including functionality, performance and usability, without regression. - One release cycle for a feature release is expected to last for eight to ten weeks. - - Maintenance releases are numbered as vX.Y.Z.W and are meant - to contain only bugfixes for the corresponding vX.Y.Z feature - release and earlier maintenance releases vX.Y.Z.V (V < W). + - Maintenance releases are numbered as vX.Y.Z and are meant + to contain only bugfixes for the corresponding vX.Y.0 feature + release and earlier maintenance releases vX.Y.W (W < Z). - 'master' branch is used to prepare for the next feature release. In other words, at some point, the tip of 'master' - branch is tagged with vX.Y.Z. + branch is tagged with vX.Y.0. - 'maint' branch is used to prepare for the next maintenance - release. After the feature release vX.Y.Z is made, the tip + release. After the feature release vX.Y.0 is made, the tip of 'maint' branch is set to that release, and bugfixes will accumulate on the branch, and at some point, the tip of the - branch is tagged with vX.Y.Z.1, vX.Y.Z.2, and so on. + branch is tagged with vX.Y.1, vX.Y.2, and so on. - 'next' branch is used to publish changes (both enhancements and fixes) that (1) have worthwhile goal, (2) are in a fairly @@ -66,7 +66,7 @@ this mailing list after each feature release is made. 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 + - 'seen' 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 @@ -76,7 +76,7 @@ this mailing list after each feature release is made. of the cycle. - Usually 'master' contains all of 'maint' and 'next' contains all - of 'master'. 'pu' contains all the topics merged to 'next', but + of 'master'. 'seen' 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 @@ -86,6 +86,10 @@ this mailing list after each feature release is made. users are encouraged to test it so that regressions and bugs are found before new topics are merged to 'master'. +Note that before v1.9.0 release, the version numbers used to be +structured slightly differently. vX.Y.Z were feature releases while +vX.Y.Z.W were maintenance releases for vX.Y.Z. + A Typical Git Day ----------------- @@ -150,15 +154,17 @@ by doing the following: - 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 + is forked from the tip of 'master' (or the last feature release, + which is a bit older than '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. + topic branch that is forked from the tip of 'maint' (or the + oldest and still relevant maintenance branch). The + topic may be named as ai/maint-topic. - Changes that pertain to an existing topic are applied to the branch, but: @@ -170,24 +176,40 @@ by doing the following: - Replacement patches to an existing topic are accepted only for commits not in 'next'. - The above except the "replacement" are all done with: + The initial round is done with: $ git checkout ai/topic ;# or "git checkout -b ai/topic master" $ git am -sc3 mailbox - while patch replacement is often done by: + and replacing an existing topic with subsequent round is done with: + + $ git checkout master...ai/topic ;# try to reapply to the same base + $ git am -sc3 mailbox + + to prepare the new round on a detached HEAD, and then - $ git format-patch ai/topic~$n..ai/topic ;# export existing + $ git range-diff @{-1}... + $ git diff @{-1} - then replace some parts with the new patch, and reapplying: + to double check what changed since the last round, and finally - $ git checkout ai/topic - $ git reset --hard ai/topic~$n - $ git am -sc3 -s 000*.txt + $ git checkout -B @{-1} + + to conclude (the last step is why a topic already in 'next' is + not replaced but updated incrementally). + + Whether it is the initial round or a subsequent round, the topic + may not build even in isolation, or may break the build when + merged to integration branches due to bugs. There may already + be obvious and trivial improvements suggested on the list. The + maintainer often adds an extra commit, with "SQUASH???" in its + title, to fix things up, before publishing the integration + branches to make it usable by other developers for testing. + These changes are what the maintainer is not 100% committed to + (trivial typofixes etc. are often squashed directly into the + patches that need fixing, without being applied as a separate + "SQUASH???" commit), so that they can be removed easily as needed. - 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: @@ -207,12 +229,12 @@ by doing the following: series?) - Prepare 'jch' branch, which is used to represent somewhere - between 'master' and 'pu' and often is slightly ahead of 'next'. + between 'master' and 'seen' and often is slightly ahead of 'next'. - $ Meta/Reintegrate master..pu >Meta/redo-jch.sh + $ Meta/Reintegrate master..seen >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 + rebuild 'seen' 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. @@ -269,29 +291,29 @@ by doing the following: merged to 'master'. This may lose '### match next' marker; add it again to the appropriate place when it happens. - - Rebuild 'pu'. + - Rebuild 'seen'. - $ Meta/Reintegrate master..pu >Meta/redo-pu.sh + $ Meta/Reintegrate master..seen >Meta/redo-seen.sh - Edit the result by adding new topics that are not still in 'pu' + Edit the result by adding new topics that are not still in 'seen' in the script. Then - $ git checkout -B pu jch - $ sh Meta/redo-pu.sh + $ git checkout -B seen jch + $ sh Meta/redo-seen.sh - When all is well, clean up the redo-pu.sh script with + When all is well, clean up the redo-seen.sh script with - $ sh Meta/redo-pu.sh -u + $ sh Meta/redo-seen.sh -u Double check by running - $ git branch --no-merged pu + $ git branch --no-merged seen 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 + appendix), and rebuild the 'seen' branch from scratch, starting at the tip of 'jch'. - Update "What's cooking" message to review the updates to @@ -301,14 +323,14 @@ by doing the following: $ Meta/cook - This script inspects the history between master..pu, finds tips + This script inspects the history between master..seen, 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 + Topics not listed in the file but are found in master..seen 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 + are no longer found in master..seen 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 + (e.g. used to be only in 'seen', now merged to 'next') are updated with change markers "<<" and ">>". Look for lines enclosed in "<<" and ">>"; they hold contents from @@ -338,7 +360,7 @@ 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'. + topics cooking first in 'seen', 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 @@ -367,6 +389,14 @@ Some observations to be made. be included in the next feature release. Being in the 'master' branch typically is. + * Due to the nature of "SQUASH???" fix-ups, if the original author + agrees with the suggested changes, it is OK to squash them to + appropriate patches in the next round (when the suggested change + is small enough, the author should not even bother with + "Helped-by"). It is also OK to drop them from the next round + when the original author does not agree with the suggestion, but + the author is expected to say why somewhere in the discussion. + Appendix -------- @@ -381,7 +411,7 @@ 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 +The Meta/Reintegrate script that is used by redo-jch and redo-seen 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 @@ -401,14 +431,14 @@ 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 +integration branch had such a semantic conflict, say seen~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 checkout seen~4 $ git show -s --pretty=%s ;# double check - Merge branch 'ai/topic' to pu + Merge branch 'ai/topic' to seen $ edit $ git commit -m 'merge-fix/ai/topic' -a @@ -420,9 +450,9 @@ result: Then double check the result by asking Meta/Reintegrate to redo the merge: - $ git checkout pu~5 ;# the parent of the problem merge + $ git checkout seen~5 ;# the parent of the problem merge $ echo ai/topic | Meta/Reintegrate - $ git diff pu~4 + $ git diff seen~4 This time, because you prepared refs/merge-fix/ai/topic, the resulting merge should have been tweaked to include the fix for the @@ -434,7 +464,7 @@ 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 +existing use sites), and if you changed redo-jch (or redo-seen) 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 diff --git a/Documentation/howto/new-command.txt b/Documentation/howto/new-command.txt index d7de5a3e9e..15a4c8031f 100644 --- a/Documentation/howto/new-command.txt +++ b/Documentation/howto/new-command.txt @@ -94,8 +94,10 @@ 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 git-commands.txt -in the main directory. +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 diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt index 19ab604f1f..f2e10a7ec8 100644 --- a/Documentation/howto/rebase-from-internal-branch.txt +++ b/Documentation/howto/rebase-from-internal-branch.txt @@ -4,7 +4,7 @@ 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 + public "seen" 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. @@ -20,8 +20,8 @@ Petr Baudis <pasky@suse.cz> writes: > 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. +>> > Junio, maybe you want to talk about how you move patches from your +>> > "seen" branch to the real branches. >> > Actually, wouldn't this be also precisely for what StGIT is intended to? -------------------------------------- @@ -33,12 +33,12 @@ 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 +I had a handful of commits that were ahead of master in 'seen', and I wanted to add some documentation bypassing my usual habit of -placing new things in pu first. At the beginning, the commit +placing new things in 'seen' first. At the beginning, the commit ancestry graph looked like this: - *"pu" head + *"seen" head master --> #1 --> #2 --> #3 So I started from master, made a bunch of edits, and committed: @@ -50,7 +50,7 @@ So I started from master, made a bunch of edits, and committed: After the commit, the ancestry graph would look like this: - *"pu" head + *"seen" head master^ --> #1 --> #2 --> #3 \ \---> master @@ -58,31 +58,31 @@ After the commit, the ancestry graph would look like this: 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. +Now I have to deal with "seen" 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" +at "master" branch being the "maintainer" branch, and "seen" 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 +"seen". You _could_ merge master to 'seen' 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": +your changes) "seen" rather than merge. So I ran "git rebase": - $ git checkout pu - $ git rebase master pu + $ git checkout seen + $ git rebase master seen What this does is to pick all the commits since the current -branch (note that I now am on "pu" branch) forked from the +branch (note that I now am on "seen" branch) forked from the master branch, and forward port these changes. master^ --> #1 --> #2 --> #3 - \ *"pu" head + \ *"seen" head \---> master --> #1' --> #2' --> #3' The diff between master^ and #1 is applied to master and @@ -92,7 +92,7 @@ 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 +you ran fsck-cache, which is normal. After testing "seen", 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 @@ -139,7 +139,7 @@ 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 nor .git/refs/heads/master. +does not touch your .git/HEAD or .git/refs/heads/master. You run "git rebase" now. $ git rebase FETCH_HEAD master diff --git a/Documentation/howto/rebuild-from-update-hook.txt b/Documentation/howto/rebuild-from-update-hook.txt index 25378f68d3..db219f5c07 100644 --- a/Documentation/howto/rebuild-from-update-hook.txt +++ b/Documentation/howto/rebuild-from-update-hook.txt @@ -4,13 +4,13 @@ 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 http://www.kernel.org/pub/software/scm/git/docs/. + shown at https://www.kernel.org/pub/software/scm/git/docs/. Content-type: text/asciidoc How to rebuild from update hook =============================== -The pages under http://www.kernel.org/pub/software/scm/git/docs/ +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 diff --git a/Documentation/howto/recover-corrupted-object-harder.txt b/Documentation/howto/recover-corrupted-object-harder.txt new file mode 100644 index 0000000000..8994e2559e --- /dev/null +++ b/Documentation/howto/recover-corrupted-object-harder.txt @@ -0,0 +1,479 @@ +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/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt index acf3e477e5..19f59cc888 100644 --- a/Documentation/howto/revert-a-faulty-merge.txt +++ b/Documentation/howto/revert-a-faulty-merge.txt @@ -30,7 +30,7 @@ The history immediately after the "revert of the merge" would look like this: ---o---o---o---M---x---x---W - / + / ---A---B where A and B are on the side development that was not so good, M is the @@ -47,14 +47,14 @@ 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 nor B will be in the result, because they were reverted +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: @@ -81,7 +81,7 @@ In such a situation, you would want to first revert the previous revert, which would make the history look like this: ---o---o---o---M---x---x---W---x---Y - / + / ---A---B-------------------C---D where Y is the revert of W. Such a "revert of the revert" can be done @@ -90,17 +90,17 @@ with: $ git revert W This history would (ignoring possible conflicts between what W and W..Y -changed) be equivalent to not having W nor Y at all in the history: +changed) be equivalent to not having W or Y at all in the history: ---o---o---o---M---x---x-------x---- - / + / ---A---B-------------------C---D and merging the side branch again will not have conflict arising from an earlier revert and revert of the revert. ---o---o---o---M---x---x-------x-------* - / / + / / ---A---B-------------------C---D Of course the changes made in C and D still can conflict with what was @@ -111,13 +111,13 @@ faulty A and B, and redone the changes on top of the updated mainline after the revert, the history would have looked like this: ---o---o---o---M---x---x---W---x---x - / \ + / \ ---A---B A'--B'--C' If you reverted the revert in such a case as in the previous example: ---o---o---o---M---x---x---W---x---x---Y---* - / \ / + / \ / ---A---B A'--B'--C' where Y is the revert of W, A' and B' are rerolled A and B, and there may @@ -129,7 +129,7 @@ lot of overlapping changes that result in conflicts. So do not do "revert of revert" blindly without thinking.. ---o---o---o---M---x---x---W---x---x - / \ + / \ ---A---B A'--B'--C' In the history with rebased side branch, W (and M) are behind the merge diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt index 85f69dbac9..a3e5595a56 100644 --- a/Documentation/howto/revert-branch-rebase.txt +++ b/Documentation/howto/revert-branch-rebase.txt @@ -15,7 +15,7 @@ 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 +branch and to adjust the 'seen' branch, using core Git tools and barebone Porcelain. First, prepare a throw-away branch in case I screw things up. @@ -104,11 +104,11 @@ $ git diff master..revert-c99 says nothing. -Then we rebase the 'pu' branch as usual. +Then we rebase the 'seen' branch as usual. ------------------------------------------------ -$ git checkout pu -$ git tag pu-anchor pu +$ git checkout seen +$ git tag seen-anchor seen $ git rebase master * Applying: Redo "revert" using three-way merge machinery. First trying simple merge strategy to cherry-pick. @@ -127,20 +127,20 @@ First trying simple merge strategy to cherry-pick. First trying simple merge strategy to cherry-pick. ------------------------------------------------ -The temporary tag 'pu-anchor' is me just being careful, in case 'git +The temporary tag 'seen-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. +$ git diff seen-anchor..seen ;# 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 -nor tag anymore, so remove them: +or tag anymore, so remove them: ------------------------------------------------ -$ rm -f .git/refs/tags/pu-anchor +$ rm -f .git/refs/tags/seen-anchor $ git branch -d revert-c99 ------------------------------------------------ @@ -168,18 +168,18 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f And the final repository status looks like this: ------------------------------------------------ -$ git show-branch --more=1 master pu rc +$ git show-branch --more=1 master seen rc ! [master] Revert "Replace zero-length array decls with []." - ! [pu] git-repack: Add option to repack all objects. + ! [seen] 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. + + [seen] git-repack: Add option to repack all objects. + + [seen~1] More documentation updates. + + [seen~2] Show commits in topo order and name all commits. + + [seen~3] mailinfo and applymbox updates + + [seen~4] Document "git cherry-pick" and "git revert" + + [seen~5] Remove git-apply-patch-script. + + [seen~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 . diff --git a/Documentation/howto/separating-topic-branches.txt b/Documentation/howto/separating-topic-branches.txt index bd1027433b..81be0d6115 100644 --- a/Documentation/howto/separating-topic-branches.txt +++ b/Documentation/howto/separating-topic-branches.txt @@ -81,7 +81,7 @@ After I am done, I'd try a pretend-merge between "topicA" and 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: +for cruft. Then I can finally clean things up: $ git branch -D topic $ git reset --hard HEAD^ ;# nuke pretend merge diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt index 981cbddc86..bfe6f9b500 100644 --- a/Documentation/howto/setup-git-server-over-http.txt +++ b/Documentation/howto/setup-git-server-over-http.txt @@ -6,6 +6,10 @@ 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 @@ -177,7 +181,7 @@ On Debian: Most tests should pass. -A command line tool to test WebDAV is cadaver. If you prefer GUIs, for +A command-line tool to test WebDAV is cadaver. If you prefer GUIs, for example, konqueror can open WebDAV URLs as "webdav://..." or "webdavs://...". @@ -240,8 +244,8 @@ 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 +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. diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt index a5193b1e5c..151ee84ceb 100644 --- a/Documentation/howto/update-hook-example.txt +++ b/Documentation/howto/update-hook-example.txt @@ -80,7 +80,7 @@ case "$1" in info "The branch '$1' is new..." else # updating -- make sure it is a fast-forward - mb=$(git-merge-base "$2" "$3") + 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.";; @@ -179,7 +179,7 @@ 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/seen junio refs/heads/cogito$ pasky refs/heads/bw/.* linus refs/heads/tmp/.* .* @@ -187,6 +187,6 @@ whom. The format of each file would look like this: 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 +do master and "seen" branches and make versioned tags. And anybody +can do tmp/blah branches. The '+' sign at the "seen" record means that JC can make non-fast-forward pushes on it. diff --git a/Documentation/howto/using-merge-subtree.txt b/Documentation/howto/using-merge-subtree.txt index 1ae8d1214e..a499a94ac2 100644 --- a/Documentation/howto/using-merge-subtree.txt +++ b/Documentation/howto/using-merge-subtree.txt @@ -33,7 +33,7 @@ Here is the command sequence you need: ---------------- $ git remote add -f Bproject /path/to/B <1> -$ git merge -s ours --no-commit Bproject/master <2> +$ 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> diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt index e9a1d5d25a..7e36e5b55b 100644 --- a/Documentation/i18n.txt +++ b/Documentation/i18n.txt @@ -1,18 +1,31 @@ -At the core level, Git is character encoding agnostic. - - - The pathnames recorded in the index and in the tree objects - are treated as uninterpreted sequences of non-NUL bytes. - What readdir(2) returns are what are recorded and compared - with the data Git keeps track of, which in turn are expected - to be what lstat(2) and creat(2) accepts. There is no such - thing as pathname encoding translation. +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. - - The commit log messages are uninterpreted sequences of non-NUL - bytes. + - 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 @@ -29,11 +42,11 @@ mind. + ------------ [i18n] - commitencoding = ISO-8859-1 + commitEncoding = ISO-8859-1 ------------ + Commit objects created with the above setting record the value -of `i18n.commitencoding` in its `encoding` header. This is to +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. @@ -41,15 +54,15 @@ implies that the commit log message is encoded in UTF-8. `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` in `.git/config` file, like this: + ------------ [i18n] - logoutputencoding = ISO-8859-1 + logOutputEncoding = ISO-8859-1 ------------ + If you do not have this configuration variable, the value of -`i18n.commitencoding` is used instead. +`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 diff --git a/Documentation/install-doc-quick.sh b/Documentation/install-doc-quick.sh index 327f69bcf5..17231d8e59 100755 --- a/Documentation/install-doc-quick.sh +++ b/Documentation/install-doc-quick.sh @@ -3,11 +3,12 @@ repository=${1?repository} destdir=${2?destination} +GIT_MAN_REF=${3?master} -head=master GIT_DIR= +GIT_DIR= for d in "$repository/.git" "$repository" do - if GIT_DIR="$d" git rev-parse refs/heads/master >/dev/null 2>&1 + if GIT_DIR="$d" git rev-parse "$GIT_MAN_REF" >/dev/null 2>&1 then GIT_DIR="$d" export GIT_DIR @@ -27,12 +28,12 @@ export GIT_INDEX_FILE GIT_WORK_TREE rm -f "$GIT_INDEX_FILE" trap 'rm -f "$GIT_INDEX_FILE"' 0 -git read-tree $head +git read-tree "$GIT_MAN_REF" git checkout-index -a -f --prefix="$destdir"/ if test -n "$GZ" then - git ls-tree -r --name-only $head | + git ls-tree -r --name-only "$GIT_MAN_REF" | xargs printf "$destdir/%s\n" | xargs gzip -f fi diff --git a/Documentation/install-webdoc.sh b/Documentation/install-webdoc.sh index 76d69a907b..ed8b4ff3e5 100755 --- a/Documentation/install-webdoc.sh +++ b/Documentation/install-webdoc.sh @@ -18,17 +18,17 @@ do else echo >&2 "# install $h $T/$h" rm -f "$T/$h" - mkdir -p `dirname "$T/$h"` + mkdir -p $(dirname "$T/$h") cp "$h" "$T/$h" fi done -strip_leading=`echo "$T/" | sed -e 's|.|.|g'` +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"'\(.*\)'` + h=$(expr "$th" : "$strip_leading"'\(.*\)') case "$h" in RelNotes-*.txt | index.html) continue ;; esac diff --git a/Documentation/line-range-format.txt b/Documentation/line-range-format.txt index d7f26039ca..829676ff98 100644 --- a/Documentation/line-range-format.txt +++ b/Documentation/line-range-format.txt @@ -22,8 +22,9 @@ This is only valid for <end> and will specify a number of lines before or after the line given by <start>. + -If ``:<regex>'' is given in place of <start> and <end>, it denotes the range -from the first funcname line that matches <regex>, up to the next -funcname line. ``:<regex>'' searches from the end of the previous `-L` range, -if any, otherwise from the start of file. -``^:<regex>'' searches from the start of file. +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/Documentation/lint-gitlink.perl b/Documentation/lint-gitlink.perl new file mode 100755 index 0000000000..476cc30b83 --- /dev/null +++ b/Documentation/lint-gitlink.perl @@ -0,0 +1,71 @@ +#!/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/Documentation/manpage-1.72.xsl b/Documentation/manpage-1.72.xsl deleted file mode 100644 index b4d315cb8c..0000000000 --- a/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/Documentation/manpage-base.xsl b/Documentation/manpage-base.xsl deleted file mode 100644 index a264fa6160..0000000000 --- a/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/Documentation/manpage-bold-literal.xsl b/Documentation/manpage-bold-literal.xsl index 608eb5df62..e13db85693 100644 --- a/Documentation/manpage-bold-literal.xsl +++ b/Documentation/manpage-bold-literal.xsl @@ -1,17 +1,16 @@ <!-- manpage-bold-literal.xsl: special formatting for manpages rendered from asciidoc+docbook --> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + xmlns:d="http://docbook.org/ns/docbook" 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:template match="literal|d:literal"> + <xsl:text>\fB</xsl:text> <xsl:apply-templates/> - <xsl:value-of select="$git.docbook.backslash"/> - <xsl:text>fR</xsl:text> + <xsl:text>\fR</xsl:text> </xsl:template> </xsl:stylesheet> diff --git a/Documentation/manpage-normal.xsl b/Documentation/manpage-normal.xsl index a48f5b11f3..a9c7ec69f4 100644 --- a/Documentation/manpage-normal.xsl +++ b/Documentation/manpage-normal.xsl @@ -1,13 +1,26 @@ <!-- manpage-normal.xsl: - special settings for manpages rendered from asciidoc+docbook - handles anything we want to keep away from docbook-xsl 1.72.0 --> + special settings for manpages rendered from asciidoc+docbook --> <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> +<!-- 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 --> +<xsl:template match="co"> + <xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/> +</xsl:template> +<xsl:template match="calloutlist"> + <xsl:text>.sp </xsl:text> + <xsl:apply-templates/> + <xsl:text> </xsl:text> +</xsl:template> +<xsl:template match="callout"> + <xsl:value-of select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/> + <xsl:apply-templates/> + <xsl:text>.br </xsl:text> +</xsl:template> </xsl:stylesheet> diff --git a/Documentation/manpage-suppress-sp.xsl b/Documentation/manpage-suppress-sp.xsl deleted file mode 100644 index a63c7632a8..0000000000 --- a/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/Documentation/manpage.xsl b/Documentation/manpage.xsl new file mode 100644 index 0000000000..ef64bab17a --- /dev/null +++ b/Documentation/manpage.xsl @@ -0,0 +1,3 @@ +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> + <xsl:import href="http://docbook.sourceforge.net/release/xsl-ns/current/manpages/docbook.xsl" /> +</xsl:stylesheet> diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index afba8d4f3b..80d4831662 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -3,9 +3,14 @@ Perform the merge and commit the result. This option can be used to override --no-commit. + -With --no-commit perform the merge but pretend the merge -failed and do not autocommit, to give the user a chance to -inspect and further tweak the merge result before committing. +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:: @@ -14,9 +19,12 @@ inspect and further tweak the merge result before committing. 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). 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. + 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 @@ -24,20 +32,41 @@ 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. ---ff:: - When the merge resolves as a fast-forward, only update the branch - pointer, without creating a merge commit. This is the default - behavior. +--cleanup=<mode>:: + This option determines how the merge message will be cleaned up before + committing. 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:: --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. - --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. + Specifies how a merge is handled when the merged-in history is + already a descendant of the current history. `--ff` is the + default unless merging an annotated (and possibly signed) tag + that is not stored in its natural place in the `refs/tags/` + hierarchy, in which case `--no-ff` is assumed. ++ +With `--ff`, when possible resolve the merge as a fast-forward (only +update the branch pointer to match the merged branch; do not create a +merge commit). When not possible (when the merged-in history is not a +descendant of the current history), create a merge commit. ++ +With `--no-ff`, create a merge commit in all cases, even when the merge +could instead be resolved as a fast-forward. ++ +With `--ff-only`, resolve the merge as a fast-forward when possible. +When not possible, refuse to merge and exit with a non-zero status. + +-S[<keyid>]:: +--gpg-sign[=<keyid>]:: +--no-gpg-sign:: + 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. `--no-gpg-sign` + is useful to countermand both `commit.gpgSign` configuration variable, + and earlier `--gpg-sign`. --log[=<n>]:: --no-log:: @@ -48,6 +77,16 @@ set to `no` at the beginning of them. 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:: @@ -60,17 +99,22 @@ 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 or - move the `HEAD`, nor 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). + 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. + +--no-verify:: + This option bypasses the pre-merge and commit-msg hooks. + See also linkgit:githooks[5]. -s <strategy>:: --strategy=<strategy>:: @@ -87,8 +131,11 @@ option can be used to override --squash. --verify-signatures:: --no-verify-signatures:: - Verify that the commits being merged have good and trusted GPG signatures - and abort the merge in case they do not. + 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:: @@ -112,3 +159,19 @@ ifndef::git-pull[] reporting. endif::git-pull[] + +--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 the operation on a dirty worktree. However, use + with care: the final stash application after a successful + merge might result in non-trivial conflicts. + +--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/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 49a9a7d53f..2912de706b 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -1,10 +1,10 @@ MERGE STRATEGIES ---------------- -The merge mechanism ('git-merge' and 'git-pull' commands) allows the +The merge mechanism (`git merge` and `git pull` commands) allows the backend 'merge strategies' to be chosen with `-s` option. Some strategies can also take their own options, which can be passed by giving `-X<option>` -arguments to 'git-merge' and/or 'git-pull'. +arguments to `git merge` and/or `git pull`. resolve:: This can only resolve two heads (i.e. the current branch @@ -20,18 +20,19 @@ recursive:: merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without - causing mis-merges by tests done on actual merge commits + causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving - renames. This is the default merge strategy when - pulling or merging one branch. + renames, but currently cannot make use of detected + copies. This is the default merge strategy when pulling + or merging one branch. + The 'recursive' strategy can take the following options: 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. + conflict with our side are reflected in 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 @@ -39,7 +40,8 @@ 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'. + 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 @@ -57,11 +59,12 @@ diff-algorithm=[patience|minimal|histogram|myers];; 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`, and - `--ignore-space-at-eol`. + 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; @@ -81,9 +84,19 @@ 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>;; - Controls the similarity threshold used for rename detection. - See also linkgit:git-diff[1] `-M`. + Deprecated synonym for `find-renames=<n>`. subtree[=<path>];; This option is a more advanced form of 'subtree' strategy, where @@ -113,3 +126,11 @@ subtree:: match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree. + +With the strategies that use 3-way merge (including the default, 'recursive'), +if a change is made on both branches, but later reverted on one of the +branches, that change will be present in the merged result; some people find +this behavior confusing. It occurs because only the heads and the merge base +are considered when performing a merge, not the individual commits. The merge +algorithm therefore considers the reverted change as no change at all, and +substitutes the changed version instead. diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index 1d174fd0b6..84bbc7439a 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -4,7 +4,7 @@ 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, +"Merge: " and the hashes 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 @@ -20,20 +20,20 @@ built-in formats: * 'oneline' - <sha1> <title line> + <hash> <title line> + This is designed to be as compact as possible. * 'short' - commit <sha1> + commit <hash> Author: <author> <title line> * 'medium' - commit <sha1> + commit <hash> Author: <author> Date: <author date> @@ -43,7 +43,7 @@ This is designed to be as compact as possible. * 'full' - commit <sha1> + commit <hash> Author: <author> Commit: <committer> @@ -53,7 +53,7 @@ This is designed to be as compact as possible. * 'fuller' - commit <sha1> + commit <hash> Author: <author> AuthorDate: <author date> Commit: <committer> @@ -63,23 +63,43 @@ This is designed to be as compact as possible. <full commit message> +* 'reference' + + <abbrev hash> (<title line>, <short author date>) ++ +This format is used to refer to another commit in a commit message and +is the same as `--pretty='format:%C(auto)%h (%s, %ad)'`. By default, +the date is formatted with `--date=short` unless another `--date` option +is explicitly specified. As with any `format:` with format +placeholders, its output is not affected by other options like +`--decorate` and `--walk-reflogs`. + * 'email' - From <sha1> <date> + From <hash> <date> From: <author> Date: <author date> Subject: [PATCH] <title line> <full commit message> +* 'mboxrd' ++ +Like 'email', but lines in the commit message starting with "From " +(preceded by zero or more ">") are quoted with ">" so they aren't +confused as starting a new commit. + * 'raw' + The 'raw' format shows the entire commit exactly as -stored in the commit object. Notably, the SHA-1s are +stored in the commit object. Notably, the hashes are displayed in full, regardless of whether --abbrev or --no-abbrev are used, and 'parents' information show the -true parent commits, without taking grafts nor history -simplification into account. +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>' + @@ -95,102 +115,187 @@ 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: -- '%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 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 -- '%cD': committer date, RFC2822 style -- '%cr': committer date, relative -- '%ct': committer date, UNIX timestamp -- '%ci': committer date, ISO 8601 format -- '%d': ref names, like the --decorate option of linkgit:git-log[1] -- '%e': encoding -- '%s': subject -- '%f': sanitized subject line, suitable for a filename -- '%b': body -- '%B': raw body (unwrapped subject and body) -- '%N': commit notes -- '%GG': raw verification message from GPG for a signed commit -- '%G?': show "G" for a Good signature, "B" for a Bad signature, "U" for a good, - untrusted signature and "N" for no signature -- '%GS': show the name of the signer for a signed commit -- '%GK': show the key used to sign a signed commit -- '%gD': reflog selector, e.g., `refs/stash@{1}` -- '%gd': shortened reflog selector, e.g., `stash@{1}` -- '%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 -- '%Cred': switch color to red -- '%Cgreen': switch color to green -- '%Cblue': switch color to blue -- '%Creset': reset color -- '%C(...)': color specification, as described in color.branch.* config option; - adding `auto,` at the beginning will emit color only when colors are - enabled for log output (by `color.diff`, `color.ui`, or `--color`, and - respecting the `auto` settings of the former if we are going to a - terminal). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring - on the next placeholders until the color is switched again. -- '%m': left, right or boundary mark -- '%n': newline -- '%%': a raw '%' -- '%x00': print a byte from a hex code -- '%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 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]) +'%al':: author email local-part (the part before the '@' sign) +'%aL':: author local-part (see '%al') 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 +'%as':: author date, short format (`YYYY-MM-DD`) +'%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]) +'%cl':: committer email local-part (the part before the '@' sign) +'%cL':: committer local-part (see '%cl') 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 +'%cs':: committer date, short format (`YYYY-MM-DD`) +'%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 +'%GT':: show the trust level for the key 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` placeholder will use the "short" decoration -format if `--decorate` was not already provided on the command line. +`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, line-feeds that -immediately precede the expansion are deleted if and only if the +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 diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt index eea0e306a8..7a6da6db78 100644 --- a/Documentation/pretty-options.txt +++ b/Documentation/pretty-options.txt @@ -3,9 +3,13 @@ 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' and 'format:<string>'. See - the "PRETTY FORMATS" section for some additional details for each - format. When omitted, the format defaults to 'medium'. + 'full', 'fuller', 'reference', '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]). @@ -22,7 +26,7 @@ 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". It also overrides the `log.abbrevCommit` variable. --oneline:: This is a shorthand for "--pretty=oneline --abbrev-commit" @@ -33,22 +37,41 @@ people using 80-column terminals. 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. + 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[=<ref>]:: 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` nor `--oneline` option given + 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 +`core.notesRef` and `notes.displayRef` variables (or corresponding environment overrides). See linkgit:git-config[1] for more details. + -With an optional '<ref>' argument, show this notes ref instead of the -default notes ref(s). The ref is taken to be in `refs/notes/` if it -is not qualified. +With an optional '<ref>' argument, use the ref to find the notes +to display. The ref 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 @@ -66,6 +89,7 @@ being displayed. Examples: "--notes=foo" will show only notes from --[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 diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt index 18cffc25b8..95ea849902 100644 --- a/Documentation/pull-fetch-param.txt +++ b/Documentation/pull-fetch-param.txt @@ -12,67 +12,92 @@ ifndef::git-pull[] endif::git-pull[] <refspec>:: - The format of a <refspec> parameter is an optional plus - `+`, followed by the source ref <src>, followed - by a colon `:`, followed by the destination ref <dst>. + 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 the section "CONFIGURED REMOTE-TRACKING BRANCHES" + in 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 empty string, the local -ref that matches it is fast-forwarded using <src>. -If the optional plus `+` is used, the local ref -is updated even if it does not result in a fast-forward -update. +is fetched, and if <dst> is not an empty string, an attempt +is made to update the local ref that matches it. + -[NOTE] -If the remote branch from which you want to pull is -modified in non-linear ways such as being rewound and -rebased frequently, then a pull will attempt a merge with -an older version of itself, likely conflict, and fail. -It is under these conditions that you would want to use -the `+` sign to indicate non-fast-forward updates will -be needed. There is currently no easy 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. +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] -You never do your own development on branches that appear -on the right hand side of a <refspec> colon on `Pull:` lines; -they are to be updated by 'git fetch'. If you intend to do -development derived from a remote branch `B`, have a `Pull:` -line to track it (i.e. `Pull: B:remote-B`), and have a separate -branch `my-B` to do your development on top of it. The latter -is created by `git branch my-B remote-B` (or its equivalent `git -checkout -b my-B remote-B`). Run `git fetch` to keep track of -the progress of the remote side, and when you see something new -on the remote branch, merge it into your development branch with -`git pull . remote-B`, while you are on `my-B` branch. +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 -`Pull:` <refspec> lines for a <repository> and running +`remote.<repository>.fetch` entries in your configuration +for a <repository> and running a 'git pull' command without any explicit <refspec> parameters. -<refspec> listed explicitly on the command line are always +<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 refs, you would be making -an Octopus. While 'git pull' run without any explicit <refspec> -parameter takes default <refspec>s from `Pull:` lines, it -merges only the first <refspec> found into the current branch, -after fetching all the remote refs. This is because making an +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. -+ -Some short-cut notations are also supported. -+ -* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`; - it requests fetching everything up to the given tag. -ifndef::git-pull[] -* A parameter <ref> without a colon fetches that ref into FETCH_HEAD, -endif::git-pull[] -ifdef::git-pull[] -* A parameter <ref> without a colon merges <ref> into the current - branch, endif::git-pull[] - and updates the remote-tracking branches (if any). diff --git a/Documentation/rev-list-description.txt b/Documentation/rev-list-description.txt new file mode 100644 index 0000000000..a9efa7fa27 --- /dev/null +++ b/Documentation/rev-list-description.txt @@ -0,0 +1,61 @@ +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 reachable from any of +the commits given on the command line form a set, 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: + +ifdef::git-rev-list[] +----------------------------------------------------------------------- +$ git rev-list foo bar ^baz +----------------------------------------------------------------------- +endif::git-rev-list[] +ifdef::git-log[] +----------------------------------------------------------------------- +$ git log foo bar ^baz +----------------------------------------------------------------------- +endif::git-log[] + +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 "^'<commit1>' '<commit2>'". For example, either of +the following may be used interchangeably: + +ifdef::git-rev-list[] +----------------------------------------------------------------------- +$ git rev-list origin..HEAD +$ git rev-list HEAD ^origin +----------------------------------------------------------------------- +endif::git-rev-list[] +ifdef::git-log[] +----------------------------------------------------------------------- +$ git log origin..HEAD +$ git log HEAD ^origin +----------------------------------------------------------------------- +endif::git-log[] + +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: + +ifdef::git-rev-list[] +----------------------------------------------------------------------- +$ git rev-list A B --not $(git merge-base --all A B) +$ git rev-list A...B +----------------------------------------------------------------------- +endif::git-rev-list[] +ifdef::git-log[] +----------------------------------------------------------------------- +$ git log A B --not $(git merge-base --all A B) +$ git log A...B +----------------------------------------------------------------------- +endif::git-log[] diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 5bdfb42852..b01b2b6773 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -13,38 +13,30 @@ 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>`, @@ -52,7 +44,6 @@ endif::git-rev-list[] 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 @@ -60,57 +51,60 @@ endif::git-rev-list[] 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 as -if it is part of the log message. +When `--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, + 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 regexp limiting patterns without regard to letters 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 regexp. - Requires libpcre to be compiled in. + 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`. @@ -118,7 +112,6 @@ if it is part of the log message. --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` @@ -135,34 +128,30 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit). 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. + 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'. + for all following revision specifiers, up to the next `--not`. --all:: - - Pretend as if all the refs in `refs/` are listed on the - command line as '<commit>'. + 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. @@ -174,60 +163,88 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit). is automatically prepended if missing. If pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the end is implied. ---ignore-missing:: +--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. + 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 + 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. + 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 + 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). It however 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 +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 range, + List only commits on the respective side of a symmetric difference, i.e. only those which would be marked `<` resp. `>` by `--left-right`. + @@ -238,7 +255,6 @@ 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 @@ -247,34 +263,58 @@ list. -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', - nor 'commit1\...commit2' notations cannot be used). + and 'commit1\...commit2' notations cannot be used). + -With '\--pretty' format other than oneline (for obvious reasons), +With `--pretty` format other than `oneline` and `reference` (for obvious reasons), this causes the output to have two extra lines of information -taken from the reflog. By default, 'commit@\{Nth}' notation is -used in the output. When the starting commit is specified as -'commit@\{now}', output also uses 'commit@\{timestamp}' notation -instead. Under '\--pretty=oneline', the commit message is +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'. +This option cannot be combined with `--reverse`. See also linkgit:git-reflog[1]. ++ +Under `--pretty=reference`, this information will not be shown at all. --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 ~~~~~~~~~~~~~~~~~~~~~~ @@ -287,11 +327,9 @@ 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. @@ -299,33 +337,33 @@ 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:: +--show-pulls:: + Include all commits from the default mode, but also any merge + commits that are not TREESAME to the first parent but are + TREESAME to a later parent. This mode is helpful for showing + the merge commits that "first introduced" a change to a branch. +--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 + 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 @@ -352,36 +390,35 @@ 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 + ``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". +* 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", +* `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. +* `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`. +* `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 +`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 + (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 @@ -400,12 +437,11 @@ 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 +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 @@ -425,9 +461,8 @@ 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). + (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 @@ -441,7 +476,7 @@ themselves. This results in `-------------' ----------------------------------------------------------------------- + -Compare to '\--full-history' without rewriting above. Note that `E` +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`. @@ -450,22 +485,19 @@ 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 +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). + `--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: @@ -484,7 +516,7 @@ history according to the following rules: -- + The effect of this is best shown by way of comparing to -'\--full-history' with parent rewriting. The example turns into: +`--full-history` with parent rewriting. The example turns into: + ----------------------------------------------------------------------- .-A---M---N---O @@ -494,7 +526,7 @@ The effect of this is best shown by way of comparing to `---------' ----------------------------------------------------------------------- + -Note the major differences in `N`, `P` and `Q` over '--full-history': +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 @@ -508,14 +540,13 @@ Note the major differences in `N`, `P` and `Q` over '--full-history': parent and is TREESAME. -- -Finally, there is a fifth simplification mode available: +There is another 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. + 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: + @@ -530,14 +561,14 @@ As an example use case, consider the following commit history: 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 +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' +excluding `C` and `K`. This is exactly what the `--ancestry-path` option does. Applied to the 'D..M' range, it results in: + ----------------------------------------------------------------------- @@ -548,7 +579,136 @@ option does. Applied to the 'D..M' range, it results in: L--M ----------------------------------------------------------------------- -The '\--simplify-by-decoration' option allows you to view only the +Before discussing another option, `--show-pulls`, we need to +create a new example history. + +A common problem users face when looking at simplified history is that a +commit they know changed a file somehow does not appear in the file's +simplified history. Let's demonstrate a new example and show how options +such as `--full-history` and `--simplify-merges` works in that case: + +----------------------------------------------------------------------- + .-A---M-----C--N---O---P + / / \ \ \/ / / + I B \ R-'`-Z' / + \ / \/ / + \ / /\ / + `---X--' `---Y--' +----------------------------------------------------------------------- + +For this example, suppose `I` created `file.txt` which was modified by +`A`, `B`, and `X` in different ways. The single-parent commits `C`, `Z`, +and `Y` do not change `file.txt`. The merge commit `M` was created by +resolving the merge conflict to include both changes from `A` and `B` +and hence is not TREESAME to either. The merge commit `R`, however, was +created by ignoring the contents of `file.txt` at `M` and taking only +the contents of `file.txt` at `X`. Hence, `R` is TREESAME to `X` but not +`M`. Finally, the natural merge resolution to create `N` is to take the +contents of `file.txt` at `R`, so `N` is TREESAME to `R` but not `C`. +The merge commits `O` and `P` are TREESAME to their first parents, but +not to their second parents, `Z` and `Y` respectively. + +When using the default mode, `N` and `R` both have a TREESAME parent, so +those edges are walked and the others are ignored. The resulting history +graph is: + +----------------------------------------------------------------------- + I---X +----------------------------------------------------------------------- + +When using `--full-history`, Git walks every edge. This will discover +the commits `A` and `B` and the merge `M`, but also will reveal the +merge commits `O` and `P`. With parent rewriting, the resulting graph is: + +----------------------------------------------------------------------- + .-A---M--------N---O---P + / / \ \ \/ / / + I B \ R-'`--' / + \ / \/ / + \ / /\ / + `---X--' `------' +----------------------------------------------------------------------- + +Here, the merge commits `O` and `P` contribute extra noise, as they did +not actually contribute a change to `file.txt`. They only merged a topic +that was based on an older version of `file.txt`. This is a common +issue in repositories using a workflow where many contributors work in +parallel and merge their topic branches along a single trunk: manu +unrelated merges appear in the `--full-history` results. + +When using the `--simplify-merges` option, the commits `O` and `P` +disappear from the results. This is because the rewritten second parents +of `O` and `P` are reachable from their first parents. Those edges are +removed and then the commits look like single-parent commits that are +TREESAME to their parent. This also happens to the commit `N`, resulting +in a history view as follows: + +----------------------------------------------------------------------- + .-A---M--. + / / \ + I B R + \ / / + \ / / + `---X--' +----------------------------------------------------------------------- + +In this view, we see all of the important single-parent changes from +`A`, `B`, and `X`. We also see the carefully-resolved merge `M` and the +not-so-carefully-resolved merge `R`. This is usually enough information +to determine why the commits `A` and `B` "disappeared" from history in +the default view. However, there are a few issues with this approach. + +The first issue is performance. Unlike any previous option, the +`--simplify-merges` option requires walking the entire commit history +before returning a single result. This can make the option difficult to +use for very large repositories. + +The second issue is one of auditing. When many contributors are working +on the same repository, it is important which merge commits introduced +a change into an important branch. The problematic merge `R` above is +not likely to be the merge commit that was used to merge into an +important branch. Instead, the merge `N` was used to merge `R` and `X` +into the important branch. This commit may have information about why +the change `X` came to override the changes from `A` and `B` in its +commit message. + +--show-pulls:: + In addition to the commits shown in the default history, show + each merge commit that is not TREESAME to its first parent but + is TREESAME to a later parent. ++ +When a merge commit is included by `--show-pulls`, the merge is +treated as if it "pulled" the change from another branch. When using +`--show-pulls` on this example (and no other options) the resulting +graph is: ++ +----------------------------------------------------------------------- + I---X---R---N +----------------------------------------------------------------------- ++ +Here, the merge commits `R` and `N` are included because they pulled +the commits `X` and `R` into the base branch, respectively. These +merges are the reason the commits `A` and `B` do not appear in the +default history. ++ +When `--show-pulls` is paired with `--simplify-merges`, the +graph includes all of the necessary information: ++ +----------------------------------------------------------------------- + .-A---M--. N + / / \ / + I B R + \ / / + \ / / + `---X--' +----------------------------------------------------------------------- ++ +Notice that since `M` is reachable from `R`, the edge from `N` to `M` +was simplified away. However, `N` still appears in the history as an +important commit because it "pulled" the change `R` into the main +branch. + +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 @@ -556,55 +716,53 @@ 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). +ifndef::git-shortlog[] 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 - + 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. +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`. + 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 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 @@ -614,8 +772,9 @@ 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[] +endif::git-shortlog[] - +ifndef::git-shortlog[] Commit Ordering ~~~~~~~~~~~~~~~ @@ -654,48 +813,154 @@ 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`. +endif::git-shortlog[] - Output the commits in reverse order. - Cannot be combined with '\--walk-reflogs'. - +ifndef::git-shortlog[] 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 + 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'". + object _bar_ but not _foo_''. ---objects-edge:: +--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. - 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 "thin" pack, which records +--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. ---unpacked:: +--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. - Only useful with '--objects'; print the object IDs that are not +--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. ---no-walk[=(sorted|unsorted)]:: +--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. ++ +Multiple '--filter=' flags can be specified to combine filters. Only +objects which are accepted by every filter are included. ++ +The form '--filter=combine:<filter1>+<filter2>+...<filterN>' can also be +used to combined several filters, but this is harder than just repeating +the '--filter' flag and is usually not necessary. Filters are joined by +'{plus}' and individual filters are %-encoded (i.e. URL-encoded). +Besides the '{plus}' and '%' characters, the following characters are +reserved and also must be encoded: `~!@#$^&*()[]{}\;",<>?`+'`+ +as well as all characters with ASCII code <= `0x20`, which includes +space and newline. ++ +Other arbitrary characters can also be encoded. For instance, +'combine:tree:3+blob:none' and 'combine:tree%3A3+blob%3Anone' are +equivalent. + +--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 show in the order they were - given on the command line. Otherwise (if "sorted" or no argument - was given), the commits are show in reverse chronological order + `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`. +endif::git-shortlog[] - Overrides a previous --no-walk. - +ifndef::git-shortlog[] Commit Formatting ~~~~~~~~~~~~~~~~~ @@ -708,48 +973,85 @@ endif::git-rev-list[] include::pretty-options.txt[] --relative-date:: - Synonym for `--date=relative`. ---date=(relative|local|default|iso|rfc|short|raw):: - +--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 log command's --date option. + 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". -+ -`--date=local` shows timestamps in user's local timezone. -+ -`--date=iso` (or `--date=iso8601`) shows timestamps in ISO 8601 format. -+ +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 E-mail messages. -+ -`--date=short` shows only date but not time, in `YYYY-MM-DD` format. -+ -`--date=raw` shows the date in the internal raw Git format `%s %z` format. -+ -`--date=default` shows timestamps in the original timezone -(either committer's or author's). +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=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' below. + 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' below. + Also enables parent rewriting, see 'History Simplification' above. ifdef::git-rev-list[] --timestamp:: @@ -757,8 +1059,7 @@ ifdef::git-rev-list[] endif::git-rev-list[] --left-right:: - - Mark which side of a symmetric diff a commit is reachable from. + Mark which side of a symmetric difference a commit is reachable from. Commits from the left side are prefixed with `<` and those from the right with `>`. If combined with `--boundary`, those commits are prefixed with `-`. @@ -787,39 +1088,46 @@ you would get an output like this: ----------------------------------------------------------------------- --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' below. +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. +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 + 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 + `--cherry-mark`, omit patch equivalent commits from these counts and print the count for equivalent commits separated by a tab. endif::git-rev-list[] +endif::git-shortlog[] - +ifndef::git-shortlog[] ifndef::git-rev-list[] Diff Formatting ~~~~~~~~~~~~~~~ -Below are listed options that control the formatting of diff output. +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 @@ -827,26 +1135,30 @@ options may be given. See linkgit:git-diff-files[1] for more options. which were modified from all parents. --cc:: - - This flag implies the '-c' option and further compresses the + 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. --m:: +--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; + 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'. + Show the tree objects in the diff output. This implies `-r`. endif::git-rev-list[] +endif::git-shortlog[] diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index 2c06ed34ad..d9169c062e 100644 --- a/Documentation/revisions.txt +++ b/Documentation/revisions.txt @@ -7,6 +7,10 @@ syntax. Here are various ways to spell object names. The ones listed near the end of this list name trees and blobs contained in a commit. +NOTE: This document shows the "raw" syntax as seen by git. The shell +and other UIs might require additional quoting to protect special +characters and to avoid word splitting. + '<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e':: The full SHA-1 object name (40-byte hexadecimal string), or a leading substring that is unique within the repository. @@ -28,8 +32,8 @@ blobs contained in a commit. 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'); + useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD` + and `CHERRY_PICK_HEAD`); . otherwise, 'refs/<refname>' if it exists; @@ -41,39 +45,39 @@ blobs contained in a commit. . 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 +`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 +`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 +`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 +`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. +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'. + '@' alone is a shortcut for `HEAD`. -'<refname>@\{<date>\}', e.g. 'master@\{yesterday\}', 'HEAD@\{5 minutes ago\}':: +'[<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 + 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'. + certain times, see `--since` and `--until`. -'<refname>@\{<n>\}', e.g. 'master@\{1\}':: +'<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\}' @@ -82,21 +86,52 @@ some output processing may assume ref names in UTF-8. immediately following a ref name and the ref must have an existing log ('$GIT_DIR/logs/<refname>'). -'@\{<n>\}', e.g. '@\{1\}':: +'@{<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 checked out +'@{-<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\}':: +'[<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. A missing branchname defaults to the current one. + 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 -'<rev>{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0':: +$ 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}' @@ -104,7 +139,9 @@ some output processing may assume ref names in UTF-8. '<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. 'master{tilde}3':: +'<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 @@ -112,7 +149,7 @@ some output processing may assume ref names in UTF-8. '<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\}':: +'<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 @@ -124,21 +161,21 @@ some output processing may assume ref names in UTF-8. '<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, +'<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 +'<rev>{caret}\{tag\}' can be used to ensure that '<rev>' identifies an existing tag object. -'<rev>{caret}\{\}', e.g. 'v0.99.8{caret}\{\}':: +'<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}':: +'<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 @@ -149,25 +186,26 @@ existing tag object. 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. If the commit message starts with a - '!' you have to repeat that; the special sequence ':/!', - followed by something else than '!', is reserved for now. - The regular expression can match any part of the commit message. To - match messages starting with a string, one can use e.g. ':/^foo'. - -'<rev>:<path>', e.g. 'HEAD:README', ':README', 'master:./README':: + 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. - ':path' (with an empty part before the colon) - is a special case of the syntax described next: content - recorded in the index at the given path. 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':: +':[<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 @@ -195,7 +233,7 @@ G H I J A = = A^0 B = A^ = A^1 = A~1 - C = A^2 = A^2 + C = = A^2 D = A^^ = A^1^1 = A~2 E = B^2 = A^^2 F = B^3 = A^^3 @@ -209,58 +247,94 @@ SPECIFYING RANGES ----------------- History traversing commands such as `git log` operate on a set -of commits, not just a single commit. To these commands, -specifying a single revision with the notation described in the -previous section means the set of commits reachable from that -commit, following the commit ancestry chain. - -To exclude commits reachable from a commit, a prefix '{caret}' -notation is used. E.g. '{caret}r1 r2' means commits reachable -from 'r2' but exclude the ones reachable from 'r1'. - -This set operation appears so often that there is a shorthand -for it. When you have two commits 'r1' and 'r2' (named according -to the syntax explained in SPECIFYING REVISIONS above), you can ask -for commits that are reachable from r2 excluding those that are reachable -from r1 by '{caret}r1 r2' and it can be written as 'r1..r2'. - -A similar notation 'r1\...r2' is called symmetric difference -of 'r1' and 'r2' and is defined as -'r1 r2 --not $(git merge-base --all r1 r2)'. -It is the set of commits that are reachable from either one of -'r1' or 'r2' but not from both. - -In these two shorthands, you can omit one end and let it default to HEAD. +of commits, not just a single commit. + +For these commands, +specifying a single revision, using the notation described in the +previous section, means the set of commits `reachable` from the given +commit. + +Specifying several revisions means the set of commits reachable from +any of the given commits. + +A commit's reachable set is the commit itself and the commits in +its ancestry chain. + + +Commit Exclusions +~~~~~~~~~~~~~~~~~ + +'{caret}<rev>' (caret) Notation:: + To exclude commits reachable from a commit, a prefix '{caret}' + notation is used. E.g. '{caret}r1 r2' means commits reachable + from 'r2' but exclude the ones reachable from 'r1' (i.e. 'r1' and + its ancestors). + +Dotted Range Notations +~~~~~~~~~~~~~~~~~~~~~~ + +The '..' (two-dot) Range Notation:: + The '{caret}r1 r2' set operation appears so often that there is a shorthand + for it. When you have two commits 'r1' and 'r2' (named according + to the syntax explained in SPECIFYING REVISIONS above), you can ask + for commits that are reachable from r2 excluding those that are reachable + from r1 by '{caret}r1 r2' and it can be written as 'r1..r2'. + +The '...' (three-dot) Symmetric Difference Notation:: + A similar notation 'r1\...r2' is called symmetric difference + of 'r1' and 'r2' and is defined as + 'r1 r2 --not $(git merge-base --all r1 r2)'. + It is the set of commits that are reachable from either one of + 'r1' (left side) or 'r2' (right side) but not from both. + +In these two shorthand notations, you can omit one end and let it default to HEAD. For example, 'origin..' is a shorthand for 'origin..HEAD' and asks "What did I do since I forked from the origin branch?" Similarly, '..origin' is a shorthand for 'HEAD..origin' and asks "What did the origin do since I forked from them?" Note that '..' would mean 'HEAD..HEAD' which is an empty range that is both reachable and unreachable from HEAD. -Two other shorthands for naming a set that is formed by a commit -and its parent commits exist. The 'r1{caret}@' notation means all -parents of 'r1'. 'r1{caret}!' includes commit 'r1' but excludes -all of its parents. +Other <rev>{caret} Parent Shorthand Notations +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Three other shorthands exist, particularly useful for merge commits, +for naming a set that is formed by a commit and its parent commits. + +The 'r1{caret}@' notation means all parents of 'r1'. + +The 'r1{caret}!' notation includes commit 'r1' but excludes all of its parents. +By itself, this notation denotes the single commit 'r1'. + +The '<rev>{caret}-[<n>]' notation includes '<rev>' but excludes the <n>th +parent (i.e. a shorthand for '<rev>{caret}<n>..<rev>'), with '<n>' = 1 if +not given. This is typically useful for merge commits where you +can just pass '<commit>{caret}-' to get all the commits in the branch +that was merged in merge commit '<commit>' (including '<commit>' +itself). + +While '<rev>{caret}<n>' was about specifying a single commit parent, these +three notations also consider its parents. For example you can say +'HEAD{caret}2{caret}@', however you cannot say 'HEAD{caret}@{caret}2'. -To summarize: +Revision Range Summary +---------------------- '<rev>':: - Include commits that are reachable from (i.e. ancestors of) - <rev>. + Include commits that are reachable from <rev> (i.e. <rev> and its + ancestors). '{caret}<rev>':: - Exclude commits that are reachable from (i.e. ancestors of) - <rev>. + Exclude commits that are reachable from <rev> (i.e. <rev> and its + ancestors). '<rev1>..<rev2>':: Include commits that are reachable from <rev2> but exclude those that are reachable from <rev1>. When either <rev1> or - <rev2> is omitted, it defaults to 'HEAD'. + <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'. + 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 @@ -272,16 +346,35 @@ To summarize: as giving commit '<rev>' and then all its parents prefixed with '{caret}' to exclude them (and their ancestors). -Here are a handful of examples: - - D G H D - D F G H I J D F - ^G D H D - ^D B E I J F B - B..C C - B...C G H D E B C - ^D B C E I J F B C - C I J F C - C^@ I J F - C^! C - F^! D G H D F +'<rev>{caret}-<n>', e.g. 'HEAD{caret}-, HEAD{caret}-2':: + Equivalent to '<rev>{caret}<n>..<rev>', with '<n>' = 1 if not + given. + +Here are a handful of examples using the Loeliger illustration above, +with each step in the notation's expansion and selection carefully +spelt out: + +.... + Args Expanded arguments Selected commits + D G H D + D F G H I J D F + ^G D H D + ^D B E I J F B + ^D B C E I J F B C + C I J F C + B..C = ^B C C + B...C = B ^F C G H D E B C + B^- = B^..B + = ^B^1 B E I J F B + C^@ = C^1 + = F I J F + B^@ = B^1 B^2 B^3 + = D E F D G H E F I J + C^! = C ^C^@ + = C ^C^1 + = C ^F C + B^! = B ^B^@ + = B ^B^1 ^B^2 ^B^3 + = B ^D ^E ^F B + F^! D = F ^I ^J D G H D F +.... diff --git a/Documentation/sequencer.txt b/Documentation/sequencer.txt index 5747f442f2..3bceb56474 100644 --- a/Documentation/sequencer.txt +++ b/Documentation/sequencer.txt @@ -1,8 +1,12 @@ --continue:: Continue the operation in progress using the information in - '.git/sequencer'. Can be used to continue after resolving + `.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 diff --git a/Documentation/technical/api-allocation-growing.txt b/Documentation/technical/api-allocation-growing.txt deleted file mode 100644 index 542946b1ba..0000000000 --- a/Documentation/technical/api-allocation-growing.txt +++ /dev/null @@ -1,36 +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. diff --git a/Documentation/technical/api-argv-array.txt b/Documentation/technical/api-argv-array.txt deleted file mode 100644 index a6b7d83a8e..0000000000 --- a/Documentation/technical/api-argv-array.txt +++ /dev/null @@ -1,63 +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 link:api-string-list.html[string-list API] 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_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`:: - Detach the argv array from the `struct argv_array`, transferring - ownership of the allocated array and strings. - -`argv_array_free_detached`:: - Free the memory allocated by a `struct argv_array` that was later - detached and is now no longer needed. diff --git a/Documentation/technical/api-builtin.txt b/Documentation/technical/api-builtin.txt deleted file mode 100644 index f3c1357b7c..0000000000 --- a/Documentation/technical/api-builtin.txt +++ /dev/null @@ -1,70 +0,0 @@ -builtin API -=========== - -Adding a new built-in ---------------------- - -There are 4 things to do to add a built-in command implementation to -Git: - -. Define the implementation of the built-in command `foo` with - signature: - - int cmd_foo(int argc, const char **argv, const char *prefix); - -. Add the external declaration for the function to `builtin.h`. - -. Add the command to `commands[]` table in `handle_internal_command()`, - defined in `git.c`. The entry should look like: - - { "foo", cmd_foo, <options> }, -+ -where options is the bitwise-or of: - -`RUN_SETUP`:: - - Make sure there is a Git directory to work on, and if there is a - work tree, chdir to the top of it if the command was invoked - in a subdirectory. If there is no work tree, no chdir() is - done. - -`USE_PAGER`:: - - If the standard output is connected to a tty, spawn a pager and - feed our output to it. - -`NEED_WORK_TREE`:: - - Make sure there is a work tree, i.e. the command cannot act - on bare repositories. - This only makes sense when `RUN_SETUP` is also set. - -. Add `builtin/foo.o` to `BUILTIN_OBJS` in `Makefile`. - -Additionally, if `foo` is a new command, there are 3 more things to do: - -. Add tests to `t/` directory. - -. Write documentation in `Documentation/git-foo.txt`. - -. Add an entry for `git-foo` to `command-list.txt`. - -. Add an entry for `/git-foo` to `.gitignore`. - - -How a built-in is called ------------------------- - -The implementation `cmd_foo()` takes three parameters, `argc`, `argv, -and `prefix`. The first two are similar to what `main()` of a -standalone command would be called with. - -When `RUN_SETUP` is specified in the `commands[]` table, and when you -were started from a subdirectory of the work tree, `cmd_foo()` is called -after chdir(2) to the top of the work tree, and `prefix` gets the path -to the subdirectory the command started from. This allows you to -convert a user-supplied pathname (typically relative to that directory) -to a pathname relative to the top of the work tree. - -The return value from `cmd_foo()` becomes the exit status of the -command. diff --git a/Documentation/technical/api-config.txt b/Documentation/technical/api-config.txt deleted file mode 100644 index 230b3a0f60..0000000000 --- a/Documentation/technical/api-config.txt +++ /dev/null @@ -1,140 +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 `git_config_with_options` function lets the caller examine config -while adjusting some of the default behavior of `git_config`. It should -almost never be used by "regular" Git code that is looking up -configuration variables. It is intended for advanced callers like -`git-config`, which are intentionally tweaking the normal config-lookup -process. It takes two extra parameters: - -`filename`:: -If this parameter is non-NULL, it specifies the name of a file to -parse for configuration, rather than looking in the usual files. Regular -`git_config` defaults to `NULL`. - -`respect_includes`:: -Specify whether include directives should be followed in parsed files. -Regular `git_config` defaults to `1`. - -There is a special version of `git_config` called `git_config_early`. -This version takes an additional parameter to specify the repository -config, instead of having it looked up via `git_path`. This is useful -early in a Git program before the repository has been found. Unless -you're working with early setup code, you probably don't want to use -this. - -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`. - -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_config_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. - -Writing Config Files --------------------- - -TODO diff --git a/Documentation/technical/api-credentials.txt b/Documentation/technical/api-credentials.txt deleted file mode 100644 index c1b42a40d3..0000000000 --- a/Documentation/technical/api-credentials.txt +++ /dev/null @@ -1,268 +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[7] 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. - -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[5] (See configuration variables `credential.*`) diff --git a/Documentation/technical/api-decorate.txt b/Documentation/technical/api-decorate.txt deleted file mode 100644 index 1d52a6ce14..0000000000 --- a/Documentation/technical/api-decorate.txt +++ /dev/null @@ -1,6 +0,0 @@ -decorate API -============ - -Talk about <decorate.h> - -(Linus) diff --git a/Documentation/technical/api-diff.txt b/Documentation/technical/api-diff.txt deleted file mode 100644 index 8b001de0db..0000000000 --- a/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 `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/Documentation/technical/api-directory-listing.txt b/Documentation/technical/api-directory-listing.txt deleted file mode 100644 index 7f8e78d916..0000000000 --- a/Documentation/technical/api-directory-listing.txt +++ /dev/null @@ -1,105 +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 (the `*IGNORED*` flags are mutually exclusive): - -`DIR_SHOW_IGNORED`::: - - Return just ignored files in `entries[]`, not untracked files. - -`DIR_SHOW_IGNORED_TOO`::: - - Similar to `DIR_SHOW_IGNORED`, but return ignored files in `ignored[]` - in addition to untracked files in `entries[]`. - -`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/Documentation/technical/api-error-handling.txt b/Documentation/technical/api-error-handling.txt new file mode 100644 index 0000000000..ceeedd485c --- /dev/null +++ b/Documentation/technical/api-error-handling.txt @@ -0,0 +1,75 @@ +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/Documentation/technical/api-gitattributes.txt b/Documentation/technical/api-gitattributes.txt deleted file mode 100644 index ce363b6305..0000000000 --- a/Documentation/technical/api-gitattributes.txt +++ /dev/null @@ -1,128 +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 git_attr_check`:: - - This structure represents a set of attributes to check in a call - to `git_check_attr()` function, and receives the results. - - -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 -git_attr_check` 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 an array of `struct git_attr_check` to define the list of - attributes you would want to check. To populate this array, you would - need to define necessary attributes by calling `git_attr()` function. - -* Call `git_check_attr()` to check the attributes for the path. - -* Inspect `git_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 "indent" are set for different paths. - -. Prepare an array of `struct git_attr_check` with two elements (because - we are checking two attributes). Initialize their `attr` member with - pointers to `struct git_attr` obtained by calling `git_attr()`: - ------------- -static struct git_attr_check check[2]; -static void setup_check(void) -{ - if (check[0].attr) - return; /* already done */ - check[0].attr = git_attr("crlf"); - check[1].attr = git_attr("ident"); -} ------------- - -. Call `git_check_attr()` with the prepared array of `struct git_attr_check`: - ------------- - const char *path; - - setup_check(); - git_check_attr(path, ARRAY_SIZE(check), check); ------------- - -. Act on `.value` member of the result, left in `check[]`: - ------------- - const char *value = check[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 not 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 ...) { - ... - } ------------- - - -Querying All Attributes ------------------------ - -To get the values of all attributes associated with a file: - -* Call `git_all_attrs()`, which returns an array of `git_attr_check` - structures. - -* Iterate over the `git_attr_check` array to examine the attribute - names and values. The name of the attribute described by a - `git_attr_check` object can be retrieved via - `git_attr_name(check[i].attr)`. (Please note that no items will be - returned for unset attributes, so `ATTR_UNSET()` will return false - for all returned `git_array_check` objects.) - -* Free the `git_array_check` array. diff --git a/Documentation/technical/api-grep.txt b/Documentation/technical/api-grep.txt deleted file mode 100644 index a69cc8964d..0000000000 --- a/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/Documentation/technical/api-hash.txt b/Documentation/technical/api-hash.txt deleted file mode 100644 index e5061e0677..0000000000 --- a/Documentation/technical/api-hash.txt +++ /dev/null @@ -1,52 +0,0 @@ -hash API -======== - -The hash API is a collection of simple hash table functions. Users are expected -to implement their own hashing. - -Data Structures ---------------- - -`struct hash_table`:: - - The hash table structure. The `array` member points to the hash table - entries. The `size` member counts the total number of valid and invalid - entries in the table. The `nr` member keeps track of the number of - valid entries. - -`struct hash_table_entry`:: - - An opaque structure representing an entry in the hash table. The `hash` - member is the entry's hash key and the `ptr` member is the entry's - value. - -Functions ---------- - -`init_hash`:: - - Initialize the hash table. - -`free_hash`:: - - Release memory associated with the hash table. - -`insert_hash`:: - - Insert a pointer into the hash table. If an entry with that hash - already exists, a pointer to the existing entry's value is returned. - Otherwise NULL is returned. This allows callers to implement - chaining, etc. - -`lookup_hash`:: - - Lookup an entry in the hash table. If an entry with that hash exists - the entry's value is returned. Otherwise NULL is returned. - -`for_each_hash`:: - - Call a function for each entry in the hash table. The function is - expected to take the entry's value as its only argument and return an - int. If the function returns a negative int the loop is aborted - immediately. Otherwise, the return value is accumulated and the sum - returned upon completion of the loop. diff --git a/Documentation/technical/api-history-graph.txt b/Documentation/technical/api-history-graph.txt deleted file mode 100644 index 18142b6d29..0000000000 --- a/Documentation/technical/api-history-graph.txt +++ /dev/null @@ -1,174 +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 go - `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) { - graph_update(graph, commit); - 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/Documentation/technical/api-in-core-index.txt b/Documentation/technical/api-in-core-index.txt deleted file mode 100644 index adbdbf5d75..0000000000 --- a/Documentation/technical/api-in-core-index.txt +++ /dev/null @@ -1,21 +0,0 @@ -in-core index API -================= - -Talk about <read-cache.c> and <cache-tree.c>, things like: - -* cache -> the_index macros -* read_index() -* write_index() -* ie_match_stat() and ie_modified(); how they are different and when to - use which. -* index_name_pos() -* remove_index_entry_at() -* remove_file_from_index() -* add_file_to_index() -* add_index_entry() -* refresh_index() -* discard_index() -* cache_tree_invalidate_path() -* cache_tree_update() - -(JC, Linus) diff --git a/Documentation/technical/api-lockfile.txt b/Documentation/technical/api-lockfile.txt deleted file mode 100644 index dd894043ae..0000000000 --- a/Documentation/technical/api-lockfile.txt +++ /dev/null @@ -1,74 +0,0 @@ -lockfile API -============ - -The lockfile API serves two purposes: - -* Mutual exclusion. When we write out a new index file, first - we create a new file `$GIT_DIR/index.lock`, write the new - contents into it, and rename it to the final destination - `$GIT_DIR/index`. We try to create the `$GIT_DIR/index.lock` - file with O_EXCL so that we can notice and fail when somebody - else is already trying to update the index file. - -* Automatic cruft removal. After we create the "lock" file, we - may decide to `die()`, and we would want to make sure that we - remove the file that has not been committed to its final - destination. This is done by remembering the lockfiles we - created in a linked list and cleaning them up from an - `atexit(3)` handler. Outstanding lockfiles are also removed - when the program dies on a signal. - - -The functions -------------- - -hold_lock_file_for_update:: - - Take a pointer to `struct lock_file`, the filename of - the final destination (e.g. `$GIT_DIR/index`) and a flag - `die_on_error`. Attempt to create a lockfile for the - destination and return the file descriptor for writing - to the file. If `die_on_error` flag is true, it dies if - a lock is already taken for the file; otherwise it - returns a negative integer to the caller on failure. - -commit_lock_file:: - - Take a pointer to the `struct lock_file` initialized - with an earlier call to `hold_lock_file_for_update()`, - close the file descriptor and rename the lockfile to its - final destination. Returns 0 upon success, a negative - value on failure to close(2) or rename(2). - -rollback_lock_file:: - - Take a pointer to the `struct lock_file` initialized - with an earlier call to `hold_lock_file_for_update()`, - close the file descriptor and remove the lockfile. - -close_lock_file:: - Take a pointer to the `struct lock_file` initialized - with an earlier call to `hold_lock_file_for_update()`, - and close the file descriptor. Returns 0 upon success, - a negative value on failure to close(2). - -Because the structure is used in an `atexit(3)` handler, its -storage has to stay throughout the life of the program. It -cannot be an auto variable allocated on the stack. - -Call `commit_lock_file()` or `rollback_lock_file()` when you are -done writing to the file descriptor. If you do not call either -and simply `exit(3)` from the program, an `atexit(3)` handler -will close and remove the lockfile. - -If you need to close the file descriptor you obtained from -`hold_lock_file_for_update` function yourself, do so by calling -`close_lock_file()`. You should never call `close(2)` yourself! -Otherwise the `struct -lock_file` structure still remembers that the file descriptor -needs to be closed, and a later call to `commit_lock_file()` or -`rollback_lock_file()` will result in duplicate calls to -`close(2)`. Worse yet, if you `close(2)`, open another file -descriptor for completely different purpose, and then call -`commit_lock_file()` or `rollback_lock_file()`, they may close -that unrelated file descriptor. diff --git a/Documentation/technical/api-merge.txt b/Documentation/technical/api-merge.txt index 9dc1bed768..487d4d83ff 100644 --- a/Documentation/technical/api-merge.txt +++ b/Documentation/technical/api-merge.txt @@ -28,77 +28,9 @@ 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. +Check ll-merge.h for details. 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) +Check ll-merge.h for details. diff --git a/Documentation/technical/api-object-access.txt b/Documentation/technical/api-object-access.txt deleted file mode 100644 index 03bb0e950d..0000000000 --- a/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_sha1_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/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt index 0be2b5159f..2e2e7c10c6 100644 --- a/Documentation/technical/api-parse-options.txt +++ b/Documentation/technical/api-parse-options.txt @@ -29,9 +29,9 @@ that allow to change the behavior of a command. The parse-options API allows: -* 'sticked' and 'separate form' of options with arguments. - `-oArg` is sticked, `-o Arg` is separate form. - `--option=Arg` is sticked, `--option Arg` is separate form. +* 'stuck' and 'separate form' of options with arguments. + `-oArg` is stuck, `-o Arg` is separate form. + `--option=Arg` is stuck, `--option Arg` is separate form. * Long options may be 'abbreviated', as long as the abbreviation is unambiguous. @@ -144,8 +144,12 @@ There are some macros to easily define options: `OPT_COUNTUP(short, long, &int_var, description)`:: Introduce a count-up option. - `int_var` is incremented on each use of `--option`, and - reset to zero with `--no-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. @@ -160,25 +164,28 @@ There are some macros to easily define options: `int_var` is set to `integer` with `--option`, and reset to zero with `--no-option`. -`OPT_SET_PTR(short, long, &ptr_var, description, ptr)`:: - Introduce a boolean option. - If used, set `ptr_var` to `ptr`. - `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_DATE(short, long, &int_var, description)`:: - Introduce an option with date argument, see `approxidate()`. - The timestamp 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, &int_var, description)`:: +`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 `int_var`. + The timestamp is put into `timestamp_t_var`. `OPT_CALLBACK(short, long, &var, arg_str, description, func_ptr)`:: Introduce an option with argument. @@ -191,8 +198,10 @@ There are some macros to easily define options: The filename will be prefixed by passing the filename along with the prefix argument of `parse_options()` to `prefix_filename()`. -`OPT_ARGUMENT(long, description)`:: +`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 @@ -216,6 +225,26 @@ There are some macros to easily define options: 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()`. diff --git a/Documentation/technical/api-quote.txt b/Documentation/technical/api-quote.txt deleted file mode 100644 index e8a1bce94e..0000000000 --- a/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/Documentation/technical/api-ref-iteration.txt b/Documentation/technical/api-ref-iteration.txt deleted file mode 100644 index aa1c50f181..0000000000 --- a/Documentation/technical/api-ref-iteration.txt +++ /dev/null @@ -1,81 +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 unsigned char *sha1, - 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. - -* `head_ref_submodule()`, `for_each_ref_submodule()`, - `for_each_ref_in_submodule()`, `for_each_tag_ref_submodule()`, - `for_each_branch_ref_submodule()`, `for_each_remote_ref_submodule()` - do the same as the functions described above but for a specified - submodule. - -* `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 an non-zero value 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 can not 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/Documentation/technical/api-remote.txt b/Documentation/technical/api-remote.txt deleted file mode 100644 index 4be87768f6..0000000000 --- a/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. - -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 (if a pattern, only the part outside of the wildcards); if there -is only one side, it is src, and dst is NULL; if sides exist but are -empty (i.e., the refspec either starts or ends with ':'), the -corresponding side is "". - -This parsing can be done to an array of strings to give an array of -struct refpsecs with parse_ref_spec(). - -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. - -`remote`:: - - The struct remote for that remote. - -`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/Documentation/technical/api-revision-walking.txt b/Documentation/technical/api-revision-walking.txt deleted file mode 100644 index 55b878ade8..0000000000 --- a/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 ---------- - -`init_revisions`:: - - Initialize a rev_info structure with default values. The second - 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/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt deleted file mode 100644 index 5d7d7f2d32..0000000000 --- a/Documentation/technical/api-run-command.txt +++ /dev/null @@ -1,241 +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 ---------- - -`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. - -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 (memset(&chld, 0, sizeof(chld));) 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. - -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. - -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/Documentation/technical/api-setup.txt b/Documentation/technical/api-setup.txt deleted file mode 100644 index 540e455689..0000000000 --- a/Documentation/technical/api-setup.txt +++ /dev/null @@ -1,49 +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 - -get_pathspec() is obsolete and should never be used in new code. - -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/Documentation/technical/api-sha1-array.txt b/Documentation/technical/api-sha1-array.txt deleted file mode 100644 index 3e75497a37..0000000000 --- a/Documentation/technical/api-sha1-array.txt +++ /dev/null @@ -1,76 +0,0 @@ -sha1-array API -============== - -The sha1-array API provides storage and manipulation of sets of SHA-1 -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 sha1_array`:: - - A single array of SHA-1 hashes. This should be initialized by - assignment from `SHA1_ARRAY_INIT`. The `sha1` 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 ---------- - -`sha1_array_append`:: - Add an item to the set. The sha1 will be placed at the end of - the array (but note that some operations below may lose this - ordering). - -`sha1_array_lookup`:: - Perform a binary search of the array for a specific sha1. - If found, returns the offset (in number of elements) of the - sha1. If not found, returns a negative integer. If the array is - not sorted, this function has the side effect of sorting it. - -`sha1_array_clear`:: - Free all memory associated with the array and return it to the - initial, empty state. - -`sha1_array_for_each_unique`:: - Efficiently iterate over each unique element of the list, - executing the callback function for each one. If the array is - not sorted, this function has the side effect of sorting it. - -Examples --------- - ------------------------------------------ -void print_callback(const unsigned char sha1[20], - void *data) -{ - printf("%s\n", sha1_to_hex(sha1)); -} - -void some_func(void) -{ - struct sha1_array hashes = SHA1_ARRAY_INIT; - unsigned char sha1[20]; - - /* Read objects into our set */ - while (read_object_from_stdin(sha1)) - sha1_array_append(&hashes, sha1); - - /* Check if some objects are in our set */ - while (read_object_from_stdin(sha1)) { - if (sha1_array_lookup(&hashes, sha1) >= 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. - */ - sha1_array_for_each_unique(&hashes, print_callback, NULL); -} ------------------------------------------ diff --git a/Documentation/technical/api-sigchain.txt b/Documentation/technical/api-sigchain.txt deleted file mode 100644 index 9e1189ef01..0000000000 --- a/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/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt deleted file mode 100644 index 3350d97dda..0000000000 --- a/Documentation/technical/api-strbuf.txt +++ /dev/null @@ -1,319 +0,0 @@ -strbuf API -========== - -strbuf's are meant to be used with all the usual C string and memory -APIs. Given that the length of the buffer is known, it's often better to -use the mem* functions than a str* one (memchr vs. strchr e.g.). -Though, one has to be careful about the fact that str* functions often -stop on NULs and that strbufs may have embedded NULs. - -An strbuf is NUL terminated for convenience, but no function in the -strbuf API actually relies on the string being free of NULs. - -strbufs has some invariants that are very important to keep in mind: - -. The `buf` member is never NULL, so it can be used in any usual C -string operations safely. strbuf's _have_ to be initialized either by -`strbuf_init()` or by `= STRBUF_INIT` before the invariants, though. -+ -Do *not* assume anything on what `buf` really is (e.g. if it is -allocated memory or not), use `strbuf_detach()` to unwrap a memory -buffer from its strbuf shell in a safe way. That is the sole supported -way. This will give you a malloced buffer that you can later `free()`. -+ -However, it is totally safe to modify anything in the string pointed by -the `buf` member, between the indices `0` and `len-1` (inclusive). - -. The `buf` member is a byte array that has at least `len + 1` bytes - allocated. The extra byte is used to store a `'\0'`, allowing the - `buf` member to be a valid C-string. Every strbuf function ensure this - invariant is preserved. -+ -NOTE: It is OK to "play" with the buffer directly if you work it this - way: -+ ----- -strbuf_grow(sb, SOME_SIZE); <1> -strbuf_setlen(sb, sb->len + SOME_OTHER_SIZE); ----- -<1> Here, the memory array starting at `sb->buf`, and of length -`strbuf_avail(sb)` is all yours, and you can be sure that -`strbuf_avail(sb)` is at least `SOME_SIZE`. -+ -NOTE: `SOME_OTHER_SIZE` must be smaller or equal to `strbuf_avail(sb)`. -+ -Doing so is safe, though if it has to be done in many places, adding the -missing API to the strbuf module is the way to go. -+ -WARNING: Do _not_ assume that the area that is yours is of size `alloc -- 1` even if it's true in the current implementation. Alloc is somehow a -"private" member that should not be messed with. Use `strbuf_avail()` -instead. - -Data structures ---------------- - -* `struct strbuf` - -This is the string buffer structure. The `len` member can be used to -determine the current length of the string, and `buf` member provides access to -the string itself. - -Functions ---------- - -* Life cycle - -`strbuf_init`:: - - Initialize the structure. The second parameter can be zero or a bigger - number to allocate memory, in case you want to prevent further reallocs. - -`strbuf_release`:: - - Release a string buffer and the memory it used. You should not use the - string buffer after using this function, unless you initialize it again. - -`strbuf_detach`:: - - Detach the string from the strbuf and returns it; you now own the - storage the string occupies and it is your responsibility from then on - to release it with `free(3)` when you are done with it. - -`strbuf_attach`:: - - Attach a string to a buffer. You should specify the string to attach, - the current length of the string and the amount of allocated memory. - The amount must be larger than the string length, because the string you - pass is supposed to be a NUL-terminated string. This string _must_ be - malloc()ed, and after attaching, the pointer cannot be relied upon - anymore, and neither be free()d directly. - -`strbuf_swap`:: - - Swap the contents of two string buffers. - -* Related to the size of the buffer - -`strbuf_avail`:: - - Determine the amount of allocated but unused memory. - -`strbuf_grow`:: - - Ensure that at least this amount of unused memory is available after - `len`. This is used when you know a typical size for what you will add - and want to avoid repetitive automatic resizing of the underlying buffer. - This is never a needed operation, but can be critical for performance in - some cases. - -`strbuf_setlen`:: - - Set the length of the buffer to a given value. This function does *not* - allocate new memory, so you should not perform a `strbuf_setlen()` to a - length that is larger than `len + strbuf_avail()`. `strbuf_setlen()` is - just meant as a 'please fix invariants from this strbuf I just messed - with'. - -`strbuf_reset`:: - - Empty the buffer by setting the size of it to zero. - -* Related to the contents of the buffer - -`strbuf_rtrim`:: - - Strip whitespace from the end of a string. - -`strbuf_cmp`:: - - Compare two buffers. Returns an integer less than, equal to, or greater - than zero if the first buffer is found, respectively, to be less than, - to match, or be greater than the second buffer. - -* Adding data to the buffer - -NOTE: All of the functions in this section will grow the buffer as necessary. -If they fail for some reason other than memory shortage and the buffer hadn't -been allocated before (i.e. the `struct strbuf` was set to `STRBUF_INIT`), -then they will free() it. - -`strbuf_addch`:: - - Add a single character to the buffer. - -`strbuf_insert`:: - - Insert data to the given position of the buffer. The remaining contents - will be shifted, not overwritten. - -`strbuf_remove`:: - - Remove given amount of data from a given position of the buffer. - -`strbuf_splice`:: - - Remove the bytes between `pos..pos+len` and replace it with the given - data. - -`strbuf_add_commented_lines`:: - - Add a NUL-terminated string to the buffer. Each line will be prepended - by a comment character and a blank. - -`strbuf_add`:: - - Add data of given length to the buffer. - -`strbuf_addstr`:: - -Add a NUL-terminated string to the buffer. -+ -NOTE: This function will *always* be implemented as an inline or a macro -that expands to: -+ ----- -strbuf_add(..., s, strlen(s)); ----- -+ -Meaning that this is efficient to write things like: -+ ----- -strbuf_addstr(sb, "immediate string"); ----- - -`strbuf_addbuf`:: - - Copy the contents of an other buffer at the end of the current one. - -`strbuf_adddup`:: - - Copy part of the buffer from a given position till a given length to the - end of the buffer. - -`strbuf_expand`:: - - This function can be used to expand a format string containing - placeholders. To that end, it parses the string and calls the specified - function for every percent sign found. -+ -The callback function is given a pointer to the character after the `%` -and a pointer to the struct strbuf. It is expected to add the expanded -version of the placeholder to the strbuf, e.g. to add a newline -character if the letter `n` appears after a `%`. The function returns -the length of the placeholder recognized and `strbuf_expand()` skips -over it. -+ -The format `%%` is automatically expanded to a single `%` as a quoting -mechanism; callers do not need to handle the `%` placeholder themselves, -and the callback function will not be invoked for this placeholder. -+ -All other characters (non-percent and not skipped ones) are copied -verbatim to the strbuf. If the callback returned zero, meaning that the -placeholder is unknown, then the percent sign is copied, too. -+ -In order to facilitate caching and to make it possible to give -parameters to the callback, `strbuf_expand()` passes a context pointer, -which can be used by the programmer of the callback as she sees fit. - -`strbuf_expand_dict_cb`:: - - Used as callback for `strbuf_expand()`, expects an array of - struct strbuf_expand_dict_entry as context, i.e. pairs of - placeholder and replacement string. The array needs to be - terminated by an entry with placeholder set to NULL. - -`strbuf_addbuf_percentquote`:: - - Append the contents of one strbuf to another, quoting any - percent signs ("%") into double-percents ("%%") in the - destination. This is useful for literal data to be fed to either - strbuf_expand or to the *printf family of functions. - -`strbuf_humanise_bytes`:: - - Append the given byte size as a human-readable string (i.e. 12.23 KiB, - 3.50 MiB). - -`strbuf_addf`:: - - Add a formatted string to the buffer. - -`strbuf_commented_addf`:: - - Add a formatted string prepended by a comment character and a - blank to the buffer. - -`strbuf_fread`:: - - Read a given size of data from a FILE* pointer to the buffer. -+ -NOTE: The buffer is rewound if the read fails. If -1 is returned, -`errno` must be consulted, like you would do for `read(3)`. -`strbuf_read()`, `strbuf_read_file()` and `strbuf_getline()` has the -same behaviour as well. - -`strbuf_read`:: - - Read the contents of a given file descriptor. The third argument can be - used to give a hint about the file size, to avoid reallocs. - -`strbuf_read_file`:: - - Read the contents of a file, specified by its path. The third argument - can be used to give a hint about the file size, to avoid reallocs. - -`strbuf_readlink`:: - - Read the target of a symbolic link, specified by its path. The third - argument can be used to give a hint about the size, to avoid reallocs. - -`strbuf_getline`:: - - Read a line from a FILE *, overwriting the existing contents - of the strbuf. The second argument specifies the line - terminator character, typically `'\n'`. - Reading stops after the terminator or at EOF. The terminator - is removed from the buffer before returning. Returns 0 unless - there was nothing left before EOF, in which case it returns `EOF`. - -`strbuf_getwholeline`:: - - Like `strbuf_getline`, but keeps the trailing terminator (if - any) in the buffer. - -`strbuf_getwholeline_fd`:: - - Like `strbuf_getwholeline`, but operates on a file descriptor. - It reads one character at a time, so it is very slow. Do not - use it unless you need the correct position in the file - descriptor. - -`stripspace`:: - - Strip whitespace from a buffer. The second parameter controls if - comments are considered contents to be removed or not. - -`strbuf_split_buf`:: -`strbuf_split_str`:: -`strbuf_split_max`:: -`strbuf_split`:: - - Split a string or strbuf into a list of strbufs at a specified - terminator character. The returned substrings include the - terminator characters. Some of these functions take a `max` - parameter, which, if positive, limits the output to that - number of substrings. - -`strbuf_list_free`:: - - Free a list of strbufs (for example, the return values of the - `strbuf_split()` functions). - -`launch_editor`:: - - Launch the user preferred editor to edit a file and fill the buffer - with the file's contents upon the user completing their editing. The - third argument can be used to set the environment which the editor is - run in. If the buffer is NULL the editor is launched as usual but the - file's contents are not read into the buffer upon completion. diff --git a/Documentation/technical/api-string-list.txt b/Documentation/technical/api-string-list.txt deleted file mode 100644 index 20be348834..0000000000 --- a/Documentation/technical/api-string-list.txt +++ /dev/null @@ -1,202 +0,0 @@ -string-list API -=============== - -The string_list API offers a data structure and functions to handle -sorted and unsorted string lists. A "sorted" list is one whose -entries are sorted by string value in `strcmp()` order. - -The 'string_list' struct used to be called 'path_list', but was renamed -because it is not specific to paths. - -The caller: - -. Allocates and clears a `struct string_list` variable. - -. Initializes the members. You might want to set the flag `strdup_strings` - if the strings should be strdup()ed. For example, this is necessary - when you add something like git_path("..."), since that function returns - a static buffer that will change with the next call to git_path(). -+ -If you need something advanced, you can manually malloc() the `items` -member (you need this if you add things later) and you should set the -`nr` and `alloc` members in that case, too. - -. Adds new items to the list, using `string_list_append`, - `string_list_append_nodup`, `string_list_insert`, - `string_list_split`, and/or `string_list_split_in_place`. - -. Can check if a string is in the list using `string_list_has_string` or - `unsorted_string_list_has_string` and get it from the list using - `string_list_lookup` for sorted lists. - -. Can sort an unsorted list using `sort_string_list`. - -. Can remove duplicate items from a sorted list using - `string_list_remove_duplicates`. - -. Can remove individual items of an unsorted list using - `unsorted_string_list_delete_item`. - -. Can remove items not matching a criterion from a sorted or unsorted - list using `filter_string_list`, or remove empty strings using - `string_list_remove_empty_items`. - -. Finally it should free the list using `string_list_clear`. - -Example: - ----- -struct string_list list = STRING_LIST_INIT_NODUP; -int i; - -string_list_append(&list, "foo"); -string_list_append(&list, "bar"); -for (i = 0; i < list.nr; i++) - printf("%s\n", list.items[i].string) ----- - -NOTE: It is more efficient to build an unsorted list and sort it -afterwards, instead of building a sorted list (`O(n log n)` instead of -`O(n^2)`). -+ -However, if you use the list to check if a certain string was added -already, you should not do that (using unsorted_string_list_has_string()), -because the complexity would be quadratic again (but with a worse factor). - -Functions ---------- - -* General ones (works with sorted and unsorted lists as well) - -`filter_string_list`:: - - Apply a function to each item in a list, retaining only the - items for which the function returns true. If free_util is - true, call free() on the util members of any items that have - to be deleted. Preserve the order of the items that are - retained. - -`string_list_remove_empty_items`:: - - Remove any empty strings from the list. If free_util is true, - call free() on the util members of any items that have to be - deleted. Preserve the order of the items that are retained. - -`print_string_list`:: - - Dump a string_list to stdout, useful mainly for debugging purposes. It - can take an optional header argument and it writes out the - string-pointer pairs of the string_list, each one in its own line. - -`string_list_clear`:: - - Free a string_list. The `string` pointer of the items will be freed in - case the `strdup_strings` member of the string_list is set. The second - parameter controls if the `util` pointer of the items should be freed - or not. - -* Functions for sorted lists only - -`string_list_has_string`:: - - Determine if the string_list has a given string or not. - -`string_list_insert`:: - - Insert a new element to the string_list. The returned pointer can be - handy if you want to write something to the `util` pointer of the - string_list_item containing the just added string. If the given - string already exists the insertion will be skipped and the - pointer to the existing item returned. -+ -Since this function uses xrealloc() (which die()s if it fails) if the -list needs to grow, it is safe not to check the pointer. I.e. you may -write `string_list_insert(...)->util = ...;`. - -`string_list_lookup`:: - - Look up a given string in the string_list, returning the containing - string_list_item. If the string is not found, NULL is returned. - -`string_list_remove_duplicates`:: - - Remove all but the first of consecutive entries that have the - same string value. If free_util is true, call free() on the - util members of any items that have to be deleted. - -* Functions for unsorted lists only - -`string_list_append`:: - - Append a new string to the end of the string_list. If - `strdup_string` is set, then the string argument is copied; - otherwise the new `string_list_entry` refers to the input - string. - -`string_list_append_nodup`:: - - Append a new string to the end of the string_list. The new - `string_list_entry` always refers to the input string, even if - `strdup_string` is set. This function can be used to hand - ownership of a malloc()ed string to a `string_list` that has - `strdup_string` set. - -`sort_string_list`:: - - Sort the list's entries by string value in `strcmp()` order. - -`unsorted_string_list_has_string`:: - - It's like `string_list_has_string()` but for unsorted lists. - -`unsorted_string_list_lookup`:: - - It's like `string_list_lookup()` but for unsorted lists. -+ -The above two functions need to look through all items, as opposed to their -counterpart for sorted lists, which performs a binary search. - -`unsorted_string_list_delete_item`:: - - Remove an item from a string_list. The `string` pointer of the items - will be freed in case the `strdup_strings` member of the string_list - is set. The third parameter controls if the `util` pointer of the - items should be freed or not. - -`string_list_split`:: -`string_list_split_in_place`:: - - Split a string into substrings on a delimiter character and - append the substrings to a `string_list`. If `maxsplit` is - non-negative, then split at most `maxsplit` times. Return the - number of substrings appended to the list. -+ -`string_list_split` requires a `string_list` that has `strdup_strings` -set to true; it leaves the input string untouched and makes copies of -the substrings in newly-allocated memory. -`string_list_split_in_place` requires a `string_list` that has -`strdup_strings` set to false; it splits the input string in place, -overwriting the delimiter characters with NULs and creating new -string_list_items that point into the original string (the original -string must therefore not be modified or freed while the `string_list` -is in use). - - -Data structures ---------------- - -* `struct string_list_item` - -Represents an item of the list. The `string` member is a pointer to the -string, and you may use the `util` member for any purpose, if you want. - -* `struct string_list` - -Represents the list itself. - -. The array of items are available via the `items` member. -. The `nr` member contains the number of items stored in the list. -. The `alloc` member is used to avoid reallocating at every insertion. - You should not tamper with it. -. Setting the `strdup_strings` member to 1 will strdup() the strings - before adding them, see above. diff --git a/Documentation/technical/api-trace2.txt b/Documentation/technical/api-trace2.txt new file mode 100644 index 0000000000..6b6085585d --- /dev/null +++ b/Documentation/technical/api-trace2.txt @@ -0,0 +1,1171 @@ += 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":"2","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[] + +When trace files are written to a target 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 message 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. +e.g: `void trace2_initialize_clock()`, `void trace2_initialize()`, +`int trace2_is_enabled()`, `void trace2_cmd_start(int argc, const char **argv)`. + +=== Command Detail Messages + +These are concerned with describing the specific Git command +after the command line, config, and environment are inspected. +e.g: `void trace2_cmd_name(const char *name)`, +`void trace2_cmd_mode(const char *mode)`. + +=== Child Process Messages + +These are concerned with the various spawned child processes, +including shell scripts, git commands, editors, pagers, and hooks. + +e.g: `void trace2_child_start(struct child_process *cmd)`. + +=== Git Thread Messages + +These messages are concerned with Git thread usage. + +e.g: `void trace2_thread_start(const char *thread_name)`. + +=== Region and Data Messages + +These are concerned with recording performance data +over regions or spans of code. e.g: +`void trace2_region_enter(const char *category, const char *label, const struct repository *repo)`. + +Refer to trace2.h for details about all trace2 functions. + +== 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. It + should always be the first event in a trace session. The EVENT format + version will be incremented if new event types are added, if existing + fields are removed, or if there are significant changes in + interpretation of existing events or fields. Smaller changes, such as + adding a new field to an existing event, will not require an increment + to the EVENT format version. ++ +------------ +{ + "event":"version", + ... + "evt":"2", # EVENT format version + "exe":"2.20.1.155.g426c96fcdb" # git version +} +------------ + +`"discard"`:: + This event is written to the git-trace2-discard sentinel file if there + are too many files in the target trace directory (see the + trace2.maxFiles config option). ++ +------------ +{ + "event":"discard", + ... +} +------------ + +`"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 +process 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, such as a config + setting, command-line flag, or environment variable. ++ +------------ +{ + "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 corresponding 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 items +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/Documentation/technical/api-tree-walking.txt b/Documentation/technical/api-tree-walking.txt deleted file mode 100644 index 14af37c3f1..0000000000 --- a/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 sha1 of - a tree. Returns the `buffer` member if the sha1 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/Documentation/technical/api-xdiff-interface.txt b/Documentation/technical/api-xdiff-interface.txt deleted file mode 100644 index 6296ecad1d..0000000000 --- a/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/Documentation/technical/bitmap-format.txt b/Documentation/technical/bitmap-format.txt new file mode 100644 index 0000000000..f8c18a0f7a --- /dev/null +++ b/Documentation/technical/bitmap-format.txt @@ -0,0 +1,164 @@ +GIT bitmap v1 format +==================== + + - A header appears at the beginning: + + 4-byte signature: {'B', 'I', 'T', 'M'} + + 2-byte version number (network byte order) + The current implementation only supports version 1 + of the bitmap index (the same one as JGit). + + 2-byte flags (network byte order) + + The following flags are supported: + + - BITMAP_OPT_FULL_DAG (0x1) REQUIRED + This flag must always be present. It implies that the bitmap + index has been generated for a packfile with full closure + (i.e. where every single object in the packfile can find + its parent links inside the same packfile). This is a + requirement for the bitmap index format, also present in JGit, + that greatly reduces the complexity of the implementation. + + - BITMAP_OPT_HASH_CACHE (0x4) + If present, the end of the bitmap file contains + `N` 32-bit name-hash values, one per object in the + pack. The format and meaning of the name-hash is + described below. + + 4-byte entry count (network byte order) + + The total count of entries (bitmapped commits) in this bitmap index. + + 20-byte checksum + + The SHA1 checksum of the pack this bitmap index belongs to. + + - 4 EWAH bitmaps that act as type indexes + + Type indexes are serialized after the hash cache in the shape + of four EWAH bitmaps stored consecutively (see Appendix A for + the serialization format of an EWAH bitmap). + + There is a bitmap for each Git object type, stored in the following + order: + + - Commits + - Trees + - Blobs + - Tags + + In each bitmap, the `n`th bit is set to true if the `n`th object + in the packfile is of that type. + + The obvious consequence is that the OR of all 4 bitmaps will result + in a full set (all bits set), and the AND of all 4 bitmaps will + result in an empty bitmap (no bits set). + + - N entries with compressed bitmaps, one for each indexed commit + + Where `N` is the total amount of entries in this bitmap index. + Each entry contains the following: + + - 4-byte object position (network byte order) + The position **in the index for the packfile** where the + bitmap for this commit is found. + + - 1-byte XOR-offset + The xor offset used to compress this bitmap. For an entry + in position `x`, a XOR offset of `y` means that the actual + bitmap representing this commit is composed by XORing the + bitmap for this entry with the bitmap in entry `x-y` (i.e. + the bitmap `y` entries before this one). + + Note that this compression can be recursive. In order to + XOR this entry with a previous one, the previous entry needs + to be decompressed first, and so on. + + The hard-limit for this offset is 160 (an entry can only be + xor'ed against one of the 160 entries preceding it). This + number is always positive, and hence entries are always xor'ed + with **previous** bitmaps, not bitmaps that will come afterwards + in the index. + + - 1-byte flags for this bitmap + At the moment the only available flag is `0x1`, which hints + that this bitmap can be re-used when rebuilding bitmap indexes + for the repository. + + - The compressed bitmap itself, see Appendix A. + +== Appendix A: Serialization format for an EWAH bitmap + +Ewah bitmaps are serialized in the same protocol as the JAVAEWAH +library, making them backwards compatible with the JGit +implementation: + + - 4-byte number of bits of the resulting UNCOMPRESSED bitmap + + - 4-byte number of words of the COMPRESSED bitmap, when stored + + - N x 8-byte words, as specified by the previous field + + This is the actual content of the compressed bitmap. + + - 4-byte position of the current RLW for the compressed + bitmap + +All words are stored in network byte order for their corresponding +sizes. + +The compressed bitmap is stored in a form of run-length encoding, as +follows. It consists of a concatenation of an arbitrary number of +chunks. Each chunk consists of one or more 64-bit words + + H L_1 L_2 L_3 .... L_M + +H is called RLW (run length word). It consists of (from lower to higher +order bits): + + - 1 bit: the repeated bit B + + - 32 bits: repetition count K (unsigned) + + - 31 bits: literal word count M (unsigned) + +The bitstream represented by the above chunk is then: + + - K repetitions of B + + - The bits stored in `L_1` through `L_M`. Within a word, bits at + lower order come earlier in the stream than those at higher + order. + +The next word after `L_M` (if any) must again be a RLW, for the next +chunk. For efficient appending to the bitstream, the EWAH stores a +pointer to the last RLW in the stream. + + +== Appendix B: Optional Bitmap Sections + +These sections may or may not be present in the `.bitmap` file; their +presence is indicated by the header flags section described above. + +Name-hash cache +--------------- + +If the BITMAP_OPT_HASH_CACHE flag is set, the end of the bitmap contains +a cache of 32-bit values, one per object in the pack. The value at +position `i` is the hash of the pathname at which the `i`th object +(counting in index order) in the pack can be found. This can be fed +into the delta heuristics to compare objects with similar pathnames. + +The hash algorithm used is: + + hash = 0; + while ((c = *name++)) + if (!isspace(c)) + hash = (hash >> 2) + (c << 24); + +Note that this hashing scheme is tied to the BITMAP_OPT_HASH_CACHE flag. +If implementations want to choose a different hashing scheme, they are +free to do so, but MUST allocate a new header flag (because comparing +hashes made under two different schemes would be pointless). diff --git a/Documentation/technical/bundle-format.txt b/Documentation/technical/bundle-format.txt new file mode 100644 index 0000000000..0e828151a5 --- /dev/null +++ b/Documentation/technical/bundle-format.txt @@ -0,0 +1,48 @@ += Git bundle v2 format + +The Git bundle format is a format that represents both refs and Git objects. + +== Format + +We will use ABNF notation to define the Git bundle format. See +protocol-common.txt for the details. + +---- +bundle = signature *prerequisite *reference LF pack +signature = "# v2 git bundle" LF + +prerequisite = "-" obj-id SP comment LF +comment = *CHAR +reference = obj-id SP refname LF + +pack = ... ; packfile +---- + +== Semantics + +A Git bundle consists of three parts. + +* "Prerequisites" lists the objects that are NOT included in the bundle and the + reader of the bundle MUST already have, in order to use the data in the + bundle. The objects stored in the bundle may refer to prerequisite objects and + anything reachable from them (e.g. a tree object in the bundle can reference + a blob that is reachable from a prerequisite) and/or expressed as a delta + against prerequisite objects. + +* "References" record the tips of the history graph, iow, what the reader of the + bundle CAN "git fetch" from it. + +* "Pack" is the pack data stream "git fetch" would send, if you fetch from a + repository that has the references recorded in the "References" above into a + repository that has references pointing at the objects listed in + "Prerequisites" above. + +In the bundle format, there can be a comment following a prerequisite obj-id. +This is a comment and it has no specific meaning. The writer of the bundle MAY +put any string here. The reader of the bundle MUST ignore the comment. + +=== Note on the shallow clone and a Git bundle + +Note that the prerequisites does not represent a shallow-clone boundary. The +semantics of the prerequisites and the shallow-clone boundaries are different, +and the Git bundle v2 format cannot represent a shallow clone repository. diff --git a/Documentation/technical/commit-graph-format.txt b/Documentation/technical/commit-graph-format.txt new file mode 100644 index 0000000000..440541045d --- /dev/null +++ b/Documentation/technical/commit-graph-format.txt @@ -0,0 +1,134 @@ +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. + +- The Bloom filter of the commit carrying the paths that were changed between + the commit and its first parent, if requested. + +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 multi-byte numbers are in network byte 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. + + Bloom Filter Index (ID: {'B', 'I', 'D', 'X'}) (N * 4 bytes) [Optional] + * The ith entry, BIDX[i], stores the number of bytes in all Bloom filters + from commit 0 to commit i (inclusive) in lexicographic order. The Bloom + filter for the i-th commit spans from BIDX[i-1] to BIDX[i] (plus header + length), where BIDX[-1] is 0. + * The BIDX chunk is ignored if the BDAT chunk is not present. + + Bloom Filter Data (ID: {'B', 'D', 'A', 'T'}) [Optional] + * It starts with header consisting of three unsigned 32-bit integers: + - Version of the hash algorithm being used. We currently only support + value 1 which corresponds to the 32-bit version of the murmur3 hash + implemented exactly as described in + https://en.wikipedia.org/wiki/MurmurHash#Algorithm and the double + hashing technique using seed values 0x293ae76f and 0x7e646e2 as + described in https://doi.org/10.1007/978-3-540-30494-4_26 "Bloom Filters + in Probabilistic Verification" + - The number of times a path is hashed and hence the number of bit positions + that cumulatively determine whether a file is present in the commit. + - The minimum number of bits 'b' per entry in the Bloom filter. If the filter + contains 'n' entries, then the filter size is the minimum number of 64-bit + words that contain n*b bits. + * The rest of the chunk is the concatenation of all the computed Bloom + filters for the commits in lexicographic order. + * Note: Commits with no changes or more than 512 changes have Bloom filters + of length zero. + * The BDAT chunk is present if and only if BIDX is present. + + 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/Documentation/technical/commit-graph.txt b/Documentation/technical/commit-graph.txt new file mode 100644 index 0000000000..808fa30b99 --- /dev/null +++ b/Documentation/technical/commit-graph.txt @@ -0,0 +1,350 @@ +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 +lexicographic 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 and 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://lore.kernel.org/git/20110713070517.GC18566@sigill.intra.peff.net/ + An abandoned patch that introduced generation numbers. + +[2] https://lore.kernel.org/git/20170908033403.q7e6dj7benasrjes@sigill.intra.peff.net/ + Discussion about generation numbers on commits and how they interact + with fsck. + +[3] https://lore.kernel.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://lore.kernel.org/git/20180108154822.54829-1-git@jeffhostetler.com/T/#u + A patch to remove the ahead-behind calculation from 'status'. + +[5] https://lore.kernel.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/Documentation/technical/directory-rename-detection.txt b/Documentation/technical/directory-rename-detection.txt new file mode 100644 index 0000000000..844629c8c4 --- /dev/null +++ b/Documentation/technical/directory-rename-detection.txt @@ -0,0 +1,115 @@ +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/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt new file mode 100644 index 0000000000..5b2db3be1e --- /dev/null +++ b/Documentation/technical/hash-function-transition.txt @@ -0,0 +1,827 @@ +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 re-encode 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://lore.kernel.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://lore.kernel.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://lore.kernel.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/ +[2] http://lore.kernel.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/ +[3] http://lore.kernel.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/ +[4] http://lore.kernel.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net +[5] https://lore.kernel.org/git/CAJo=hJtoX9=AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com/ diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index caf941a1c5..51a79e63de 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -20,13 +20,13 @@ URL syntax documented by RFC 1738, so they are of the form: http://<host>:<port>/<path>?<searchpart> -Within this documentation the placeholder $GIT_URL will stand for +Within this documentation the placeholder `$GIT_URL` will stand for the http:// repository URL entered by the end-user. -Servers SHOULD handle all requests to locations matching $GIT_URL, as +Servers SHOULD handle all requests to locations matching `$GIT_URL`, as both the "smart" and "dumb" HTTP protocols used by Git operate by appending additional path components onto the end of the user -supplied $GIT_URL string. +supplied `$GIT_URL` string. An example of a dumb client requesting for a loose object: @@ -43,10 +43,10 @@ An example of a request to a submodule: $GIT_URL: http://example.com/git/repo.git/path/submodule.git URL request: http://example.com/git/repo.git/path/submodule.git/info/refs -Clients MUST strip a trailing '/', if present, from the user supplied -$GIT_URL string to prevent empty path tokens ('//') from appearing +Clients MUST strip a trailing `/`, if present, from the user supplied +`$GIT_URL` string to prevent empty path tokens (`//`) from appearing in any URL sent to a server. Compatible clients MUST expand -'$GIT_URL/info/refs' as 'foo/info/refs' and not 'foo//info/refs'. +`$GIT_URL/info/refs` as `foo/info/refs` and not `foo//info/refs`. Authentication @@ -60,7 +60,7 @@ 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 2616. +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. @@ -103,14 +103,14 @@ Except where noted, all standard HTTP behavior SHOULD be assumed by both client and server. This includes (but is not necessarily limited to): -If there is no repository at $GIT_URL, or the resource pointed to by a -location matching $GIT_URL does not exist, the server MUST NOT respond -with '200 OK' response. A server SHOULD respond with -'404 Not Found', '410 Gone', or any other suitable HTTP status code +If there is no repository at `$GIT_URL`, or the resource pointed to by a +location matching `$GIT_URL` does not exist, the server MUST NOT respond +with `200 OK` response. A server SHOULD respond with +`404 Not Found`, `410 Gone`, or any other suitable HTTP status code which does not imply the resource exists as requested. -If there is a repository at $GIT_URL, but access is not currently -permitted, the server MUST respond with the '403 Forbidden' HTTP +If there is a repository at `$GIT_URL`, but access is not currently +permitted, the server MUST respond with the `403 Forbidden` HTTP status code. Servers SHOULD support both HTTP 1.0 and HTTP 1.1. @@ -126,9 +126,9 @@ Servers MAY return ETag and/or Last-Modified headers. Clients MAY revalidate cached entities by including If-Modified-Since and/or If-None-Match request headers. -Servers MAY return '304 Not Modified' if the relevant headers appear +Servers MAY return `304 Not Modified` if the relevant headers appear in the request and the entity has not changed. Clients MUST treat -'304 Not Modified' identical to '200 OK' by reusing the cached entity. +`304 Not Modified` identical to `200 OK` by reusing the cached entity. Clients MAY reuse a cached entity without revalidation if the Cache-Control and/or Expires header permits caching. Clients and @@ -148,7 +148,7 @@ HTTP clients that only support the "dumb" protocol MUST discover references by making a request for the special info/refs file of the repository. -Dumb HTTP clients MUST make a GET request to $GIT_URL/info/refs, +Dumb HTTP clients MUST make a `GET` request to `$GIT_URL/info/refs`, without any search/query parameters. C: GET $GIT_URL/info/refs HTTP/1.0 @@ -161,21 +161,21 @@ without any search/query parameters. S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{} The Content-Type of the returned info/refs entity SHOULD be -"text/plain; charset=utf-8", but MAY be any content type. +`text/plain; charset=utf-8`, but MAY be any content type. Clients MUST NOT attempt to validate the returned Content-Type. Dumb servers MUST NOT return a return type starting with -"application/x-git-". +`application/x-git-`. Cache-Control headers MAY be returned to disable caching of the returned entity. When examining the response clients SHOULD only examine the HTTP -status code. Valid responses are '200 OK', or '304 Not Modified'. +status code. Valid responses are `200 OK`, or `304 Not Modified`. The returned content is a UNIX formatted text file describing each ref and its known value. The file SHOULD be sorted by name according to the C locale ordering. The file SHOULD NOT include -the default ref named 'HEAD'. +the default ref named `HEAD`. info_refs = *( ref_record ) ref_record = any_ref / peeled_ref @@ -192,13 +192,14 @@ HTTP clients that support the "smart" protocol (or both the a parameterized request for the info/refs file of the repository. The request MUST contain exactly one query parameter, -'service=$servicename', where $servicename MUST be the service +`service=$servicename`, where `$servicename` MUST be the service name the client wishes to contact to complete the operation. The request MUST NOT contain additional query parameters. C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 - dumb server reply: +dumb server reply: + S: 200 OK S: S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint @@ -206,16 +207,23 @@ The request MUST NOT contain additional query parameters. S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0 S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{} - smart server reply: +smart server reply: + S: 200 OK S: Content-Type: application/x-git-upload-pack-advertisement S: Cache-Control: no-cache 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: 003fd049f6c27a2244e12041955e262a404c7faba355 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 ^^^^^^^^^^^^^^^^^^^^ @@ -228,7 +236,7 @@ Smart Server Response ^^^^^^^^^^^^^^^^^^^^^ If the server does not recognize the requested service name, or the requested service name has been disabled by the server administrator, -the server MUST respond with the '403 Forbidden' HTTP status code. +the server MUST respond with the `403 Forbidden` HTTP status code. Otherwise, smart servers MUST respond with the smart server reply format for the requested service name. @@ -236,38 +244,43 @@ format for the requested service name. Cache-Control headers SHOULD be used to disable caching of the returned entity. -The Content-Type MUST be 'application/x-$servicename-advertisement'. +The Content-Type MUST be `application/x-$servicename-advertisement`. Clients SHOULD fall back to the dumb protocol if another content type is returned. When falling back to the dumb protocol clients -SHOULD NOT make an additional request to $GIT_URL/info/refs, but +SHOULD NOT make an additional request to `$GIT_URL/info/refs`, but instead SHOULD use the response already in hand. Clients MUST NOT continue if they do not support the dumb protocol. -Clients MUST validate the status code is either '200 OK' or -'304 Not Modified'. +Clients MUST validate the status code is either `200 OK` or +`304 Not Modified`. Clients MUST validate the first five bytes of the response entity -matches the regex "^[0-9a-f]{4}#". If this test fails, clients +matches the regex `^[0-9a-f]{4}#`. If this test fails, clients MUST NOT continue. Clients MUST parse the entire response as a sequence of pkt-line records. -Clients MUST verify the first pkt-line is "# service=$servicename". +Clients MUST verify the first pkt-line is `# service=$servicename`. Servers MUST set $servicename to be the request parameter value. Servers SHOULD include an LF at the end of this line. Clients MUST ignore an LF at the end of the line. -Servers MUST terminate the response with the magic "0000" end +Servers MUST terminate the response with the magic `0000` end pkt-line marker. The returned response is a pkt-line stream describing each ref and its known value. The stream SHOULD be sorted by name according to the C locale ordering. The stream SHOULD include the default ref -named 'HEAD' as the first ref. The stream MUST include capability +named `HEAD` as the first ref. The stream MUST include capability declarations behind a NUL on the first ref. +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 @@ -286,12 +299,13 @@ declarations behind a NUL on the first ref. peeled_ref = PKT-LINE(obj-id SP name LF) PKT-LINE(obj-id SP name "^{}" LF + Smart Service git-upload-pack ------------------------------ -This service reads from the repository pointed to by $GIT_URL. +This service reads from the repository pointed to by `$GIT_URL`. Clients MUST first perform ref discovery with -'$GIT_URL/info/refs?service=git-upload-pack'. +`$GIT_URL/info/refs?service=git-upload-pack`. C: POST $GIT_URL/git-upload-pack HTTP/1.0 C: Content-Type: application/x-git-upload-pack-request @@ -307,153 +321,154 @@ Clients MUST first perform ref discovery with S: ....ACK %s, continue S: ....NAK -Clients MUST NOT reuse or revalidate a cached reponse. +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 +Clients MUST send at least one "want" command in the request body. +Clients MUST NOT reference an id in a "want" command which did not appear in the response obtained through ref discovery unless the -server advertises capability "allow-tip-sha1-in-want". +server advertises capability `allow-tip-sha1-in-want` or +`allow-reachable-sha1-in-want`. compute_request = want_list have_list request_end request_end = "0000" / "done" - want_list = PKT-LINE(want NUL cap_list LF) + want_list = PKT-LINE(want SP cap_list LF) *(want_pkt) want_pkt = PKT-LINE(want LF) want = "want" SP id - cap_list = *(SP capability) SP + cap_list = capability *(SP capability) have_list = *PKT-LINE("have" SP id LF) TODO: Document this further. -TODO: Don't use uppercase for variable names below. The Negotiation Algorithm ~~~~~~~~~~~~~~~~~~~~~~~~~ The computation to select the minimal pack proceeds as follows -(c = client, s = server): +(C = client, S = server): + +'init step:' + +C: Use ref discovery to obtain the advertised refs. - init step: - (c) Use ref discovery to obtain the advertised refs. - (c) Place any object seen into set ADVERTISED. +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: Build an empty set, `common`, to hold the objects that are later + determined to be on both ends. - (c) Start a queue, C_PENDING, ordered by commit time (popping newest - first). Add all client refs. When a commit is popped from - the queue its parents SHOULD be automatically inserted back. - Commits MUST only enter the queue once. +C: Build a set, `want`, of the objects from `advertised` the client + wants to fetch, based on what it saw during ref discovery. - one compute step: - (c) Send one $GIT_URL/git-upload-pack request: +C: Start a queue, `c_pending`, ordered by commit time (popping newest + first). Add all client refs. When a commit is popped from + the queue its parents SHOULD be automatically inserted back. + Commits MUST only enter the queue once. - C: 0032want <WANT #1>............................... - C: 0032want <WANT #2>............................... +'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 <common #1>............................. + C: 0032have <common #2>............................. .... - C: 0032have <HAVE #1>............................... - C: 0032have <HAVE #2>............................... + C: 0032have <have #1>............................... + C: 0032have <have #2>............................... .... C: 0000 - The stream is organized into "commands", with each command - appearing by itself in a pkt-line. Within a command line - the text leading up to the first space is the command name, - and the remainder of the line to the first LF is the value. - Command lines are terminated with an LF as the last byte of - the pkt-line value. +The stream is organized into "commands", with each command +appearing by itself in a pkt-line. Within a command line, +the text leading up to the first space is the command name, +and the remainder of the line to the first LF is the value. +Command lines are terminated with an LF as the last byte of +the pkt-line value. - Commands MUST appear in the following order, if they appear - at all in the request stream: +Commands MUST appear in the following order, if they appear +at all in the request stream: - * want - * have +* "want" +* "have" - The stream is terminated by a pkt-line flush ("0000"). +The stream is terminated by a pkt-line flush (`0000`). - A single "want" or "have" command MUST have one hex formatted - SHA-1 as its value. Multiple SHA-1s MUST be sent by sending - multiple commands. +A single "want" or "have" command MUST have one hex formatted +SHA-1 as its value. Multiple SHA-1s MUST be sent by sending +multiple commands. - The HAVE list is created by popping the first 32 commits - from C_PENDING. Less can be supplied if C_PENDING empties. +The `have` list is created by popping the first 32 commits +from `c_pending`. Less can be supplied if `c_pending` empties. - If the client has sent 256 HAVE commits and has not yet - received one of those back from S_COMMON, or the client has - emptied C_PENDING it SHOULD include a "done" command to let - the server know it won't proceed: +If the client has sent 256 "have" commits and has not yet +received one of those back from `s_common`, or the client has +emptied `c_pending` it SHOULD include a "done" command to let +the server know it won't proceed: C: 0009done - (s) Parse the git-upload-pack request: - - Verify all objects in WANT are directly reachable from refs. - - The server MAY walk backwards through history or through - the reflog to permit slightly stale requests. +S: Parse the git-upload-pack request: - If no WANT objects are received, send an error: +Verify all objects in `want` are directly reachable from refs. -TODO: Define error if no want lines are requested. +The server MAY walk backwards through history or through +the reflog to permit slightly stale requests. - If any WANT object is not reachable, send an error: +If no "want" objects are received, send an error: +TODO: Define error if no "want" lines are requested. -TODO: Define error if an invalid want is requested. +If any "want" object is not reachable, send an error: +TODO: Define error if an invalid "want" is requested. - Create an empty list, S_COMMON. +Create an empty list, `s_common`. - If 'have' was sent: +If "have" was sent: - Loop through the objects in the order supplied by the client. - For each object, if the server has the object reachable from - a ref, add it to S_COMMON. If a commit is added to S_COMMON, - do not add any ancestors, even if they also appear in HAVE. +Loop through the objects in the order supplied by the client. - (s) Send the git-upload-pack response: +For each object, if the server has the object reachable from +a ref, add it to `s_common`. If a commit is added to `s_common`, +do not add any ancestors, even if they also appear in `have`. - If the server has found a closed set of objects to pack or the - request ends with "done", it replies with the pack. +S: Send the git-upload-pack response: +If the server has found a closed set of objects to pack or the +request ends with "done", it replies with the pack. TODO: Document the pack based response - S: PACK... - The returned stream is the side-band-64k protocol supported - by the git-upload-pack service, and the pack is embedded into - stream 1. Progress messages from the server side MAY appear - in stream 2. + S: PACK... - Here a "closed set of objects" is defined to have at least - one path from every WANT to at least one COMMON object. +The returned stream is the side-band-64k protocol supported +by the git-upload-pack service, and the pack is embedded into +stream 1. Progress messages from the server side MAY appear +in stream 2. - If the server needs more information, it replies with a - status continue response: +Here a "closed set of objects" is defined to have at least +one path from every "want" to at least one "common" object. +If the server needs more information, it replies with a +status continue response: TODO: Document the non-pack response - (c) Parse the upload-pack response: - -TODO: Document parsing response +C: Parse the upload-pack response: + TODO: Document parsing response - Do another compute step. +'Do another compute step.' Smart Service git-receive-pack ------------------------------ -This service reads from the repository pointed to by $GIT_URL. +This service reads from the repository pointed to by `$GIT_URL`. Clients MUST first perform ref discovery with -'$GIT_URL/info/refs?service=git-receive-pack'. +`$GIT_URL/info/refs?service=git-receive-pack`. C: POST $GIT_URL/git-receive-pack HTTP/1.0 C: Content-Type: application/x-git-receive-pack-request @@ -468,7 +483,7 @@ Clients MUST first perform ref discovery with S: S: .... -Clients MUST NOT reuse or revalidate a cached reponse. +Clients MUST NOT reuse or revalidate a cached response. Servers MUST include sufficient Cache-Control headers to prevent caching of the response. @@ -497,7 +512,7 @@ TODO: Document this further. References ---------- -link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)] -link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1] +http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)] +http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1] link:technical/pack-protocol.html link:technical/protocol-capabilities.html diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index f352a9b22e..faa25c5c52 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -129,6 +129,9 @@ Git index format (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 @@ -167,7 +170,7 @@ Git index format 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 + 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), ... @@ -198,3 +201,157 @@ Git index format - 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 beginning 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 beginning 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/Documentation/technical/long-running-process-protocol.txt b/Documentation/technical/long-running-process-protocol.txt new file mode 100644 index 0000000000..aa0aa9af1c --- /dev/null +++ b/Documentation/technical/long-running-process-protocol.txt @@ -0,0 +1,50 @@ +Long-running process protocol +============================= + +This protocol is used when Git needs to communicate with an external +process throughout the entire life of a single Git command. All +communication is in pkt-line format (see technical/protocol-common.txt) +over standard input and standard output. + +Handshake +--------- + +Git starts by sending a welcome message (for example, +"git-filter-client"), a list of supported protocol version numbers, and +a flush packet. Git expects to read the welcome message with "server" +instead of "client" (for example, "git-filter-server"), exactly one +protocol version number from the previously sent list, and a flush +packet. All further communication will be based on the selected version. +The remaining protocol description below documents "version=2". Please +note that "version=42" in the example below does not exist and is only +there to illustrate how the protocol would look like with more than one +version. + +After the version negotiation Git sends a list of all capabilities that +it supports and a flush packet. Git expects to read a list of desired +capabilities, which must be a subset of the supported capabilities list, +and a flush packet as response: +------------------------ +packet: git> git-filter-client +packet: git> version=2 +packet: git> version=42 +packet: git> 0000 +packet: git< git-filter-server +packet: git< version=2 +packet: git< 0000 +packet: git> capability=clean +packet: git> capability=smudge +packet: git> capability=not-yet-invented +packet: git> 0000 +packet: git< capability=clean +packet: git< capability=smudge +packet: git< 0000 +------------------------ + +Shutdown +-------- + +Git will close +the command pipe on exit. The filter is expected to detect EOF +and exit gracefully on its own. Git will wait until the filter +process has stopped. diff --git a/Documentation/technical/multi-pack-index.txt b/Documentation/technical/multi-pack-index.txt new file mode 100644 index 0000000000..4e7631437a --- /dev/null +++ b/Documentation/technical/multi-pack-index.txt @@ -0,0 +1,109 @@ +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 core.multiPackIndex 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://lore.kernel.org/git/20180107181459.222909-1-dstolee@microsoft.com/ + An earlier RFC for the multi-pack-index feature + +[2] https://lore.kernel.org/git/alpine.DEB.2.20.1803091557510.23109@alexmv-linux/ + Git Merge 2018 Contributor's summit notes (includes discussion of MIDX) diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt index 8e5bf60be3..d3a142c652 100644 --- a/Documentation/technical/pack-format.txt +++ b/Documentation/technical/pack-format.txt @@ -36,6 +36,98 @@ Git pack format - The trailer records 20-byte SHA-1 checksum of all of the above. +=== Object types + +Valid object types are: + +- OBJ_COMMIT (1) +- OBJ_TREE (2) +- OBJ_BLOB (3) +- OBJ_TAG (4) +- OBJ_OFS_DELTA (6) +- OBJ_REF_DELTA (7) + +Type 5 is reserved for future expansion. Type 0 is invalid. + +=== Deltified representation + +Conceptually there are only four object types: commit, tree, tag and +blob. However to save space, an object could be stored as a "delta" of +another "base" object. These representations are assigned new types +ofs-delta and ref-delta, which is only valid in a pack file. + +Both ofs-delta and ref-delta store the "delta" to be applied to +another object (called 'base object') to reconstruct the object. The +difference between them is, ref-delta directly encodes 20-byte base +object name. If the base object is in the same pack, ofs-delta encodes +the offset of the base object in the pack instead. + +The base object could also be deltified if it's in the same pack. +Ref-delta can also refer to an object outside the pack (i.e. the +so-called "thin pack"). When stored on disk however, the pack should +be self contained to avoid cyclic dependency. + +The delta data is a sequence of instructions to reconstruct an object +from the base object. If the base object is deltified, it must be +converted to canonical form first. Each instruction appends more and +more data to the target object until it's complete. There are two +supported instructions so far: one for copy a byte range from the +source object and one for inserting new data embedded in the +instruction itself. + +Each instruction has variable length. Instruction type is determined +by the seventh bit of the first octet. The following diagrams follow +the convention in RFC 1951 (Deflate compressed data format). + +==== Instruction to copy from base object + + +----------+---------+---------+---------+---------+-------+-------+-------+ + | 1xxxxxxx | offset1 | offset2 | offset3 | offset4 | size1 | size2 | size3 | + +----------+---------+---------+---------+---------+-------+-------+-------+ + +This is the instruction format to copy a byte range from the source +object. It encodes the offset to copy from and the number of bytes to +copy. Offset and size are in little-endian order. + +All offset and size bytes are optional. This is to reduce the +instruction size when encoding small offsets or sizes. The first seven +bits in the first octet determines which of the next seven octets is +present. If bit zero is set, offset1 is present. If bit one is set +offset2 is present and so on. + +Note that a more compact instruction does not change offset and size +encoding. For example, if only offset2 is omitted like below, offset3 +still contains bits 16-23. It does not become offset2 and contains +bits 8-15 even if it's right next to offset1. + + +----------+---------+---------+ + | 10000101 | offset1 | offset3 | + +----------+---------+---------+ + +In its most compact form, this instruction only takes up one byte +(0x80) with both offset and size omitted, which will have default +values zero. There is another exception: size zero is automatically +converted to 0x10000. + +==== Instruction to add new data + + +----------+============+ + | 0xxxxxxx | data | + +----------+============+ + +This is the instruction to construct target object without the base +object. The following data is appended to the target object. The first +seven bits of the first octet determines the size of data in +bytes. The size must be non-zero. + +==== Reserved instruction + + +----------+============ + | 00000000 | + +----------+============ + +This is the instruction reserved for future expansion. + == Original (version 1) pack-*.idx files have the following format: - The header consists of 256 4-byte network byte order @@ -160,3 +252,81 @@ Pack file entry: <+ 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^32, 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, and offsets larger than + 2^31-1 must be stored in it instead. 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/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt index b7bd95152e..95a07db6e8 100644 --- a/Documentation/technical/pack-heuristics.txt +++ b/Documentation/technical/pack-heuristics.txt @@ -1,5 +1,5 @@ - Concerning Git's Packing Heuristics - =================================== +Concerning Git's Packing Heuristics +=================================== Oh, here's a really stupid question: diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index b898e97988..a4573d12ce 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -1,11 +1,11 @@ Packfile transfer protocols =========================== -Git supports transferring data in packfiles over the ssh://, git:// and +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. All three transports (ssh, git, file) use the same -protocol to transfer data. +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; @@ -14,6 +14,24 @@ 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 @@ -31,6 +49,20 @@ 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 ------------- @@ -38,18 +70,25 @@ 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. - 0032git-upload-pack /project.git\0host=myserver.com\0 + 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 ] + 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 -- -Only host-parameter is allowed in the git-proto-request. Clients -MUST NOT attempt to send additional parameters. It is used for the +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. @@ -57,16 +96,9 @@ 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" | + "003agit-upload-pack /schacon/gitbook.git\0host=example.com\0" | nc -v example.com 9418 -If the server refuses the request for some reasons, it could abort -gracefully with an error message. - ----- - error-line = PKT-LINE("ERR" SP explanation-text) ----- - SSH Transport ------------- @@ -109,6 +141,12 @@ we execute it without the leading '/'. 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 @@ -129,11 +167,13 @@ Reference Discovery ------------------- When the client initially connects the server will immediately respond -with a listing of each reference it has (all branches and tags) along +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 "0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" | + $ echo -e -n "0045git-upload-pack /schacon/gitbook.git\0host=example.com\0\0version=1\0" | nc -v example.com 9418 + 000eversion 1 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration @@ -143,9 +183,6 @@ with the object name that each reference currently points to. 003fe92df48743b7bc7d26bcaabfddde0a1e20cae47c refs/tags/v1.0^{} 0000 -Server SHOULD terminate each non-flush line using LF ("\n") terminator; -client MUST NOT complain if there is no terminator. - 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. @@ -160,19 +197,23 @@ immediately after the ref itself, if presented. A conforming server MUST peel the ref if it's an annotated tag. ---- - advertised-refs = (no-refs / list-of-refs) + advertised-refs = *1("version 1") + (no-refs / list-of-refs) + *shallow flush-pkt no-refs = PKT-LINE(zero-id SP "capabilities^{}" - NUL capability-list LF) + NUL capability-list) list-of-refs = first-ref *other-ref first-ref = PKT-LINE(obj-id SP refname - NUL capability-list LF) + NUL capability-list) other-ref = PKT-LINE(other-tip / other-peeled) - other-tip = obj-id SP refname LF - other-peeled = obj-id SP refname "^{}" LF + 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 / "-" / "_") @@ -191,7 +232,7 @@ 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. +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, @@ -204,19 +245,24 @@ 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) + shallow-line = PKT-LINE("shallow" SP obj-id) - depth-request = PKT_LINE("deepen" SP depth) + depth-request = PKT-LINE("deepen" SP depth) / + PKT-LINE("deepen-since" SP timestamp) / + PKT-LINE("deepen-not" SP ref) - first-want = PKT-LINE("want" SP obj-id SP capability-list LF) - additional-want = PKT-LINE("want" SP obj-id LF) + 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 @@ -234,10 +280,17 @@ 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 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. +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 @@ -281,7 +334,7 @@ so that there is always a block of 32 "in-flight on the wire" at a time. compute-end have-list = *have-line - have-line = PKT-LINE("have" SP obj-id LF) + have-line = PKT-LINE("have" SP obj-id) compute-end = flush-pkt / PKT-LINE("done") ---- @@ -299,7 +352,7 @@ In multi_ack mode: ready to make a packfile, it will blindly ACK all 'have' obj-ids back to the client. - * the server will then send a 'NACK' and then wait for another response + * 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: @@ -335,19 +388,24 @@ during a prior round. This helps to ensure that at least one common ancestor is found before we give up entirely. Once the 'done' line is read from the client, the server will either -send a final 'ACK obj-id' or it will send a 'NAK'. The server only sends +send a final 'ACK obj-id' or it will send a 'NAK'. 'obj-id' is the object +name of the last commit determined to be common. The server only sends ACK after 'done' if there is at least one common base and multi_ack or multi_ack_detailed is enabled. The server always sends NAK after 'done' if there is no common base found. +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 LF) + ack_multi = PKT-LINE("ACK" SP obj-id ack_status) ack_status = "continue" / "common" / "ready" - ack = PKT-LINE("ACK SP obj-id LF) - nak = PKT-LINE("NAK" LF) + ack = PKT-LINE("ACK" SP obj-id) + nak = PKT-LINE("NAK") ---- A simple clone may look like this (with no 'have' lines): @@ -445,7 +503,8 @@ The reference discovery phase is done nearly the same way as it is in the fetching protocol. Each reference obj-id and name on the server is sent in packet-line format to the client, followed by a flush-pkt. The only real difference is that the capability listing is different - the only -possible values are 'report-status', 'delete-refs' and 'ofs-delta'. +possible values are 'report-status', 'delete-refs', 'ofs-delta' and +'push-options'. Reference Update Request and Packfile Transfer ---------------------------------------------- @@ -456,15 +515,15 @@ that it wants to update, it sends a line listing the obj-id currently on the server, the obj-id the client would like to update it to and the name of the reference. -This list is followed by a flush-pkt and then the packfile that should -contain all the objects that the server will need to complete the new -references. +This list is followed by a flush-pkt. ---- - update-request = command-list [pack-file] + update-requests = *shallow ( command-list | push-cert ) - command-list = PKT-LINE(command NUL capability-list LF) - *PKT-LINE(command LF) + shallow = PKT-LINE("shallow" SP obj-id) + + command-list = PKT-LINE(command NUL capability-list) + *PKT-LINE(command) flush-pkt command = create / delete / update @@ -475,17 +534,55 @@ references. old-id = obj-id new-id = obj-id - pack-file = "PACK" 28*(OCTET) + 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. -The pack-file MUST NOT be sent if the only command used is 'delete'. +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 pack-file MUST be sent if either create or update command is used, +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 pack-file. The only time 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. @@ -495,6 +592,35 @@ 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 ------------- @@ -511,14 +637,14 @@ update was successful, or 'ng [refname] [error]' if the update was not. 1*(command-status) flush-pkt - unpack-status = PKT-LINE("unpack" SP unpack-result LF) + 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 LF) - command-fail = PKT-LINE("ng" SP refname SP error-msg LF) + command-ok = PKT-LINE("ok" SP refname) + command-fail = PKT-LINE("ng" SP refname SP error-msg) - error-msg = 1*(OCTECT) ; where not "ok" + error-msg = 1*(OCTET) ; where not "ok" ---- Updates can be unsuccessful for a number of reasons. The reference can have @@ -531,14 +657,14 @@ can be rejected. An example client/server communication might look like this: ---- - S: 007c74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/local\0report-status delete-refs ofs-delta\n + 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: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/team\n + S: 003d74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/team\n S: 0000 - C: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe 74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/debug\n - C: 003e74730d410fcb6603ace96f1dc55ea6196122532d 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a refs/heads/master\n + C: 00677d1665144a3a975c05f1f43902ddaf084e784dbe 74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/debug\n + C: 006874730d410fcb6603ace96f1dc55ea6196122532d 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a refs/heads/master\n C: 0000 C: [PACKDATA] diff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt new file mode 100644 index 0000000000..318713abc3 --- /dev/null +++ b/Documentation/technical/packfile-uri.txt @@ -0,0 +1,78 @@ +Packfile URIs +============= + +This feature allows servers to serve part of their packfile response as URIs. +This allows server designs that improve scalability in bandwidth and CPU usage +(for example, by serving some data through a CDN), and (in the future) provides +some measure of resumability to clients. + +This feature is available only in protocol version 2. + +Protocol +-------- + +The server advertises the `packfile-uris` capability. + +If the client then communicates which protocols (HTTPS, etc.) it supports with +a `packfile-uris` argument, the server MAY send a `packfile-uris` section +directly before the `packfile` section (right after `wanted-refs` if it is +sent) containing URIs of any of the given protocols. The URIs point to +packfiles that use only features that the client has declared that it supports +(e.g. ofs-delta and thin-pack). See protocol-v2.txt for the documentation of +this section. + +Clients should then download and index all the given URIs (in addition to +downloading and indexing the packfile given in the `packfile` section of the +response) before performing the connectivity check. + +Server design +------------- + +The server can be trivially made compatible with the proposed protocol by +having it advertise `packfile-uris`, tolerating the client sending +`packfile-uris`, and never sending any `packfile-uris` section. But we should +include some sort of non-trivial implementation in the Minimum Viable Product, +at least so that we can test the client. + +This is the implementation: a feature, marked experimental, that allows the +server to be configured by one or more `uploadpack.blobPackfileUri=<sha1> +<uri>` entries. Whenever the list of objects to be sent is assembled, all such +blobs are excluded, replaced with URIs. The client will download those URIs, +expecting them to each point to packfiles containing single blobs. + +Client design +------------- + +The client has a config variable `fetch.uriprotocols` that determines which +protocols the end user is willing to use. By default, this is empty. + +When the client downloads the given URIs, it should store them with "keep" +files, just like it does with the packfile in the `packfile` section. These +additional "keep" files can only be removed after the refs have been updated - +just like the "keep" file for the packfile in the `packfile` section. + +The division of work (initial fetch + additional URIs) introduces convenient +points for resumption of an interrupted clone - such resumption can be done +after the Minimum Viable Product (see "Future work"). + +Future work +----------- + +The protocol design allows some evolution of the server and client without any +need for protocol changes, so only a small-scoped design is included here to +form the MVP. For example, the following can be done: + + * On the server, more sophisticated means of excluding objects (e.g. by + specifying a commit to represent that commit and all objects that it + references). + * On the client, resumption of clone. If a clone is interrupted, information + could be recorded in the repository's config and a "clone-resume" command + can resume the clone in progress. (Resumption of subsequent fetches is more + difficult because that must deal with the user wanting to use the repository + even after the fetch was interrupted.) + +There are some possible features that will require a change in protocol: + + * Additional HTTP headers (e.g. authentication) + * Byte range support + * Different file formats referenced by URIs (e.g. raw object) diff --git a/Documentation/technical/partial-clone.txt b/Documentation/technical/partial-clone.txt new file mode 100644 index 0000000000..b9e17e7a28 --- /dev/null +++ b/Documentation/technical/partial-clone.txt @@ -0,0 +1,375 @@ +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. + +A remote that can later provide the missing objects is called a +promisor remote, as it promises to send the objects when +requested. Initially Git supported only one promisor remote, the origin +remote from which the user cloned and that was configured in the +"extensions.partialClone" config option. Later support for more than +one promisor remote has been implemented. + +Use of partial clone requires that the user be online and the origin +remote or other promisor remotes 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 promisor remotes 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 promisor remotes have promised + that they have, 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 promisor remotes. ++ +When the normal object lookup fails to find an object, Git invokes +promisor_remote_get_direct() to try to get the object from a promisor +remote 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. + + +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. + + +Using many promisor remotes +--------------------------- + +Many promisor remotes can be configured and used. + +This allows for example a user to have multiple geographically-close +cache servers for fetching missing blobs while continuing to do +filtered `git-fetch` commands from the central server. + +When fetching objects, promisor remotes are tried one after the other +until all the objects have been fetched. + +Remotes that are considered "promisor" remotes are those specified by +the following configuration variables: + +- `extensions.partialClone = <name>` + +- `remote.<name>.promisor = true` + +- `remote.<name>.partialCloneFilter = ...` + +Only one promisor remote can be configured using the +`extensions.partialClone` config variable. This promisor remote will +be the last one tried when fetching objects. + +We decided to make it the last one we try, because it is likely that +someone using many promisor remotes is doing so because the other +promisor remotes are better for some reason (maybe they are closer or +faster for some kind of objects) than the origin, and the origin is +likely to be the remote specified by extensions.partialClone. + +This justification is not very strong, but one choice had to be made, +and anyway the long term plan should be to make the order somehow +fully configurable. + +For now though the other promisor remotes will be tried in the order +they appear in the config file. + +Current Limitations +------------------- + +- It is not possible to specify the order in which the promisor + remotes are tried in other ways than the order in which they appear + in the config file. ++ +It is also not possible to specify an order to be used when fetching +from one remote and a different order when fetching from another +remote. + +- It is not possible to push only specific objects to a promisor + remote. ++ +It is not possible to push at the same time to multiple promisor +remote in a specific order. + +- Dynamic object fetching will only ask promisor remotes for missing + objects. We assume that promisor remotes have 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 +----------- + +- Improve the way to specify the order in which promisor remotes are + tried. ++ +For example this could allow to specify explicitly something like: +"When fetching from this remote, I want to use these promisor remotes +in this order, though, when pushing or fetching to that remote, I want +to use those promisor remotes in that order." + +- Allow pushing to promisor remotes. ++ +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://lore.kernel.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://lore.kernel.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://lore.kernel.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://lore.kernel.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://lore.kernel.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://lore.kernel.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/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index fd8ffa5df3..36ccd14f97 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -1,6 +1,10 @@ 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 @@ -18,8 +22,9 @@ 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 'report-status', 'delete-refs', and 'quiet' capabilities are sent and -recognized by the receive-pack (push to server) process. +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 @@ -69,17 +74,50 @@ ends. Without multi_ack the client would have sent that c-b-a chain anyway, interleaved with S-R-Q. +multi_ack_detailed +------------------ +This is an extension of multi_ack that permits client to better +understand the server's in-memory state. See pack-protocol.txt, +section "Packfile Negotiation" for more information. + +no-done +------- +This capability should only be used with the smart HTTP protocol. If +multi_ack_detailed and no-done are both present, then the sender is +free to immediately send a pack following its first "ACK obj-id ready" +message. + +Without no-done in the smart HTTP protocol, the server session would +end and the client has to make another trip to send "done" before +the server can send the pack. no-done removes the last round and +thus slightly reduces latency. + thin-pack --------- -This capability means that the server can send a 'thin' pack, a pack -which does not contain base objects; if those base objects are available -on client side. Client requests 'thin-pack' capability when it -understands how to "thicken" it by adding required delta bases making -it self-contained. +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. -Client MUST NOT request 'thin-pack' capability if it cannot turn a thin -pack into a self-contained 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 @@ -135,9 +173,38 @@ 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 programatically assume the presence +purposes, and MUST NOT be used to programmatically assume the presence or absence of particular features. +object-format +------------- + +This capability, which takes a hash algorithm as an argument, indicates +that the server supports the given hash algorithms. It may be sent +multiple times; if so, the first one given is the one used in the ref +advertisement. + +When provided by the client, this indicates that it intends to use the +given hash algorithm to communicate. The algorithm provided must be one +that the server supports. + +If this capability is not provided, it is assumed that the only +supported algorithm is SHA-1. + +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 ------- @@ -145,6 +212,31 @@ This capability adds "deepen", "shallow" and "unshallow" commands to the fetch-pack/upload-pack protocol so clients can request shallow clones. +deepen-since +------------ + +This capability adds "deepen-since" command to fetch-pack/upload-pack +protocol so the client can request shallow clones that are cut at a +specific time, instead of depth. Internally it's equivalent of doing +"rev-list --max-age=<timestamp>" on the server side. "deepen-since" +cannot be used with "deepen". + +deepen-not +---------- + +This capability adds "deepen-not" command to fetch-pack/upload-pack +protocol so the client can request shallow clones that are cut at a +specific revision, instead of depth. Internally it's equivalent of +doing "rev-list --not <rev>" on the server side. "deepen-not" +cannot be used with "deepen", but can be used with "deepen-since". + +deepen-relative +--------------- + +If this capability is requested by the client, the semantics of +"deepen" command is changed. The "depth" argument is the depth from +the current shallow boundary, instead of the depth from remote refs. + no-progress ----------- @@ -211,9 +303,50 @@ 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/Documentation/technical/protocol-common.txt b/Documentation/technical/protocol-common.txt index fb7ff084f8..ecedb34bba 100644 --- a/Documentation/technical/protocol-common.txt +++ b/Documentation/technical/protocol-common.txt @@ -39,7 +39,7 @@ More specifically, they: caret `^`, colon `:`, question-mark `?`, asterisk `*`, or open bracket `[` anywhere. -. They cannot end with a slash `/` nor a dot `.`. +. They cannot end with a slash `/` or a dot `.`. . They cannot end with the sequence `.lock`. @@ -62,11 +62,14 @@ 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. - -The maximum length of a pkt-line's data component is 65520 bytes. -Implementations MUST NOT send pkt-line whose length exceeds 65524 -(65520 bytes of payload + 4 bytes of length data). +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"). diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt new file mode 100644 index 0000000000..e597b74da3 --- /dev/null +++ b/Documentation/technical/protocol-v2.txt @@ -0,0 +1,494 @@ +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 + * '0002' Message Packet (response-end-pkt) - indicates the end of a response + for stateless connections + +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 (aka 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. + +If the 'packfile-uris' feature is advertised, the following argument +can be included in the client's request as well as the potential +addition of the 'packfile-uris' section in the server's response as +explained below. + + packfile-uris <comma-separated list of protocols> + Indicates to the server that the client is willing to receive + URIs of any of the given protocols in place of objects in the + sent packfile. Before performing the connectivity check, the + client should download from all given URIs. Currently, the + protocols supported are "http" and "https". + +The response of `fetch` is broken into a number of sections separated by +delimiter packets (0001), with each section beginning with its section +header. Most sections are sent only when the packfile is sent. + + output = acknowledgements flush-pkt | + [acknowledgments delim-pkt] [shallow-info delim-pkt] + [wanted-refs delim-pkt] [packfile-uris delim-pkt] + packfile flush-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-uris = PKT-LINE("packfile-uris" LF) *packfile-uri + packfile-uri = PKT-LINE(40*(HEXDIGIT) SP *%x20-ff LF) + + 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 (thus requiring the server to send a packfile), + 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. + + 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-uris section + * This section is only included if the client sent + 'packfile-uris' and the server has at least one such URI to + send. + + * Always begins with the section header "packfile-uris". + + * For each URI the server sends, it sends a hash of the pack's + contents (as output by git index-pack) followed by the URI. + + * The hashes are 40 hex characters long. When Git upgrades to a new + hash algorithm, this might need to be updated. (It should match + whatever index-pack outputs after "pack\t" or "keep\t". + + 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. + + object-format +~~~~~~~~~~~~~~~ + +The server can advertise the `object-format` capability with a value `X` (in the +form `object-format=X`) to notify the client that the server is able to deal +with objects using hash algorithm X. If not specified, the server is assumed to +only handle SHA-1. If the client would like to use a hash algorithm other than +SHA-1, it should specify its object-format string. diff --git a/Documentation/technical/racy-git.txt b/Documentation/technical/racy-git.txt index 242a044db9..ceda4bbfda 100644 --- a/Documentation/technical/racy-git.txt +++ b/Documentation/technical/racy-git.txt @@ -41,13 +41,17 @@ 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, but this is not enabled by default +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). +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://lore.kernel.org/lkml/5577240D.7020309@gmail.com/ Racy Git -------- diff --git a/Documentation/technical/reftable.txt b/Documentation/technical/reftable.txt new file mode 100644 index 0000000000..2951840e9c --- /dev/null +++ b/Documentation/technical/reftable.txt @@ -0,0 +1,1083 @@ +reftable +-------- + +Overview +~~~~~~~~ + +Problem statement +^^^^^^^^^^^^^^^^^ + +Some repositories contain a lot of references (e.g. android at 866k, +rails at 31k). The existing packed-refs format takes up a lot of space +(e.g. 62M), and does not scale with additional references. Lookup of a +single reference requires linearly scanning the file. + +Atomic pushes modifying multiple references require copying the entire +packed-refs file, which can be a considerable amount of data moved +(e.g. 62M in, 62M out) for even small transactions (2 refs modified). + +Repositories with many loose references occupy a large number of disk +blocks from the local file system, as each reference is its own file +storing 41 bytes (and another file for the corresponding reflog). This +negatively affects the number of inodes available when a large number of +repositories are stored on the same filesystem. Readers can be penalized +due to the larger number of syscalls required to traverse and read the +`$GIT_DIR/refs` directory. + + +Objectives +^^^^^^^^^^ + +* Near constant time lookup for any single reference, even when the +repository is cold and not in process or kernel cache. +* Near constant time verification if an object name is referred to by at least +one reference (for allow-tip-sha1-in-want). +* Efficient enumeration of an entire namespace, such as `refs/tags/`. +* Support atomic push with `O(size_of_update)` operations. +* Combine reflog storage with ref storage for small transactions. +* Separate reflog storage for base refs and historical logs. + +Description +^^^^^^^^^^^ + +A reftable file is a portable binary file format customized for +reference storage. References are sorted, enabling linear scans, binary +search lookup, and range scans. + +Storage in the file is organized into variable sized blocks. Prefix +compression is used within a single block to reduce disk space. Block +size and alignment is tunable by the writer. + +Performance +^^^^^^^^^^^ + +Space used, packed-refs vs. reftable: + +[cols=",>,>,>,>,>",options="header",] +|=============================================================== +|repository |packed-refs |reftable |% original |avg ref |avg obj +|android |62.2 M |36.1 M |58.0% |33 bytes |5 bytes +|rails |1.8 M |1.1 M |57.7% |29 bytes |4 bytes +|git |78.7 K |48.1 K |61.0% |50 bytes |4 bytes +|git (heads) |332 b |269 b |81.0% |33 bytes |0 bytes +|=============================================================== + +Scan (read 866k refs), by reference name lookup (single ref from 866k +refs), and by SHA-1 lookup (refs with that SHA-1, from 866k refs): + +[cols=",>,>,>,>",options="header",] +|========================================================= +|format |cache |scan |by name |by SHA-1 +|packed-refs |cold |402 ms |409,660.1 usec |412,535.8 usec +|packed-refs |hot | |6,844.6 usec |20,110.1 usec +|reftable |cold |112 ms |33.9 usec |323.2 usec +|reftable |hot | |20.2 usec |320.8 usec +|========================================================= + +Space used for 149,932 log entries for 43,061 refs, reflog vs. reftable: + +[cols=",>,>",options="header",] +|================================ +|format |size |avg entry +|$GIT_DIR/logs |173 M |1209 bytes +|reftable |5 M |37 bytes +|================================ + +Details +~~~~~~~ + +Peeling +^^^^^^^ + +References stored in a reftable are peeled, a record for an annotated +(or signed) tag records both the tag object, and the object it refers +to. This is analogous to storage in the packed-refs format. + +Reference name encoding +^^^^^^^^^^^^^^^^^^^^^^^ + +Reference names are an uninterpreted sequence of bytes that must pass +linkgit:git-check-ref-format[1] as a valid reference name. + +Key unicity +^^^^^^^^^^^ + +Each entry must have a unique key; repeated keys are disallowed. + +Network byte order +^^^^^^^^^^^^^^^^^^ + +All multi-byte, fixed width fields are in network byte order. + +Varint encoding +^^^^^^^^^^^^^^^ + +Varint encoding is identical to the ofs-delta encoding method used +within pack files. + +Decoder works such as: + +.... +val = buf[ptr] & 0x7f +while (buf[ptr] & 0x80) { + ptr++ + val = ((val + 1) << 7) | (buf[ptr] & 0x7f) +} +.... + +Ordering +^^^^^^^^ + +Blocks are lexicographically ordered by their first reference. + +Directory/file conflicts +^^^^^^^^^^^^^^^^^^^^^^^^ + +The reftable format accepts both `refs/heads/foo` and +`refs/heads/foo/bar` as distinct references. + +This property is useful for retaining log records in reftable, but may +confuse versions of Git using `$GIT_DIR/refs` directory tree to maintain +references. Users of reftable may choose to continue to reject `foo` and +`foo/bar` type conflicts to prevent problems for peers. + +File format +~~~~~~~~~~~ + +Structure +^^^^^^^^^ + +A reftable file has the following high-level structure: + +.... +first_block { + header + first_ref_block +} +ref_block* +ref_index* +obj_block* +obj_index* +log_block* +log_index* +footer +.... + +A log-only file omits the `ref_block`, `ref_index`, `obj_block` and +`obj_index` sections, containing only the file header and log block: + +.... +first_block { + header +} +log_block* +log_index* +footer +.... + +in a log-only file the first log block immediately follows the file +header, without padding to block alignment. + +Block size +^^^^^^^^^^ + +The file's block size is arbitrarily determined by the writer, and does +not have to be a power of 2. The block size must be larger than the +longest reference name or log entry used in the repository, as +references cannot span blocks. + +Powers of two that are friendly to the virtual memory system or +filesystem (such as 4k or 8k) are recommended. Larger sizes (64k) can +yield better compression, with a possible increased cost incurred by +readers during access. + +The largest block size is `16777215` bytes (15.99 MiB). + +Block alignment +^^^^^^^^^^^^^^^ + +Writers may choose to align blocks at multiples of the block size by +including `padding` filled with NUL bytes at the end of a block to round +out to the chosen alignment. When alignment is used, writers must +specify the alignment with the file header's `block_size` field. + +Block alignment is not required by the file format. Unaligned files must +set `block_size = 0` in the file header, and omit `padding`. Unaligned +files with more than one ref block must include the link:#Ref-index[ref +index] to support fast lookup. Readers must be able to read both aligned +and non-aligned files. + +Very small files (e.g. a single ref block) may omit `padding` and the ref +index to reduce total file size. + +Header (version 1) +^^^^^^^^^^^^^^^^^^ + +A 24-byte header appears at the beginning of the file: + +.... +'REFT' +uint8( version_number = 1 ) +uint24( block_size ) +uint64( min_update_index ) +uint64( max_update_index ) +.... + +Aligned files must specify `block_size` to configure readers with the +expected block alignment. Unaligned files must set `block_size = 0`. + +The `min_update_index` and `max_update_index` describe bounds for the +`update_index` field of all log records in this file. When reftables are +used in a stack for link:#Update-transactions[transactions], these +fields can order the files such that the prior file's +`max_update_index + 1` is the next file's `min_update_index`. + +Header (version 2) +^^^^^^^^^^^^^^^^^^ + +A 28-byte header appears at the beginning of the file: + +.... +'REFT' +uint8( version_number = 2 ) +uint24( block_size ) +uint64( min_update_index ) +uint64( max_update_index ) +uint32( hash_id ) +.... + +The header is identical to `version_number=1`, with the 4-byte hash ID +("sha1" for SHA1 and "s256" for SHA-256) append to the header. + +For maximum backward compatibility, it is recommended to use version 1 when +writing SHA1 reftables. + +First ref block +^^^^^^^^^^^^^^^ + +The first ref block shares the same block as the file header, and is 24 +bytes smaller than all other blocks in the file. The first block +immediately begins after the file header, at position 24. + +If the first block is a log block (a log-only file), its block header +begins immediately at position 24. + +Ref block format +^^^^^^^^^^^^^^^^ + +A ref block is written as: + +.... +'r' +uint24( block_len ) +ref_record+ +uint24( restart_offset )+ +uint16( restart_count ) + +padding? +.... + +Blocks begin with `block_type = 'r'` and a 3-byte `block_len` which +encodes the number of bytes in the block up to, but not including the +optional `padding`. This is always less than or equal to the file's +block size. In the first ref block, `block_len` includes 24 bytes for +the file header. + +The 2-byte `restart_count` stores the number of entries in the +`restart_offset` list, which must not be empty. Readers can use +`restart_count` to binary search between restarts before starting a +linear scan. + +Exactly `restart_count` 3-byte `restart_offset` values precedes the +`restart_count`. Offsets are relative to the start of the block and +refer to the first byte of any `ref_record` whose name has not been +prefix compressed. Entries in the `restart_offset` list must be sorted, +ascending. Readers can start linear scans from any of these records. + +A variable number of `ref_record` fill the middle of the block, +describing reference names and values. The format is described below. + +As the first ref block shares the first file block with the file header, +all `restart_offset` in the first block are relative to the start of the +file (position 0), and include the file header. This forces the first +`restart_offset` to be `28`. + +ref record +++++++++++ + +A `ref_record` describes a single reference, storing both the name and +its value(s). Records are formatted as: + +.... +varint( prefix_length ) +varint( (suffix_length << 3) | value_type ) +suffix +varint( update_index_delta ) +value? +.... + +The `prefix_length` field specifies how many leading bytes of the prior +reference record's name should be copied to obtain this reference's +name. This must be 0 for the first reference in any block, and also must +be 0 for any `ref_record` whose offset is listed in the `restart_offset` +table at the end of the block. + +Recovering a reference name from any `ref_record` is a simple concat: + +.... +this_name = prior_name[0..prefix_length] + suffix +.... + +The `suffix_length` value provides the number of bytes available in +`suffix` to copy from `suffix` to complete the reference name. + +The `update_index` that last modified the reference can be obtained by +adding `update_index_delta` to the `min_update_index` from the file +header: `min_update_index + update_index_delta`. + +The `value` follows. Its format is determined by `value_type`, one of +the following: + +* `0x0`: deletion; no value data (see transactions, below) +* `0x1`: one object name; value of the ref +* `0x2`: two object names; value of the ref, peeled target +* `0x3`: symbolic reference: `varint( target_len ) target` + +Symbolic references use `0x3`, followed by the complete name of the +reference target. No compression is applied to the target name. + +Types `0x4..0x7` are reserved for future use. + +Ref index +^^^^^^^^^ + +The ref index stores the name of the last reference from every ref block +in the file, enabling reduced disk seeks for lookups. Any reference can +be found by searching the index, identifying the containing block, and +searching within that block. + +The index may be organized into a multi-level index, where the 1st level +index block points to additional ref index blocks (2nd level), which may +in turn point to either additional index blocks (e.g. 3rd level) or ref +blocks (leaf level). Disk reads required to access a ref go up with +higher index levels. Multi-level indexes may be required to ensure no +single index block exceeds the file format's max block size of +`16777215` bytes (15.99 MiB). To achieve constant O(1) disk seeks for +lookups the index must be a single level, which is permitted to exceed +the file's configured block size, but not the format's max block size of +15.99 MiB. + +If present, the ref index block(s) appears after the last ref block. + +If there are at least 4 ref blocks, a ref index block should be written +to improve lookup times. Cold reads using the index require 2 disk reads +(read index, read block), and binary searching < 4 blocks also requires +<= 2 reads. Omitting the index block from smaller files saves space. + +If the file is unaligned and contains more than one ref block, the ref +index must be written. + +Index block format: + +.... +'i' +uint24( block_len ) +index_record+ +uint24( restart_offset )+ +uint16( restart_count ) + +padding? +.... + +The index blocks begin with `block_type = 'i'` and a 3-byte `block_len` +which encodes the number of bytes in the block, up to but not including +the optional `padding`. + +The `restart_offset` and `restart_count` fields are identical in format, +meaning and usage as in ref blocks. + +To reduce the number of reads required for random access in very large +files the index block may be larger than other blocks. However, readers +must hold the entire index in memory to benefit from this, so it's a +time-space tradeoff in both file size and reader memory. + +Increasing the file's block size decreases the index size. Alternatively +a multi-level index may be used, keeping index blocks within the file's +block size, but increasing the number of blocks that need to be +accessed. + +index record +++++++++++++ + +An index record describes the last entry in another block. Index records +are written as: + +.... +varint( prefix_length ) +varint( (suffix_length << 3) | 0 ) +suffix +varint( block_position ) +.... + +Index records use prefix compression exactly like `ref_record`. + +Index records store `block_position` after the suffix, specifying the +absolute position in bytes (from the start of the file) of the block +that ends with this reference. Readers can seek to `block_position` to +begin reading the block header. + +Readers must examine the block header at `block_position` to determine +if the next block is another level index block, or the leaf-level ref +block. + +Reading the index ++++++++++++++++++ + +Readers loading the ref index must first read the footer (below) to +obtain `ref_index_position`. If not present, the position will be 0. The +`ref_index_position` is for the 1st level root of the ref index. + +Obj block format +^^^^^^^^^^^^^^^^ + +Object blocks are optional. Writers may choose to omit object blocks, +especially if readers will not use the object name to ref mapping. + +Object blocks use unique, abbreviated 2-32 object name keys, mapping to +ref blocks containing references pointing to that object directly, or as +the peeled value of an annotated tag. Like ref blocks, object blocks use +the file's standard block size. The abbrevation length is available in +the footer as `obj_id_len`. + +To save space in small files, object blocks may be omitted if the ref +index is not present, as brute force search will only need to read a few +ref blocks. When missing, readers should brute force a linear search of +all references to lookup by object name. + +An object block is written as: + +.... +'o' +uint24( block_len ) +obj_record+ +uint24( restart_offset )+ +uint16( restart_count ) + +padding? +.... + +Fields are identical to ref block. Binary search using the restart table +works the same as in reference blocks. + +Because object names are abbreviated by writers to the shortest unique +abbreviation within the reftable, obj key lengths have a variable length. Their +length must be at least 2 bytes. Readers must compare only for common prefix +match within an obj block or obj index. + +obj record +++++++++++ + +An `obj_record` describes a single object abbreviation, and the blocks +containing references using that unique abbreviation: + +.... +varint( prefix_length ) +varint( (suffix_length << 3) | cnt_3 ) +suffix +varint( cnt_large )? +varint( position_delta )* +.... + +Like in reference blocks, abbreviations are prefix compressed within an +obj block. On large reftables with many unique objects, higher block +sizes (64k), and higher restart interval (128), a `prefix_length` of 2 +or 3 and `suffix_length` of 3 may be common in obj records (unique +abbreviation of 5-6 raw bytes, 10-12 hex digits). + +Each record contains `position_count` number of positions for matching +ref blocks. For 1-7 positions the count is stored in `cnt_3`. When +`cnt_3 = 0` the actual count follows in a varint, `cnt_large`. + +The use of `cnt_3` bets most objects are pointed to by only a single +reference, some may be pointed to by a couple of references, and very +few (if any) are pointed to by more than 7 references. + +A special case exists when `cnt_3 = 0` and `cnt_large = 0`: there are no +`position_delta`, but at least one reference starts with this +abbreviation. A reader that needs exact reference names must scan all +references to find which specific references have the desired object. +Writers should use this format when the `position_delta` list would have +overflowed the file's block size due to a high number of references +pointing to the same object. + +The first `position_delta` is the position from the start of the file. +Additional `position_delta` entries are sorted ascending and relative to +the prior entry, e.g. a reader would perform: + +.... +pos = position_delta[0] +prior = pos +for (j = 1; j < position_count; j++) { + pos = prior + position_delta[j] + prior = pos +} +.... + +With a position in hand, a reader must linearly scan the ref block, +starting from the first `ref_record`, testing each reference's object names +(for `value_type = 0x1` or `0x2`) for full equality. Faster searching by +object name within a single ref block is not supported by the reftable format. +Smaller block sizes reduce the number of candidates this step must +consider. + +Obj index +^^^^^^^^^ + +The obj index stores the abbreviation from the last entry for every obj +block in the file, enabling reduced disk seeks for all lookups. It is +formatted exactly the same as the ref index, but refers to obj blocks. + +The obj index should be present if obj blocks are present, as obj blocks +should only be written in larger files. + +Readers loading the obj index must first read the footer (below) to +obtain `obj_index_position`. If not present, the position will be 0. + +Log block format +^^^^^^^^^^^^^^^^ + +Unlike ref and obj blocks, log blocks are always unaligned. + +Log blocks are variable in size, and do not match the `block_size` +specified in the file header or footer. Writers should choose an +appropriate buffer size to prepare a log block for deflation, such as +`2 * block_size`. + +A log block is written as: + +.... +'g' +uint24( block_len ) +zlib_deflate { + log_record+ + uint24( restart_offset )+ + uint16( restart_count ) +} +.... + +Log blocks look similar to ref blocks, except `block_type = 'g'`. + +The 4-byte block header is followed by the deflated block contents using +zlib deflate. The `block_len` in the header is the inflated size +(including 4-byte block header), and should be used by readers to +preallocate the inflation output buffer. A log block's `block_len` may +exceed the file's block size. + +Offsets within the log block (e.g. `restart_offset`) still include the +4-byte header. Readers may prefer prefixing the inflation output buffer +with the 4-byte header. + +Within the deflate container, a variable number of `log_record` describe +reference changes. The log record format is described below. See ref +block format (above) for a description of `restart_offset` and +`restart_count`. + +Because log blocks have no alignment or padding between blocks, readers +must keep track of the bytes consumed by the inflater to know where the +next log block begins. + +log record +++++++++++ + +Log record keys are structured as: + +.... +ref_name '\0' reverse_int64( update_index ) +.... + +where `update_index` is the unique transaction identifier. The +`update_index` field must be unique within the scope of a `ref_name`. +See the update transactions section below for further details. + +The `reverse_int64` function inverses the value so lexicographical +ordering the network byte order encoding sorts the more recent records +with higher `update_index` values first: + +.... +reverse_int64(int64 t) { + return 0xffffffffffffffff - t; +} +.... + +Log records have a similar starting structure to ref and index records, +utilizing the same prefix compression scheme applied to the log record +key described above. + +.... + varint( prefix_length ) + varint( (suffix_length << 3) | log_type ) + suffix + log_data { + old_id + new_id + varint( name_length ) name + varint( email_length ) email + varint( time_seconds ) + sint16( tz_offset ) + varint( message_length ) message + }? +.... + +Log record entries use `log_type` to indicate what follows: + +* `0x0`: deletion; no log data. +* `0x1`: standard git reflog data using `log_data` above. + +The `log_type = 0x0` is mostly useful for `git stash drop`, removing an +entry from the reflog of `refs/stash` in a transaction file (below), +without needing to rewrite larger files. Readers reading a stack of +reflogs must treat this as a deletion. + +For `log_type = 0x1`, the `log_data` section follows +linkgit:git-update-ref[1] logging and includes: + +* two object names (old id, new id) +* varint string of committer's name +* varint string of committer's email +* varint time in seconds since epoch (Jan 1, 1970) +* 2-byte timezone offset in minutes (signed) +* varint string of message + +`tz_offset` is the absolute number of minutes from GMT the committer was +at the time of the update. For example `GMT-0800` is encoded in reftable +as `sint16(-480)` and `GMT+0230` is `sint16(150)`. + +The committer email does not contain `<` or `>`, it's the value normally +found between the `<>` in a git commit object header. + +The `message_length` may be 0, in which case there was no message +supplied for the update. + +Contrary to traditional reflog (which is a file), renames are encoded as +a combination of ref deletion and ref creation. A deletion is a log +record with a zero new_id, and a creation is a log record with a zero old_id. + +Reading the log ++++++++++++++++ + +Readers accessing the log must first read the footer (below) to +determine the `log_position`. The first block of the log begins at +`log_position` bytes since the start of the file. The `log_position` is +not block aligned. + +Importing logs +++++++++++++++ + +When importing from `$GIT_DIR/logs` writers should globally order all +log records roughly by timestamp while preserving file order, and assign +unique, increasing `update_index` values for each log line. Newer log +records get higher `update_index` values. + +Although an import may write only a single reftable file, the reftable +file must span many unique `update_index`, as each log line requires its +own `update_index` to preserve semantics. + +Log index +^^^^^^^^^ + +The log index stores the log key +(`refname \0 reverse_int64(update_index)`) for the last log record of +every log block in the file, supporting bounded-time lookup. + +A log index block must be written if 2 or more log blocks are written to +the file. If present, the log index appears after the last log block. +There is no padding used to align the log index to block alignment. + +Log index format is identical to ref index, except the keys are 9 bytes +longer to include `'\0'` and the 8-byte `reverse_int64(update_index)`. +Records use `block_position` to refer to the start of a log block. + +Reading the index ++++++++++++++++++ + +Readers loading the log index must first read the footer (below) to +obtain `log_index_position`. If not present, the position will be 0. + +Footer +^^^^^^ + +After the last block of the file, a file footer is written. It begins +like the file header, but is extended with additional data. + +.... + HEADER + + uint64( ref_index_position ) + uint64( (obj_position << 5) | obj_id_len ) + uint64( obj_index_position ) + + uint64( log_position ) + uint64( log_index_position ) + + uint32( CRC-32 of above ) +.... + +If a section is missing (e.g. ref index) the corresponding position +field (e.g. `ref_index_position`) will be 0. + +* `obj_position`: byte position for the first obj block. +* `obj_id_len`: number of bytes used to abbreviate object names in +obj blocks. +* `log_position`: byte position for the first log block. +* `ref_index_position`: byte position for the start of the ref index. +* `obj_index_position`: byte position for the start of the obj index. +* `log_index_position`: byte position for the start of the log index. + +The size of the footer is 68 bytes for version 1, and 72 bytes for +version 2. + +Reading the footer +++++++++++++++++++ + +Readers must first read the file start to determine the version +number. Then they seek to `file_length - FOOTER_LENGTH` to access the +footer. A trusted external source (such as `stat(2)`) is necessary to +obtain `file_length`. When reading the footer, readers must verify: + +* 4-byte magic is correct +* 1-byte version number is recognized +* 4-byte CRC-32 matches the other 64 bytes (including magic, and +version) + +Once verified, the other fields of the footer can be accessed. + +Empty tables +++++++++++++ + +A reftable may be empty. In this case, the file starts with a header +and is immediately followed by a footer. + +Binary search +^^^^^^^^^^^^^ + +Binary search within a block is supported by the `restart_offset` fields +at the end of the block. Readers can binary search through the restart +table to locate between which two restart points the sought reference or +key should appear. + +Each record identified by a `restart_offset` stores the complete key in +the `suffix` field of the record, making the compare operation during +binary search straightforward. + +Once a restart point lexicographically before the sought reference has +been identified, readers can linearly scan through the following record +entries to locate the sought record, terminating if the current record +sorts after (and therefore the sought key is not present). + +Restart point selection ++++++++++++++++++++++++ + +Writers determine the restart points at file creation. The process is +arbitrary, but every 16 or 64 records is recommended. Every 16 may be +more suitable for smaller block sizes (4k or 8k), every 64 for larger +block sizes (64k). + +More frequent restart points reduces prefix compression and increases +space consumed by the restart table, both of which increase file size. + +Less frequent restart points makes prefix compression more effective, +decreasing overall file size, with increased penalties for readers +walking through more records after the binary search step. + +A maximum of `65535` restart points per block is supported. + +Considerations +~~~~~~~~~~~~~~ + +Lightweight refs dominate +^^^^^^^^^^^^^^^^^^^^^^^^^ + +The reftable format assumes the vast majority of references are single +object names valued with common prefixes, such as Gerrit Code Review's +`refs/changes/` namespace, GitHub's `refs/pulls/` namespace, or many +lightweight tags in the `refs/tags/` namespace. + +Annotated tags storing the peeled object cost an additional object name per +reference. + +Low overhead +^^^^^^^^^^^^ + +A reftable with very few references (e.g. git.git with 5 heads) is 269 +bytes for reftable, vs. 332 bytes for packed-refs. This supports +reftable scaling down for transaction logs (below). + +Block size +^^^^^^^^^^ + +For a Gerrit Code Review type repository with many change refs, larger +block sizes (64 KiB) and less frequent restart points (every 64) yield +better compression due to more references within the block compressing +against the prior reference. + +Larger block sizes reduce the index size, as the reftable will require +fewer blocks to store the same number of references. + +Minimal disk seeks +^^^^^^^^^^^^^^^^^^ + +Assuming the index block has been loaded into memory, binary searching +for any single reference requires exactly 1 disk seek to load the +containing block. + +Scans and lookups dominate +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Scanning all references and lookup by name (or namespace such as +`refs/heads/`) are the most common activities performed on repositories. +Object names are stored directly with references to optimize this use case. + +Logs are infrequently read +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Logs are infrequently accessed, but can be large. Deflating log blocks +saves disk space, with some increased penalty at read time. + +Logs are stored in an isolated section from refs, reducing the burden on +reference readers that want to ignore logs. Further, historical logs can +be isolated into log-only files. + +Logs are read backwards +^^^^^^^^^^^^^^^^^^^^^^^ + +Logs are frequently accessed backwards (most recent N records for master +to answer `master@{4}`), so log records are grouped by reference, and +sorted descending by update index. + +Repository format +~~~~~~~~~~~~~~~~~ + +Version 1 +^^^^^^^^^ + +A repository must set its `$GIT_DIR/config` to configure reftable: + +.... +[core] + repositoryformatversion = 1 +[extensions] + refStorage = reftable +.... + +Layout +^^^^^^ + +A collection of reftable files are stored in the `$GIT_DIR/reftable/` +directory: + +.... +00000001-00000001.log +00000002-00000002.ref +00000003-00000003.ref +.... + +where reftable files are named by a unique name such as produced by the +function `${min_update_index}-${max_update_index}.ref`. + +Log-only files use the `.log` extension, while ref-only and mixed ref +and log files use `.ref`. extension. + +The stack ordering file is `$GIT_DIR/reftable/tables.list` and lists the +current files, one per line, in order, from oldest (base) to newest +(most recent): + +.... +$ cat .git/reftable/tables.list +00000001-00000001.log +00000002-00000002.ref +00000003-00000003.ref +.... + +Readers must read `$GIT_DIR/reftable/tables.list` to determine which +files are relevant right now, and search through the stack in reverse +order (last reftable is examined first). + +Reftable files not listed in `tables.list` may be new (and about to be +added to the stack by the active writer), or ancient and ready to be +pruned. + +Backward compatibility +^^^^^^^^^^^^^^^^^^^^^^ + +Older clients should continue to recognize the directory as a git +repository so they don't look for an enclosing repository in parent +directories. To this end, a reftable-enabled repository must contain the +following dummy files + +* `.git/HEAD`, a regular file containing `ref: refs/heads/.invalid`. +* `.git/refs/`, a directory +* `.git/refs/heads`, a regular file + +Readers +^^^^^^^ + +Readers can obtain a consistent snapshot of the reference space by +following: + +1. Open and read the `tables.list` file. +2. Open each of the reftable files that it mentions. +3. If any of the files is missing, goto 1. +4. Read from the now-open files as long as necessary. + +Update transactions +^^^^^^^^^^^^^^^^^^^ + +Although reftables are immutable, mutations are supported by writing a +new reftable and atomically appending it to the stack: + +1. Acquire `tables.list.lock`. +2. Read `tables.list` to determine current reftables. +3. Select `update_index` to be most recent file's +`max_update_index + 1`. +4. Prepare temp reftable `tmp_XXXXXX`, including log entries. +5. Rename `tmp_XXXXXX` to `${update_index}-${update_index}.ref`. +6. Copy `tables.list` to `tables.list.lock`, appending file from (5). +7. Rename `tables.list.lock` to `tables.list`. + +During step 4 the new file's `min_update_index` and `max_update_index` +are both set to the `update_index` selected by step 3. All log records +for the transaction use the same `update_index` in their keys. This +enables later correlation of which references were updated by the same +transaction. + +Because a single `tables.list.lock` file is used to manage locking, the +repository is single-threaded for writers. Writers may have to busy-spin +(with backoff) around creating `tables.list.lock`, for up to an +acceptable wait period, aborting if the repository is too busy to +mutate. Application servers wrapped around repositories (e.g. Gerrit +Code Review) can layer their own lock/wait queue to improve fairness to +writers. + +Reference deletions +^^^^^^^^^^^^^^^^^^^ + +Deletion of any reference can be explicitly stored by setting the `type` +to `0x0` and omitting the `value` field of the `ref_record`. This serves +as a tombstone, overriding any assertions about the existence of the +reference from earlier files in the stack. + +Compaction +^^^^^^^^^^ + +A partial stack of reftables can be compacted by merging references +using a straightforward merge join across reftables, selecting the most +recent value for output, and omitting deleted references that do not +appear in remaining, lower reftables. + +A compacted reftable should set its `min_update_index` to the smallest +of the input files' `min_update_index`, and its `max_update_index` +likewise to the largest input `max_update_index`. + +For sake of illustration, assume the stack currently consists of +reftable files (from oldest to newest): A, B, C, and D. The compactor is +going to compact B and C, leaving A and D alone. + +1. Obtain lock `tables.list.lock` and read the `tables.list` file. +2. Obtain locks `B.lock` and `C.lock`. Ownership of these locks +prevents other processes from trying to compact these files. +3. Release `tables.list.lock`. +4. Compact `B` and `C` into a temp file +`${min_update_index}-${max_update_index}_XXXXXX`. +5. Reacquire lock `tables.list.lock`. +6. Verify that `B` and `C` are still in the stack, in that order. This +should always be the case, assuming that other processes are adhering to +the locking protocol. +7. Rename `${min_update_index}-${max_update_index}_XXXXXX` to +`${min_update_index}-${max_update_index}.ref`. +8. Write the new stack to `tables.list.lock`, replacing `B` and `C` +with the file from (4). +9. Rename `tables.list.lock` to `tables.list`. +10. Delete `B` and `C`, perhaps after a short sleep to avoid forcing +readers to backtrack. + +This strategy permits compactions to proceed independently of updates. + +Each reftable (compacted or not) is uniquely identified by its name, so +open reftables can be cached by their name. + +Alternatives considered +~~~~~~~~~~~~~~~~~~~~~~~ + +bzip packed-refs +^^^^^^^^^^^^^^^^ + +`bzip2` can significantly shrink a large packed-refs file (e.g. 62 MiB +compresses to 23 MiB, 37%). However the bzip format does not support +random access to a single reference. Readers must inflate and discard +while performing a linear scan. + +Breaking packed-refs into chunks (individually compressing each chunk) +would reduce the amount of data a reader must inflate, but still leaves +the problem of indexing chunks to support readers efficiently locating +the correct chunk. + +Given the compression achieved by reftable's encoding, it does not seem +necessary to add the complexity of bzip/gzip/zlib. + +Michael Haggerty's alternate format +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Michael Haggerty proposed +link:https://lore.kernel.org/git/CAMy9T_HCnyc1g8XWOOWhe7nN0aEFyyBskV2aOMb_fe%2BwGvEJ7A%40mail.gmail.com/[an +alternate] format to reftable on the Git mailing list. This format uses +smaller chunks, without the restart table, and avoids block alignment +with padding. Reflog entries immediately follow each ref, and are thus +interleaved between refs. + +Performance testing indicates reftable is faster for lookups (51% +faster, 11.2 usec vs. 5.4 usec), although reftable produces a slightly +larger file (+ ~3.2%, 28.3M vs 29.2M): + +[cols=">,>,>,>",options="header",] +|===================================== +|format |size |seek cold |seek hot +|mh-alt |28.3 M |23.4 usec |11.2 usec +|reftable |29.2 M |19.9 usec |5.4 usec +|===================================== + +JGit Ketch RefTree +^^^^^^^^^^^^^^^^^^ + +https://dev.eclipse.org/mhonarc/lists/jgit-dev/msg03073.html[JGit Ketch] +proposed +link:https://lore.kernel.org/git/CAJo%3DhJvnAPNAdDcAAwAvU9C4RVeQdoS3Ev9WTguHx4fD0V_nOg%40mail.gmail.com/[RefTree], +an encoding of references inside Git tree objects stored as part of the +repository's object database. + +The RefTree format adds additional load on the object database storage +layer (more loose objects, more objects in packs), and relies heavily on +the packer's delta compression to save space. Namespaces which are flat +(e.g. thousands of tags in refs/tags) initially create very large loose +objects, and so RefTree does not address the problem of copying many +references to modify a handful. + +Flat namespaces are not efficiently searchable in RefTree, as tree +objects in canonical formatting cannot be binary searched. This fails +the need to handle a large number of references in a single namespace, +such as GitHub's `refs/pulls`, or a project with many tags. + +LMDB +^^^^ + +David Turner proposed +https://lore.kernel.org/git/1455772670-21142-26-git-send-email-dturner@twopensource.com/[using +LMDB], as LMDB is lightweight (64k of runtime code) and GPL-compatible +license. + +A downside of LMDB is its reliance on a single C implementation. This +makes embedding inside JGit (a popular reimplementation of Git) +difficult, and hoisting onto virtual storage (for JGit DFS) virtually +impossible. + +A common format that can be supported by all major Git implementations +(git-core, JGit, libgit2) is strongly preferred. diff --git a/Documentation/technical/repository-version.txt b/Documentation/technical/repository-version.txt new file mode 100644 index 0000000000..7844ef30ff --- /dev/null +++ b/Documentation/technical/repository-version.txt @@ -0,0 +1,102 @@ +== 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/Documentation/technical/rerere.txt b/Documentation/technical/rerere.txt new file mode 100644 index 0000000000..af5f9fc24f --- /dev/null +++ b/Documentation/technical/rerere.txt @@ -0,0 +1,186 @@ +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 became 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/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt index 5183b15422..01dedfe9ff 100644 --- a/Documentation/technical/shallow.txt +++ b/Documentation/technical/shallow.txt @@ -8,20 +8,22 @@ repo, and therefore grafts are introduced pretending that these commits have no parents. ********************************************************* -The basic idea is to write the SHA-1s of shallow commits into -$GIT_DIR/shallow, and handle its contents like the contents -of $GIT_DIR/info/grafts (with the difference that shallow -cannot contain parent information). - -This information is stored in a new file instead of grafts, or -even the config, since the user should not touch that file -at all (even throughout development of the shallow clone, it -was never manually edited!). +$GIT_DIR/shallow lists commit object names and tells Git to +pretend as if they are root commits (e.g. "git log" traversal +stops after showing them; "git fsck" does not complain saying +the commits listed on their "parent" lines do not exist). Each line contains exactly one SHA-1. When read, a commit_graft will be constructed, which has nr_parent < 0 to make it easier to discern from user provided grafts. +Note that the shallow feature could not be changed easily to +use replace refs: a commit containing a `mergetag` is not allowed +to be replaced, not even by a root commit. Such a commit can be +made shallow, though. Also, having a `shallow` file explicitly +listing all the commits made shallow makes it a *lot* easier to +do shallow-specific things such as to deepen the history. + Since fsck-objects relies on the library to read the objects, it honours shallow commits automatically. diff --git a/Documentation/technical/signature-format.txt b/Documentation/technical/signature-format.txt new file mode 100644 index 0000000000..2c9406a56a --- /dev/null +++ b/Documentation/technical/signature-format.txt @@ -0,0 +1,186 @@ +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/Documentation/technical/trivial-merge.txt b/Documentation/technical/trivial-merge.txt index c79d4a7c47..1f1c33d0da 100644 --- a/Documentation/technical/trivial-merge.txt +++ b/Documentation/technical/trivial-merge.txt @@ -32,7 +32,7 @@ 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. +and not up to date. Entries marked '+' have stat information. Spaces marked '*' don't affect the result. @@ -65,7 +65,7 @@ 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. +up to date. *empty* means that the tree must not have a directory-file conflict with the entry. diff --git a/Documentation/texi.xsl b/Documentation/texi.xsl new file mode 100644 index 0000000000..0f8ff07eca --- /dev/null +++ b/Documentation/texi.xsl @@ -0,0 +1,26 @@ +<!-- 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/Documentation/trace2-target-values.txt b/Documentation/trace2-target-values.txt new file mode 100644 index 0000000000..3985b6d3c2 --- /dev/null +++ b/Documentation/trace2-target-values.txt @@ -0,0 +1,12 @@ +-- +* `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. If the target +already exists and is a directory, the traces will be written to files (one +per process) underneath the given directory. +* `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/Documentation/transfer-data-leaks.txt b/Documentation/transfer-data-leaks.txt new file mode 100644 index 0000000000..914bacc39e --- /dev/null +++ b/Documentation/transfer-data-leaks.txt @@ -0,0 +1,30 @@ +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/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt index 282758e768..bd184cd653 100644 --- a/Documentation/urls-remotes.txt +++ b/Documentation/urls-remotes.txt @@ -36,7 +36,7 @@ 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 diff --git a/Documentation/urls.txt b/Documentation/urls.txt index 9ccb24677e..1c229d7581 100644 --- a/Documentation/urls.txt +++ b/Documentation/urls.txt @@ -7,9 +7,8 @@ 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 and rsync can be used for fetching -and pushing, but these are inefficient and deprecated; do not use -them). +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. @@ -20,7 +19,6 @@ The following syntaxes may be used with them: - 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/ -- rsync://host.xz/path/to/repo.git/ An alternative scp-like syntax may also be used with the ssh protocol: @@ -55,6 +53,9 @@ These two syntaxes are mostly equivalent, except the former implies --local option. endif::git-clone[] +'git clone', 'git fetch' and 'git pull', but not 'git push', will also +accept a suitable bundle file. See linkgit:git-bundle[1]. + 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 @@ -64,7 +65,7 @@ may be used: 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[1] for details. +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 diff --git a/Documentation/user-manual.conf b/Documentation/user-manual.conf index d87294de2f..0148f126dc 100644 --- a/Documentation/user-manual.conf +++ b/Documentation/user-manual.conf @@ -9,13 +9,3 @@ 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/Documentation/user-manual.txt b/Documentation/user-manual.txt index cbb01a1ea2..fd480b8645 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1,5 +1,4 @@ -Git User Manual -_______________ += Git User Manual Git is a fast distributed revision control system. @@ -41,12 +40,10 @@ complete. [[repositories-and-branches]] -Repositories and Branches -========================= +== Repositories and Branches [[how-to-get-a-git-repository]] -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. @@ -73,8 +70,7 @@ 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 -------------------------------------------------- +=== 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 @@ -122,10 +118,10 @@ 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-checkout[1]: +out using linkgit:git-switch[1]: ------------------------------------------------ -$ git checkout -b new v2.6.13 +$ git switch -c new v2.6.13 ------------------------------------------------ The working directory then reflects the contents that the project had @@ -151,8 +147,7 @@ with no way to find the history it used to point to; so use this command carefully. [[understanding-commits]] -Understanding History: 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 @@ -202,8 +197,7 @@ 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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. @@ -227,8 +221,7 @@ 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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 @@ -247,8 +240,7 @@ 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? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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 @@ -261,8 +253,7 @@ However, when no confusion will result, we often just use the term "branch" both for branches and for branch heads. [[manipulating-branches]] -Manipulating branches ---------------------- +=== Manipulating branches Creating, deleting, and modifying branches is quick and easy; here's a summary of the commands: @@ -282,10 +273,10 @@ a summary of the commands: this command will fail with a warning. `git branch -D <branch>`:: delete the branch `<branch>` irrespective of its merged status. -`git checkout <branch>`:: +`git switch <branch>`:: make the current branch `<branch>`, updating the working directory to reflect the version referenced by `<branch>`. -`git checkout -b <new> <start-point>`:: +`git switch -c <new> <start-point>`:: create a new branch `<new>` referencing `<start-point>`, and check it out. @@ -299,27 +290,26 @@ ref: refs/heads/master ------------------------------------------------ [[detached-head]] -Examining an old version without creating a new branch ------------------------------------------------------- +=== Examining an old version without creating a new branch -The `git checkout` command normally expects a branch head, but will also -accept an arbitrary commit; for example, you can check out the commit -referenced by a tag: +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 checkout v2.6.17 +$ 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 checkout. +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 -b with the checkout command again. Example: +do so (now or later) by using -c with the switch command again. Example: - git checkout -b new_branch_name + git switch -c new_branch_name -HEAD is now at 427abfa... Linux v2.6.17 +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, @@ -340,8 +330,7 @@ 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 -------------------------------------------- +=== 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 @@ -358,7 +347,7 @@ $ git branch -r origin/man origin/master origin/next - origin/pu + origin/seen origin/todo ------------------------------------------------ @@ -373,7 +362,7 @@ 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 checkout -b my-todo-copy origin/todo +$ git switch -c my-todo-copy origin/todo ------------------------------------------------ You can also check out `origin/todo` directly to examine it or @@ -383,8 +372,7 @@ 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 -------------------------------------------- +=== 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 @@ -413,21 +401,18 @@ 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 ------------------------------------- +=== Updating a repository with git fetch -Eventually the developer cloned from will do additional work in her -repository, creating new commits and advancing the branches to point -at the new commits. +After you clone a repository and commit a few changes of your own, you +may wish to check the original repository for updates. -The command `git fetch`, with no arguments, will update all of the -remote-tracking branches to the latest version found in her +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 ------------------------------------------ +=== Fetching branches from other repositories You can also track branches from repositories other than the one you cloned from, using linkgit:git-remote[1]: @@ -475,8 +460,7 @@ text editor. (See the "CONFIGURATION FILE" section of linkgit:git-config[1] for details.) [[exploring-git-history]] -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 @@ -490,8 +474,7 @@ 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 --------------------------------------- +=== 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 @@ -509,7 +492,7 @@ Bisecting: 3537 revisions left to test after this 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 +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: @@ -550,14 +533,14 @@ says "bisect". Choose a safe-looking commit nearby, note its commit id, and check it out with: ------------------------------------------------- -$ git reset --hard fb47ddb2db... +$ 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 +fb47ddb2db`, you might just want to tell Git that you want to skip the current commit: ------------------------------------------------- @@ -573,8 +556,7 @@ linkgit:git-bisect[1] for more information about this and other `git bisect` features. [[naming-commits]] -Naming commits --------------- +=== Naming commits We have seen several ways of naming commits already: @@ -638,8 +620,7 @@ e05db0fd4f31dde7005f075a84f96b360d05984b ------------------------------------------------- [[creating-tags]] -Creating tags -------------- +=== Creating tags We can also create a tag to refer to a particular commit; after running @@ -656,8 +637,7 @@ should create a tag object instead; see the linkgit:git-tag[1] man page for details. [[browsing-revisions]] -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 @@ -698,8 +678,7 @@ multiple independent lines of development, the particular order that commits are listed in may be somewhat arbitrary. [[generating-diffs]] -Generating diffs ----------------- +=== Generating diffs You can generate diffs between any two versions using linkgit:git-diff[1]: @@ -727,8 +706,7 @@ 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 -------------------------- +=== 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 @@ -743,12 +721,10 @@ 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 --------- +=== Examples [[counting-commits-on-a-branch]] -Counting the number of 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`: @@ -766,8 +742,7 @@ $ git rev-list origin..mybranch | wc -l ------------------------------------------------- [[checking-for-equal-branches]] -Check whether two branches point at the same history -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== Check whether two branches point at the same history Suppose you want to check whether two branches point at the same point in history. @@ -799,8 +774,7 @@ $ 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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 @@ -884,8 +858,7 @@ 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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. @@ -932,8 +905,7 @@ $ gitk $( git show-ref --heads ) --not $( git show-ref --tags ) syntax such as `--not`.) [[making-a-release]] -Creating a changelog and tarball for a software 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: @@ -984,8 +956,7 @@ 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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 @@ -1001,12 +972,10 @@ 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 -=================== +== Developing with Git [[telling-git-your-name]] -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]: @@ -1031,8 +1000,7 @@ also edit it with your favorite editor. [[creating-a-new-repository]] -Creating a new repository -------------------------- +=== Creating a new repository Creating a new repository from scratch is very easy: @@ -1053,8 +1021,7 @@ $ git commit ------------------------------------------------- [[how-to-make-a-commit]] -How to make a commit --------------------- +=== How to make a commit Creating a new commit takes three steps: @@ -1149,8 +1116,7 @@ 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 ------------------------------ +=== 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 @@ -1163,8 +1129,7 @@ rest of the commit in the body. [[ignoring-files]] -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 @@ -1201,13 +1166,12 @@ 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. +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 ------------- +=== How to merge You can rejoin two diverging branches of development using linkgit:git-merge[1]: @@ -1255,8 +1219,7 @@ 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 ------------------ +=== 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 @@ -1298,8 +1261,7 @@ 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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 @@ -1402,14 +1364,13 @@ 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 ---------------- +=== 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 reset --hard HEAD +$ git merge --abort ------------------------------------------------- Or, if you've already committed the merge that you want to throw away, @@ -1424,30 +1385,28 @@ itself have been merged into another branch, as doing so may confuse further merges. [[fast-forwards]] -Fast-forward merges -------------------- +=== 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 a descendant of the other--so every -commit present in the one is already contained in the other--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. +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 ---------------- +=== 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 reset --hard HEAD +$ git restore --staged --worktree :/ ------------------------------------------------- If you make a commit that you later wish you hadn't, there are two @@ -1464,8 +1423,7 @@ fundamentally different ways to fix the problem: a branch that has had its history changed. [[reverting-a-commit]] -Fixing a mistake with a new 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 @@ -1491,8 +1449,7 @@ 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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 @@ -1519,17 +1476,14 @@ 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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-checkout[1]. We've used `git checkout` before to switch -branches, but it has quite different behavior if it is given a path -name: the command +linkgit:git-restore[1]. The command ------------------------------------------------- -$ git checkout HEAD^ path/to/file +$ git restore --source=HEAD^ path/to/file ------------------------------------------------- replaces path/to/file by the contents it had in the commit HEAD^, and @@ -1546,8 +1500,7 @@ $ git show HEAD^:path/to/file which will display the given version of the file. [[interrupted-work]] -Temporarily setting aside work in progress -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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 @@ -1557,7 +1510,7 @@ so on a different branch and then coming back), unstash the work-in-progress changes. ------------------------------------------------ -$ git stash save "work in progress for foo feature" +$ git stash push -m "work in progress for foo feature" ------------------------------------------------ This command will save your changes away to the `stash`, and @@ -1578,8 +1531,7 @@ $ git stash pop [[ensuring-good-performance]] -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 @@ -1590,12 +1542,10 @@ to avoid automatic compression kicking in when it is not convenient. [[ensuring-reliability]] -Ensuring reliability --------------------- +=== Ensuring reliability [[checking-for-corruption]] -Checking the repository 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 @@ -1621,12 +1571,10 @@ You can run `git fsck --no-dangling` to suppress these messages, and still view real errors. [[recovering-lost-changes]] -Recovering lost changes -~~~~~~~~~~~~~~~~~~~~~~~ +==== Recovering lost changes [[reflogs]] -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 @@ -1673,8 +1621,7 @@ 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 -^^^^^^^^^^^^^^^^^^^^^^^^^^ +===== 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 @@ -1718,12 +1665,10 @@ dangling objects can arise in other situations. [[sharing-development]] -Sharing development with others -=============================== +== Sharing development with others [[getting-updates-With-git-pull]] -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 @@ -1786,8 +1731,7 @@ $ git merge branch are roughly equivalent. [[submitting-patches]] -Submitting patches to a project -------------------------------- +=== 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: @@ -1811,12 +1755,11 @@ 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 how they -prefer such patches be handled. +Consult the mailing list for your project first to determine +their requirements for submitting patches. [[importing-patches]] -Importing patches to a project ------------------------------- +=== 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. @@ -1848,8 +1791,7 @@ the original mailbox, with authorship and commit log message each taken from the message containing each patch. [[public-repositories]] -Public Git 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 @@ -1889,21 +1831,22 @@ 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 +.... + 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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 @@ -1923,8 +1866,7 @@ public repository. You can use scp, rsync, or whatever is most convenient. [[exporting-via-git]] -Exporting a Git repository via the Git protocol -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== Exporting a Git repository via the Git protocol This is the preferred method. @@ -1945,8 +1887,7 @@ linkgit:git-daemon[1] man page for details. (See especially the examples section.) [[exporting-via-http]] -Exporting a git repository 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. @@ -1978,8 +1919,7 @@ 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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 @@ -2038,17 +1978,18 @@ See the explanations of the `remote.<name>.url`, linkgit:git-config[1] for details. [[forcing-push]] -What to do when a push fails -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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: ------------------------------------------------- -error: remote 'refs/heads/master' is not an ancestor of - local 'refs/heads/master'. - Maybe you are not up-to-date and need to pull first? -error: failed to push to 'ssh://yourserver.com/~you/proj.git' + ! [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: @@ -2091,8 +2032,7 @@ pull, or by a fetch followed by a rebase; see the linkgit:gitcvs-migration[7] for more. [[setting-up-a-shared-repository]] -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 @@ -2122,20 +2062,45 @@ advantages over the central shared repository: "out". [[setting-up-gitweb]] -Allowing web browsing of a repository -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== Allowing web browsing of a repository The gitweb cgi script provides users an easy way to browse your -project's files and history without having to install Git; see the file -gitweb/INSTALL in the Git source tree for instructions on setting it up. +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 --------- +=== Examples [[maintaining-topic-branches]] -Maintaining topic branches for a Linux subsystem maintainer -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== 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. @@ -2165,7 +2130,7 @@ $ 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 +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 @@ -2181,8 +2146,8 @@ $ git branch --track release origin/master These can be easily kept up to date using linkgit:git-pull[1]. ------------------------------------------------- -$ git checkout test && git pull -$ git checkout release && git pull +$ git switch test && git pull +$ git switch release && git pull ------------------------------------------------- Important note! If you have any local changes in these branches, then @@ -2234,7 +2199,7 @@ tested changes 2) help future bug hunters that use `git bisect` to find problems ------------------------------------------------- -$ git checkout -b speed-up-spinlocks v2.6.35 +$ git switch -c speed-up-spinlocks v2.6.35 ------------------------------------------------- Now you apply the patch(es), run some tests, and commit the change(s). If @@ -2249,19 +2214,19 @@ 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 checkout test && git merge speed-up-spinlocks +$ 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. -Some time later when enough time has passed and testing done, you can pull the +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 checkout release && git merge speed-up-spinlocks +$ git switch release && git merge speed-up-spinlocks ------------------------------------------------- After a while, you will have a number of branches, and despite the @@ -2431,8 +2396,7 @@ done [[cleaning-up-history]] -Rewriting history and maintaining patch series -============================================== +== 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 @@ -2442,8 +2406,7 @@ However, there is a situation in which it can be useful to violate this assumption. [[patch-series]] -Creating the perfect 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 @@ -2475,14 +2438,13 @@ 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 --------------------------------------------------- +=== 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 checkout -b mywork origin +$ git switch -c mywork origin $ vi file.txt $ git commit $ vi otherfile.txt @@ -2522,7 +2484,7 @@ commits without any merges, you may instead choose to use linkgit:git-rebase[1]: ------------------------------------------------- -$ git checkout mywork +$ git switch mywork $ git rebase origin ------------------------------------------------- @@ -2563,8 +2525,7 @@ the rebase. See <<interactive-rebase>> for details, and <<reordering-patch-series>> for alternatives. [[rewriting-one-commit]] -Rewriting a single commit -------------------------- +=== Rewriting a single commit We saw in <<fixing-a-mistake-by-rewriting-history>> that you can replace the most recent commit using @@ -2582,8 +2543,7 @@ 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 -------------------------------------------- +=== 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 @@ -2602,8 +2562,7 @@ $ git am *.patch ------------------------------------------------- [[interactive-rebase]] -Using interactive rebases -------------------------- +=== 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 @@ -2660,16 +2619,14 @@ 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 ------------ +=== 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 -------------------------------- +=== 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 @@ -2717,8 +2674,7 @@ 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 ------------------------------------------------------------------------ +=== 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 @@ -2783,12 +2739,10 @@ linear by rebasing against the latest upstream version before publishing. [[advanced-branch-management]] -Advanced branch management -========================== +== Advanced branch management [[fetching-individual-branches]] -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 @@ -2816,8 +2770,7 @@ already have a branch named example-master, it will attempt to master branch. In more detail: [[fetch-fast-forwards]] -git fetch and 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 @@ -2854,8 +2807,7 @@ unless you've already created a reference of your own pointing to them. [[forcing-fetch]] -Forcing git fetch to do non-fast-forward updates ------------------------------------------------- +=== 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: @@ -2875,8 +2827,7 @@ 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 ------------------------------------- +=== 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 @@ -2927,8 +2878,7 @@ the refspec syntax. [[git-concepts]] -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 @@ -2938,8 +2888,7 @@ We start with the most important, the <<def_object_database,object database>> and the <<def_index,index>>. [[the-object-database]] -The Object Database -------------------- +=== The Object Database We already saw in <<understanding-commits>> that all commits are stored @@ -2983,8 +2932,7 @@ There are four different types of objects: "blob", "tree", "commit", and The object types in some more detail: [[commit-object]] -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 @@ -3036,8 +2984,7 @@ 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 -~~~~~~~~~~~ +==== 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 @@ -3076,8 +3023,7 @@ Note that the files all have mode 644 or 755: Git actually only pays attention to the executable bit. [[blob-object]] -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: @@ -3106,8 +3052,7 @@ sometimes be useful for browsing the contents of a tree that is not currently checked out. [[trust]] -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 @@ -3136,8 +3081,7 @@ like GPG/PGP. To assist in this, Git also provides the tag object... [[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 @@ -3166,8 +3110,7 @@ objects. (Note that linkgit:git-tag[1] can also be used to create references whose names begin with `refs/tags/`). [[pack-files]] -How Git stores objects efficiently: 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`). @@ -3225,8 +3168,7 @@ 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 -~~~~~~~~~~~~~~~~ +==== Dangling objects The linkgit:git-fsck[1] command will sometimes complain about dangling objects. They are not a problem. @@ -3306,8 +3248,7 @@ don't want to do that while the filesystem is mounted. accesses to a repository but you might receive confusing or scary messages.) [[recovering-from-repository-corruption]] -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 @@ -3386,7 +3327,7 @@ commit abc Author: Date: ... -:100644 100644 4b9458b... newsha... M somedirectory/myfile +:100644 100644 4b9458b newsha M somedirectory/myfile commit xyz @@ -3394,7 +3335,7 @@ Author: Date: ... -:100644 100644 oldsha... 4b9458b... M somedirectory/myfile +:100644 100644 oldsha 4b9458b M somedirectory/myfile ------------------------------------------------ This tells you that the immediately following version of the file was @@ -3419,13 +3360,12 @@ and your repository is good again! $ git log --raw --all ------------------------------------------------ -and just looked for the sha of the missing object (4b9458b..) in that +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 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 @@ -3483,8 +3423,7 @@ 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 -========== +== Submodules Large projects are often composed of smaller, self-contained modules. For example, an embedded Linux distribution's source tree would include every @@ -3638,13 +3577,13 @@ change within the submodule, and then update the superproject to reference the new commit: ------------------------------------------------- -$ git checkout master +$ git switch master ------------------------------------------------- or ------------------------------------------------- -$ git checkout -b fix-up +$ git switch -c fix-up ------------------------------------------------- then @@ -3670,8 +3609,8 @@ $ git push You have to run `git submodule update` after `git pull` if you want to update submodules, too. -Pitfalls with submodules ------------------------- +[[pitfalls-with-submodules]] +=== 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, @@ -3740,8 +3679,7 @@ 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 -======================== +== 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 @@ -3749,8 +3687,7 @@ be useful when doing unusual things with Git, or just as a way to understand its inner workings. [[object-manipulation]] -Object access and 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. @@ -3767,11 +3704,10 @@ verified by linkgit:git-verify-tag[1], though it is normally simpler to use linkgit:git-tag[1] for both. [[the-workflow]] -The Workflow ------------- +=== The Workflow -High-level operations such as linkgit:git-commit[1], -linkgit:git-checkout[1] and linkgit:git-reset[1] work by moving data +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. @@ -3783,8 +3719,7 @@ the database or the working directory. Thus there are four main combinations: [[working-directory-to-index]] -working directory -> index -~~~~~~~~~~~~~~~~~~~~~~~~~~ +==== working directory -> index The linkgit:git-update-index[1] command updates the index with information from the working directory. You generally update the @@ -3795,7 +3730,7 @@ like so: $ git update-index filename ------------------------------------------------- -but to avoid common mistakes with filename globbing etc, the command +but to avoid common mistakes with filename globbing etc., the command will not normally add totally new entries or remove old entries, i.e. it will normally just update existing cache entries. @@ -3820,8 +3755,7 @@ The previously introduced linkgit:git-add[1] is just a wrapper for linkgit:git-update-index[1]. [[index-to-object-database]] -index -> object database -~~~~~~~~~~~~~~~~~~~~~~~~ +==== index -> object database You write your current index file to a "tree" object with the program @@ -3836,8 +3770,7 @@ use that tree to re-generate the index at any time by going in the other direction: [[object-database-to-index]] -object database -> 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 @@ -3853,8 +3786,7 @@ earlier. However, that is only your 'index' file: your working directory contents have not been modified. [[index-to-working-directory]] -index -> 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 @@ -3883,8 +3815,7 @@ 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 -~~~~~~~~~~~~~~~~~~~~~ +==== 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 @@ -3958,8 +3889,7 @@ Here is a picture that illustrates how various pieces fit together: [[examining-the-data]] -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 @@ -3994,8 +3924,7 @@ $ git cat-file commit HEAD to see what the top commit was. [[merging-multiple-trees]] -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 @@ -4045,8 +3974,7 @@ index file, and you can just write the result out with [[merging-multiple-trees-2]] -Merging multiple trees, continued ---------------------------------- +=== 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 @@ -4074,7 +4002,7 @@ 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` nor `$target`, or if the file changed +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 @@ -4084,9 +4012,9 @@ 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 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 ------------------------------------------------ @@ -4116,15 +4044,13 @@ $ 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 -=========== +== Hacking Git This chapter covers internal details of the Git implementation which probably only Git developers need to understand. [[object-details]] -Object storage format ---------------------- +=== 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 @@ -4154,8 +4080,7 @@ 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 -------------------------------------- +=== 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 @@ -4164,7 +4089,7 @@ start. A good place to start is with the contents of the initial commit, with: ---------------------------------------------------- -$ git checkout e83c5163 +$ git switch --detach e83c5163 ---------------------------------------------------- The initial revision lays the foundation for almost everything Git has @@ -4231,9 +4156,9 @@ Most of what `git rev-list` did is contained in `revision.c` and 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 +`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 +`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()`. @@ -4344,7 +4269,7 @@ $ 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 see that it is in commit 18449ab0. Now just copy this object name, and paste it into the command line ------------------- @@ -4364,21 +4289,22 @@ You see, Git is actually the best tool to find out about the source of Git itself! [[glossary]] -Git Glossary -============ +== Git Glossary + +[[git-explained]] +=== Git explained include::glossary-content.txt[] [[git-quick-start]] -Appendix A: Git Quick Reference -=============================== +[appendix] +== 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 -------------------------- +=== Creating a new repository From a tarball: @@ -4399,14 +4325,13 @@ $ cd project ----------------------------------------------- [[managing-branches]] -Managing branches ------------------ +=== Managing branches ----------------------------------------------- -$ git branch # list all local branches in this repo -$ git checkout test # switch working directory to branch "test" -$ git branch new # create branch "new" starting at current HEAD -$ git branch -d new # delete branch "new" +$ 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: @@ -4422,7 +4347,7 @@ $ git branch new test~10 # ten commits before tip of branch "test" Create and switch to a new branch at the same time: ----------------------------------------------- -$ git checkout -b new v2.6.15 +$ git switch -c new v2.6.15 ----------------------------------------------- Update and examine branches from the repository you cloned from: @@ -4433,7 +4358,7 @@ $ git branch -r # list origin/master origin/next ... -$ git checkout -b masterwork origin/master +$ git switch -c masterwork origin/master ----------------------------------------------- Fetch a branch from a different repository, and give it a new @@ -4464,8 +4389,7 @@ $ git branch -r # list all remote branches [[exploring-history]] -Exploring history ------------------ +=== Exploring history ----------------------------------------------- $ gitk # visualize and browse history @@ -4500,8 +4424,7 @@ $ git bisect bad # if this revision is bad. ----------------------------------------------- [[making-changes]] -Making changes --------------- +=== Making changes Make sure Git knows who to blame: @@ -4531,8 +4454,7 @@ $ git commit -a # use latest content of all tracked files ----------------------------------------------- [[merging]] -Merging -------- +=== Merging ----------------------------------------------- $ git merge test # merge branch "test" into the current branch @@ -4542,8 +4464,7 @@ $ git pull . test # equivalent to git merge test ----------------------------------------------- [[sharing-your-changes]] -Sharing your changes --------------------- +=== Sharing your changes Importing or exporting patches: @@ -4588,8 +4509,7 @@ $ git push example test ----------------------------------------------- [[repository-maintenance]] -Repository maintenance ----------------------- +=== Repository maintenance Check for corruption: @@ -4605,8 +4525,11 @@ $ git gc [[todo]] -Appendix B: Notes and todo list for this manual -=============================================== +[appendix] +== Notes and todo list for this manual + +[[todo-list]] +=== Todo list This is a work in progress. @@ -4637,27 +4560,19 @@ Scan email archives for other stuff left out Scan man pages to see if any assume more background than this manual provides. -Simplify beginning by suggesting disconnected head instead of -temporary branch creation? - 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. -Document shallow clones? See draft 1.5.0 release notes for some -documentation. - Add a section on working with other version control systems, including CVS, Subversion, and just imports of series of release tarballs. -More details on gitweb? - 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 + https://lore.kernel.org/git/Pine.LNX.4.64.0702272039540.12485@woody.linux-foundation.org/ + https://lore.kernel.org/git/Pine.LNX.4.64.0702141033400.3604@woody.linux-foundation.org/ |