diff options
Diffstat (limited to 'Documentation')
289 files changed, 8310 insertions, 2061 deletions
diff --git a/Documentation/BreakingChanges.txt b/Documentation/BreakingChanges.txt new file mode 100644 index 0000000000..27acff86db --- /dev/null +++ b/Documentation/BreakingChanges.txt @@ -0,0 +1,174 @@ += Upcoming breaking changes + +The Git project aims to ensure backwards compatibility to the best extent +possible. Minor releases will not break backwards compatibility unless there is +a very strong reason to do so, like for example a security vulnerability. + +Regardless of that, due to the age of the Git project, it is only natural to +accumulate a backlog of backwards-incompatible changes that will eventually be +required to keep the project aligned with a changing world. These changes fall +into several categories: + +* Changes to long established defaults. +* Concepts that have been replaced with a superior design. +* Concepts, commands, configuration or options that have been lacking in major + ways and that cannot be fixed and which will thus be removed without any + replacement. + +Explicitly not included in this list are fixes to minor bugs that may cause a +change in user-visible behavior. + +The Git project irregularly releases breaking versions that deliberately break +backwards compatibility with older versions. This is done to ensure that Git +remains relevant, safe and maintainable going forward. The release cadence of +breaking versions is typically measured in multiple years. We had the following +major breaking releases in the past: + +* Git 1.6.0, released in August 2008. +* Git 2.0, released in May 2014. + +We use <major>.<minor> release numbers these days, starting from Git 2.0. For +future releases, our plan is to increment <major> in the release number when we +make the next breaking release. Before Git 2.0, the release numbers were +1.<major>.<minor> with the intention to increment <major> for "usual" breaking +releases, reserving the jump to Git 2.0 for really large backward-compatibility +breaking changes. + +The intent of this document is to track upcoming deprecations for future +breaking releases. Furthermore, this document also tracks what will _not_ be +deprecated. This is done such that the outcome of discussions document both +when the discussion favors deprecation, but also when it rejects a deprecation. + +Items should have a clear summary of the reasons why we do or do not want to +make the described change that can be easily understood without having to read +the mailing list discussions. If there are alternatives to the changed feature, +those alternatives should be pointed out to our users. + +All items should be accompanied by references to relevant mailing list threads +where the deprecation was discussed. These references use message-IDs, which +can visited via + + https://lore.kernel.org/git/$message_id/ + +to see the message and its surrounding discussion. Such a reference is there to +make it easier for you to find how the project reached consensus on the +described item back then. + +This is a living document as the environment surrounding the project changes +over time. If circumstances change, an earlier decision to deprecate or change +something may need to be revisited from time to time. So do not take items on +this list to mean "it is settled, do not waste our time bringing it up again". + +== Procedure + +Discussing the desire to make breaking changes, declaring that breaking +changes are made at a certain version boundary, and recording these +decisions in this document, are necessary but not sufficient. +Because such changes are expected to be numerous, and the design and +implementation of them are expected to span over time, they have to +be deployable trivially at such a version boundary. + +The breaking changes MUST be guarded with the a compile-time switch, +WITH_BREAKING_CHANGES, to help this process. When built with it, +the resulting Git binary together with its documentation would +behave as if these breaking changes slated for the next big version +boundary are already in effect. We may also want to have a CI job +or two to exercise the work-in-progress version of Git with these +breaking changes. + + +== Git 3.0 + +The following subsections document upcoming breaking changes for Git 3.0. There +is no planned release date for this breaking version yet. The early +adopter configuration used for changes for this release is `feature.git3`. + +Proposed changes and removals only include items which are "ready" to be done. +In other words, this is not supposed to be a wishlist of features that should +be changed to or replaced in case the alternative was implemented already. + +=== Changes + +* The default hash function for new repositories will be changed from "sha1" + to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays + recommended against in FIPS 140-2 and similar certifications. Furthermore, + there are practical attacks on SHA-1 that weaken its cryptographic properties: ++ + ** The SHAppening (2015). The first demonstration of a practical attack + against SHA-1 with 2^57 operations. + ** SHAttered (2017). Generation of two valid PDF files with 2^63 operations. + ** Birthday-Near-Collision (2019). This attack allows for chosen prefix + attacks with 2^68 operations. + ** Shambles (2020). This attack allows for chosen prefix attacks with 2^63 + operations. ++ +While we have protections in place against known attacks, it is expected +that more attacks against SHA-1 will be found by future research. Paired +with the ever-growing capability of hardware, it is only a matter of time +before SHA-1 will be considered broken completely. We want to be prepared +and will thus change the default hash algorithm to "sha256" for newly +initialized repositories. ++ +An important requirement for this change is that the ecosystem is ready to +support the "sha256" object format. This includes popular Git libraries, +applications and forges. ++ +There is no plan to deprecate the "sha1" object format at this point in time. ++ +Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>, +<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>, +<CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com>. + +=== Removals + +* Support for grafting commits has long been superseded by git-replace(1). + Grafts are inferior to replacement refs: ++ + ** Grafts are a local-only mechanism and cannot be shared across + repositories. + ** Grafts can lead to hard-to-diagnose problems when transferring objects + between repositories. ++ +The grafting mechanism has been marked as outdated since e650d0643b (docs: mark +info/grafts as outdated, 2014-03-05) and will be removed. ++ +Cf. <20140304174806.GA11561@sigill.intra.peff.net>. + +* The git-pack-redundant(1) command can be used to remove redundant pack files. + The subcommand is unusably slow and the reason why nobody reports it as a + performance bug is suspected to be the absence of users. We have nominated + the command for removal and have started to emit a user-visible warning in + c3b58472be (pack-redundant: gauge the usage before proposing its removal, + 2020-08-25) whenever the command is executed. ++ +So far there was a single complaint about somebody still using the command, but +that complaint did not cause us to reverse course. On the contrary, we have +doubled down on the deprecation and starting with 4406522b76 (pack-redundant: +escalate deprecation warning to an error, 2023-03-23), the command dies unless +the user passes the `--i-still-use-this` option. ++ +There have not been any subsequent complaints, so this command will finally be +removed. ++ +Cf. <xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com>, + <CAKvOHKAFXQwt4D8yUCCkf_TQL79mYaJ=KAKhtpDNTvHJFuX1NA@mail.gmail.com>, + <20230323204047.GA9290@coredump.intra.peff.net>, + +== Superseded features that will not be deprecated + +Some features have gained newer replacements that aim to improve the design in +certain ways. The fact that there is a replacement does not automatically mean +that the old way of doing things will eventually be removed. This section tracks +those features with newer alternatives. + +* The features git-checkout(1) offers are covered by the pair of commands + git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still + widespread, and it is not expected that this will change anytime soon, all + three commands will stay. ++ +This decision may get revisited in case we ever figure out that there are +almost no users of any of the commands anymore. ++ +Cf. <xmqqttjazwwa.fsf@gitster.g>, +<xmqqleeubork.fsf@gitster.g>, +<112b6568912a6de6672bf5592c3a718e@manjaro.org>. diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 9495df835d..87904791cb 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, a few rough rules are: +Like other projects, we also have some guidelines for our 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." @@ -40,7 +40,7 @@ As for more concrete guidelines, just imitate the existing code contributing to). It is always preferable to match the _local_ convention. New code added to Git suite is expected to match the overall style of existing code. Modifications to existing -code is expected to match the style the surrounding code already +code are expected to match the style the surrounding code already uses (even if it doesn't match the overall style of existing code). But if you must have a list of rules, here are some language @@ -185,8 +185,51 @@ For shell scripts specifically (not exhaustive): - Even though "local" is not part of POSIX, we make heavy use of it in our test suite. We do not use it in scripted Porcelains, and - hopefully nobody starts using "local" before they are reimplemented - in C ;-) + hopefully nobody starts using "local" before all shells that matter + support it (notably, ksh from AT&T Research does not support it yet). + + - Some versions of shell do not understand "export variable=value", + so we write "variable=value" and then "export variable" on two + separate lines. + + - Some versions of dash have broken variable assignment when prefixed + with "local", "export", and "readonly", in that the value to be + assigned goes through field splitting at $IFS unless quoted. + + (incorrect) + local variable=$value + local variable=$(command args) + + (correct) + local variable="$value" + local variable="$(command args)" + + - The common construct + + VAR=VAL command args + + to temporarily set and export environment variable VAR only while + "command args" is running is handy, but this triggers an + unspecified behaviour according to POSIX when used for a command + that is not an external command (like shell functions). Indeed, + dash 0.5.10.2-6 on Ubuntu 20.04, /bin/sh on FreeBSD 13, and AT&T + ksh all make a temporary assignment without exporting the variable, + in such a case. As it does not work portably across shells, do not + use this syntax for shell functions. A common workaround is to do + an explicit export in a subshell, like so: + + (incorrect) + VAR=VAL func args + + (correct) + ( + VAR=VAL && + export VAR && + func args + ) + + but be careful that the effect "func" makes to the variables in the + current shell will be lost across the subshell boundary. - Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g. "\xc2\xa2") in printf format strings, since hexadecimal escape @@ -198,6 +241,16 @@ For C programs: - We use tabs to indent, and interpret tabs as taking up to 8 spaces. + - Nested C preprocessor directives are indented after the hash by one + space per nesting level. + + #if FOO + # include <foo.h> + # if BAR + # include <bar.h> + # endif + #endif + - We try to keep to at most 80 characters per line. - As a Git developer we assume you have a reasonably modern compiler @@ -205,6 +258,14 @@ For C programs: ensure your patch is clear of all compiler warnings we care about, by e.g. "echo DEVELOPER=1 >>config.mak". + - When using DEVELOPER=1 mode, you may see warnings from the compiler + like "error: unused parameter 'foo' [-Werror=unused-parameter]", + which indicates that a function ignores its argument. If the unused + parameter can't be removed (e.g., because the function is used as a + callback and has to match a certain interface), you can annotate + the individual parameters with the UNUSED (or MAYBE_UNUSED) + keyword, like "int foo UNUSED". + - We try to support a wide range of C compilers to compile Git with, including old ones. As of Git v2.35.0 Git requires C99 (we check "__STDC_VERSION__"). You should not use features from a newer C @@ -218,7 +279,7 @@ For C programs: . since around 2007 with 2b6854c863a, we have been using initializer elements which are not computable at load time. E.g.: - const char *args[] = {"constant", variable, NULL}; + const char *args[] = { "constant", variable, NULL }; . since early 2012 with e1327023ea, we have been using an enum definition whose last element is followed by a comma. This, like @@ -250,7 +311,9 @@ For C programs: v12.01, 2022-03-28). - Variables have to be declared at the beginning of the block, before - the first statement (i.e. -Wdeclaration-after-statement). + the first statement (i.e. -Wdeclaration-after-statement). It is + encouraged to have a blank line between the end of the declarations + and the first statement in the block. - NULL pointers shall be written as NULL, not as 0. @@ -270,6 +333,13 @@ For C programs: while( condition ) func (bar+1); + - A binary operator (other than ",") and ternary conditional "?:" + have a space on each side of the operator to separate it from its + operands. E.g. "A + 1", not "A+1". + + - A unary operator (other than "." and "->") have no space between it + and its operand. E.g. "(char *)ptr", not "(char *) ptr". + - 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: @@ -446,12 +516,41 @@ For C programs: detail. - The first #include in C files, except in platform specific compat/ - implementations and sha1dc/, must be either "git-compat-util.h" or - one of the approved headers that includes it first for you. (The - approved headers currently include "builtin.h", - "t/helper/test-tool.h", "xdiff/xinclude.h", or - "reftable/system.h"). You do not have to include more than one of - these. + implementations and sha1dc/, must be <git-compat-util.h>. This + header file insulates other header files and source files from + platform differences, like which system header files must be + included in what order, and what C preprocessor feature macros must + be defined to trigger certain features we expect out of the system. + A collorary to this is that C files should not directly include + system header files themselves. + + There are some exceptions, because certain group of files that + implement an API all have to include the same header file that + defines the API and it is convenient to include <git-compat-util.h> + there. Namely: + + - the implementation of the built-in commands in the "builtin/" + directory that include "builtin.h" for the cmd_foo() prototype + definition, + + - the test helper programs in the "t/helper/" directory that include + "t/helper/test-tool.h" for the cmd__foo() prototype definition, + + - the xdiff implementation in the "xdiff/" directory that includes + "xdiff/xinclude.h" for the xdiff machinery internals, + + - the unit test programs in "t/unit-tests/" directory that include + "t/unit-tests/test-lib.h" that gives them the unit-tests + framework, and + + - the source files that implement reftable in the "reftable/" + directory that include "reftable/system.h" for the reftable + internals, + + are allowed to assume that they do not have to include + <git-compat-util.h> themselves, as it is included as the first + '#include' in these header files. These headers must be the first + header file to be "#include"d in them, though. - A C file must directly include the header files that declare the functions and the types it uses, except for the functions and types @@ -486,11 +585,61 @@ For C programs: use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb" ./bin-wrappers/git log` (See `wrap-for-bin.sh`.) + - The primary data structure that a subsystem 'S' deals with is called + `struct S`. Functions that operate on `struct S` are named + `S_<verb>()` and should generally receive a pointer to `struct S` as + first parameter. E.g. + + struct strbuf; + + void strbuf_add(struct strbuf *buf, ...); + + void strbuf_reset(struct strbuf *buf); + + is preferred over: + + struct strbuf; + + void add_string(struct strbuf *buf, ...); + + void reset_strbuf(struct strbuf *buf); + + - There are several common idiomatic names for functions performing + specific tasks on a structure `S`: + + - `S_init()` initializes a structure without allocating the + structure itself. + + - `S_release()` releases a structure's contents without freeing the + structure. + + - `S_clear()` is equivalent to `S_release()` followed by `S_init()` + such that the structure is directly usable after clearing it. When + `S_clear()` is provided, `S_init()` shall not allocate resources + that need to be released again. + + - `S_free()` releases a structure's contents and frees the + structure. + + - Function names should be clear and descriptive, accurately reflecting + their purpose or behavior. Arbitrary suffixes that do not add meaningful + context can lead to confusion, particularly for newcomers to the codebase. + + Historically, the '_1' suffix has been used in situations where: + + - A function handles one element among a group that requires similar + processing. + - A recursive function has been separated from its setup phase. + + The '_1' suffix can be used as a concise way to indicate these specific + cases. However, it is recommended to find a more descriptive name wherever + possible to improve the readability and maintainability of the code. + For Perl programs: - Most of the C guidelines above apply. - - We try to support Perl 5.8 and later ("use Perl 5.008"). + - We try to support Perl 5.8.1 and later ("use Perl 5.008001"). - use strict and use warnings are strongly preferred. @@ -518,7 +667,7 @@ For Perl programs: For Python scripts: - - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/). + - We follow PEP-8 (https://peps.python.org/pep-0008/). - As a minimum, we aim to be compatible with Python 2.7. @@ -578,7 +727,7 @@ Externally Visible Names . 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. `-`), + formed by concatenating the words without punctuation marks (e.g. `-`), and are broken using bumpyCaps in documentation as a hint to the reader. @@ -612,15 +761,15 @@ Writing Documentation: - Prefer succinctness and matter-of-factly describing functionality in the abstract. E.g. - --short:: Emit output in the short-format. + `--short`:: Emit output in the short-format. and avoid something like these overly verbose alternatives: - --short:: Use this to emit output in the short-format. - --short:: You can use this to get output in the short-format. - --short:: A user who prefers shorter output could.... - --short:: Should a person and/or program want shorter output, he - she/they/it can... + `--short`:: Use this to emit output in the short-format. + `--short`:: You can use this to get output in the short-format. + `--short`:: A user who prefers shorter output could.... + `--short`:: Should a person and/or program want shorter output, he + she/they/it can... This practice often eliminates the need to involve human actors in your description, but it is a good practice regardless of the @@ -630,12 +779,12 @@ Writing Documentation: addressing the hypothetical user, and possibly "we" when discussing how the program might react to the user. E.g. - You can use this option instead of --xyz, but we might remove + You can use this option instead of `--xyz`, but we might remove support for it in future versions. while keeping in mind that you can probably be less verbose, e.g. - Use this instead of --xyz. This option might be removed in future + Use this instead of `--xyz`. This option might be removed in future versions. - If you still need to refer to an example person that is @@ -653,18 +802,72 @@ Writing Documentation: The same general rule as for code applies -- imitate the existing conventions. - A few commented examples follow to provide reference when writing or - modifying command usage strings and synopsis sections in the manual - pages: - Placeholders are spelled in lowercase and enclosed in angle brackets: - <file> - --sort=<key> - --abbrev[=<n>] +Markup: + + Literal parts (e.g. use of command-line options, command names, + branch names, URLs, pathnames (files and directories), configuration and + environment variables) must be typeset as verbatim (i.e. wrapped with + backticks): + `--pretty=oneline` + `git rev-list` + `remote.pushDefault` + `http://git.example.com` + `.git/config` + `GIT_DIR` + `HEAD` + `umask`(2) + + 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` + + Placeholders are spelled in lowercase and enclosed in + angle brackets surrounded by underscores: + _<file>_ + _<commit>_ If a placeholder has multiple words, they are separated by dashes: - <new-branch-name> - --template=<template-directory> + _<new-branch-name>_ + _<template-directory>_ + + When needed, use a distinctive identifier for placeholders, usually + made of a qualification and a type: + _<git-dir>_ + _<key-id>_ + + Git's Asciidoc processor has been tailored to treat backticked text + as complex synopsis. When literal and placeholders are mixed, you can + use the backtick notation which will take care of correctly typesetting + the content. + `--jobs <n>` + `--sort=<key>` + `<directory>/.git` + `remote.<name>.mirror` + `ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>` + +As a side effect, backquoted placeholders are correctly typeset, but +this style is not recommended. + +Synopsis Syntax + + The synopsis (a paragraph with [synopsis] attribute) is automatically + formatted by the toolchain and does not need typesetting. + + A few commented examples follow to provide reference when writing or + modifying command usage strings and synopsis sections in the manual + pages: Possibility of multiple occurrences is indicated by three dots: <file>... @@ -674,6 +877,9 @@ Writing Documentation: [<file>...] (Zero or more of <file>.) + An optional parameter needs to be typeset with unconstrained pairs + [<repository>] + --exec-path[=<path>] (Option with an optional argument. Note that the "=" is inside the brackets.) @@ -697,14 +903,14 @@ Writing Documentation: Don't: --track[=(direct | inherit)] 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>.) [(-p <parent>)...] (Any number of option -p, each with one <parent> argument.) - git remote set-head <name> (-a | -d | <branch>) + git remote set-head <name> (-a|-d|<branch>) (One and only one of "-a", "-d" or "<branch>" _must_ (no square brackets) be provided.) @@ -720,37 +926,6 @@ Writing Documentation: 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 diff --git a/Documentation/DecisionMaking.txt b/Documentation/DecisionMaking.txt new file mode 100644 index 0000000000..b43c472ae5 --- /dev/null +++ b/Documentation/DecisionMaking.txt @@ -0,0 +1,74 @@ +Decision-Making Process in the Git Project +========================================== + +Introduction +------------ +This document describes the current decision-making process in the Git +project. It is a descriptive rather than prescriptive doc; that is, we want to +describe how things work in practice rather than explicitly recommending any +particular process or changes to the current process. + +Here we document how the project makes decisions for discussions +(with or without patches), in scale larger than an individual patch +series (which is fully covered by the SubmittingPatches document). + + +Larger Discussions (with patches) +--------------------------------- +As with discussions on an individual patch series, starting a larger-scale +discussion often begins by sending a patch or series to the list. This might +take the form of an initial design doc, with implementation following in later +iterations of the series (for example, +link:https://lore.kernel.org/git/0169ce6fb9ccafc089b74ae406db0d1a8ff8ac65.1688165272.git.steadmon@google.com/[adding unit tests] or +link:https://lore.kernel.org/git/20200420235310.94493-1-emilyshaffer@google.com/[config-based hooks]), +or it might include a full implementation from the beginning. +In either case, discussion progresses the same way for an individual patch series, +until consensus is reached or the topic is dropped. + + +Larger Discussions (without patches) +------------------------------------ +Occasionally, larger discussions might occur without an associated patch series. +These may be very large-scale technical decisions that are beyond the scope of +even a single large patch series, or they may be more open-ended, +policy-oriented discussions (examples: +link:https://lore.kernel.org/git/ZZ77NQkSuiRxRDwt@nand.local/[introducing Rust] +or link:https://lore.kernel.org/git/YHofmWcIAidkvJiD@google.com/[improving submodule UX]). +In either case, discussion progresses as described above for general patch series. + +For larger discussions without a patch series or other concrete implementation, +it may be hard to judge when consensus has been reached, as there are not any +official guidelines. If discussion stalls at this point, it may be helpful to +restart discussion with an RFC patch series (such as a partial, unfinished +implementation or proof of concept) that can be more easily debated. + +When consensus is reached that it is a good idea, the original +proposer is expected to coordinate the effort to make it happen, +with help from others who were involved in the discussion, as +needed. + +For decisions that require code changes, it is often the case that the original +proposer will follow up with a patch series, although it is also common for +other interested parties to provide an implementation (or parts of the +implementation, for very large changes). + +For non-technical decisions such as community norms or processes, it is up to +the community as a whole to implement and sustain agreed-upon changes. +The project leadership committee (PLC) may help the implementation of +policy decisions. + + +Other Discussion Venues +----------------------- +Occasionally decision proposals are presented off-list, e.g. at the semi-regular +Contributors' Summit. While higher-bandwidth face-to-face discussion is often +useful for quickly reaching consensus among attendees, generally we expect to +summarize the discussion in notes that can later be presented on-list. For an +example, see the thread +link:https://lore.kernel.org/git/AC2EB721-2979-43FD-922D-C5076A57F24B@jramsay.com.au/[Notes +from Git Contributor Summit, Los Angeles (April 5, 2020)] by James Ramsay. + +We prefer that "official" discussion happens on the list so that the full +community has opportunity to engage in discussion. This also means that the +mailing list archives contain a more-or-less complete history of project +discussions and decisions. diff --git a/Documentation/Makefile b/Documentation/Makefile index b629176d7d..0f55baa252 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -51,6 +51,7 @@ MAN7_TXT += gitdiffcore.txt MAN7_TXT += giteveryday.txt MAN7_TXT += gitfaq.txt MAN7_TXT += gitglossary.txt +MAN7_TXT += gitpacking.txt MAN7_TXT += gitnamespaces.txt MAN7_TXT += gitremote-helpers.txt MAN7_TXT += gitrevisions.txt @@ -103,6 +104,7 @@ SP_ARTICLES += howto/coordinate-embargoed-releases 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 += DecisionMaking TECH_DOCS += ReviewingGuidelines TECH_DOCS += MyFirstContribution TECH_DOCS += MyFirstObjectWalk @@ -116,12 +118,14 @@ TECH_DOCS += technical/multi-pack-index TECH_DOCS += technical/pack-heuristics TECH_DOCS += technical/parallel-checkout TECH_DOCS += technical/partial-clone +TECH_DOCS += technical/platform-support TECH_DOCS += technical/racy-git TECH_DOCS += technical/reftable TECH_DOCS += technical/scalar TECH_DOCS += technical/send-pack-pipeline TECH_DOCS += technical/shallow TECH_DOCS += technical/trivial-merge +TECH_DOCS += technical/unit-tests SP_ARTICLES += $(TECH_DOCS) SP_ARTICLES += technical/api-index @@ -201,12 +205,15 @@ ASCIIDOC_DOCBOOK = docbook5 ASCIIDOC_EXTRA += -acompat-mode -atabsize=8 ASCIIDOC_EXTRA += -I. -rasciidoctor-extensions ASCIIDOC_EXTRA += -alitdd='&\#x2d;&\#x2d;' +ASCIIDOC_EXTRA += -adocinfo=shared ASCIIDOC_DEPS = asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS DBLATEX_COMMON = XMLTO_EXTRA += --skip-validation XMLTO_EXTRA += -x manpage.xsl endif +ASCIIDOC_DEPS += docinfo.html + SHELL_PATH ?= $(SHELL) # Shell quote; SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) @@ -335,6 +342,9 @@ clean: $(RM) $(cmds_txt) $(mergetools_txt) *.made $(RM) GIT-ASCIIDOCFLAGS +docinfo.html: docinfo-html.in + $(QUIET_GEN)$(RM) $@ && cat $< >$@ + $(MAN_HTML): %.html : %.txt $(ASCIIDOC_DEPS) $(QUIET_ASCIIDOC)$(TXT_TO_HTML) -d manpage -o $@ $< @@ -483,12 +493,16 @@ $(LINT_DOCS_FSCK_MSGIDS): ../fsck.h fsck-msgids.txt lint-docs-fsck-msgids: $(LINT_DOCS_FSCK_MSGIDS) +lint-docs-manpages: + $(QUIET_GEN)./lint-manpages.sh + ## Lint: list of targets above .PHONY: lint-docs lint-docs: lint-docs-fsck-msgids lint-docs: lint-docs-gitlink lint-docs: lint-docs-man-end-blurb lint-docs: lint-docs-man-section-order +lint-docs: lint-docs-manpages ifeq ($(wildcard po/Makefile),po/Makefile) doc-l10n install-l10n:: diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt index 62d11a5cd7..e41654c00a 100644 --- a/Documentation/MyFirstContribution.txt +++ b/Documentation/MyFirstContribution.txt @@ -35,8 +35,9 @@ 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 +the list by sending an email to <git+subscribe@vger.kernel.org> +(see https://subspace.kernel.org/subscribing.html for details). +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] @@ -160,10 +161,11 @@ 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`. +Be sure to `#include "builtin.h"` in your `psuh.c`. You'll also need to +`#include "gettext.h"` to use functions related to printing output text. -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. +Go ahead and add some throwaway printf to the `cmd_psuh` 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 @@ -832,7 +834,7 @@ 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. +suite for you. It's documented at https://gitgitgadget.github.io/. [[create-fork]] === Forking `git/git` on GitHub @@ -1114,6 +1116,15 @@ $ 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. +:contrib-scripts: footnoteref:[contrib-scripts,Scripts under `contrib/` are + +not part of the core `git` binary and must be called directly. Clone the Git + +codebase and run `perl contrib/contacts/git-contacts`.] + +NOTE: If you're not sure whom to CC, running `contrib/contacts/git-contacts` can +list potential reviewers. In addition, you can do `git send-email +--cc-cmd='perl contrib/contacts/git-contacts' feature/*.patch`{contrib-scripts} to +automatically pass this list of emails to `send-email`. + 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. diff --git a/Documentation/MyFirstObjectWalk.txt b/Documentation/MyFirstObjectWalk.txt index c68cdb11b9..dec8afe5b1 100644 --- a/Documentation/MyFirstObjectWalk.txt +++ b/Documentation/MyFirstObjectWalk.txt @@ -210,13 +210,14 @@ We'll also need to include the `config.h` header: ... -static int git_walken_config(const char *var, const char *value, void *cb) +static int git_walken_config(const char *var, const char *value, + const struct config_context *ctx, 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); + return git_default_config(var, value, ctx, cb); } ---- @@ -389,10 +390,11 @@ modifying `rev_info.grep_filter`, which is a `struct grep_opt`. First some setup. Add `grep_config()` to `git_walken_config()`: ---- -static int git_walken_config(const char *var, const char *value, void *cb) +static int git_walken_config(const char *var, const char *value, + const struct config_context *ctx, void *cb) { - grep_config(var, value, cb); - return git_default_config(var, value, cb); + grep_config(var, value, ctx, cb); + return git_default_config(var, value, ctx, cb); } ---- @@ -523,7 +525,7 @@ 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 +resides in `builtin/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 @@ -732,8 +734,8 @@ walk we've just performed: } else { trace_printf( _("Filtered object walk with filterspec 'tree:1'.\n")); - CALLOC_ARRAY(rev->filter, 1); - parse_list_objects_filter(rev->filter, "tree:1"); + + parse_list_objects_filter(&rev->filter, "tree:1"); } traverse_commit_list(rev, walken_show_commit, walken_show_object, NULL); @@ -752,10 +754,12 @@ 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. +filter, like with `git log --filter=<spec> --filter-print-omitted`. To do this, +change `traverse_commit_list()` to `traverse_commit_list_filtered()`, which is +able to populate an `omitted` list. Asking for this list of filtered objects +may cause performance degradations, however, because in this case, despite +filtering objects, the possibly much larger set of all reachable objects must +be processed in order to populate that list. First, add the `struct oidset` and related items we will use to iterate it: @@ -776,8 +780,9 @@ static void walken_object_walk( ... ---- -Modify the call to `traverse_commit_list_filtered()` to include your `omitted` -object: +Replace the call to `traverse_commit_list()` with +`traverse_commit_list_filtered()` and pass a pointer to the `omitted` oidset +defined and initialized above: ---- ... @@ -843,7 +848,7 @@ those lines without having to recompile. With only that change, run again (but save yourself some scrollback): ---- -$ GIT_TRACE=1 ./bin-wrappers/git walken | head -n 10 +$ GIT_TRACE=1 ./bin-wrappers/git walken 2>&1 | head -n 10 ---- Take a look at the top commit with `git show` and the object ID you printed; it @@ -871,7 +876,7 @@ of the first handful: ---- $ make -$ GIT_TRACE=1 ./bin-wrappers git walken | tail -n 10 +$ GIT_TRACE=1 ./bin-wrappers/git walken 2>&1 | tail -n 10 ---- The last commit object given should have the same OID as the one we saw at the diff --git a/Documentation/RelNotes/1.6.2.txt b/Documentation/RelNotes/1.6.2.txt index 980adfb315..166d73c60f 100644 --- a/Documentation/RelNotes/1.6.2.txt +++ b/Documentation/RelNotes/1.6.2.txt @@ -10,7 +10,7 @@ To ease the transition plan, the receiving repository of such a push running this release will issue a big warning when the configuration variable is missing. Please refer to: - http://git.or.cz/gitwiki/GitFaq#non-bare + https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitFaq.html#non-bare https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the diff --git a/Documentation/RelNotes/1.6.3.txt b/Documentation/RelNotes/1.6.3.txt index 4bcff945e0..bbf177fc3c 100644 --- a/Documentation/RelNotes/1.6.3.txt +++ b/Documentation/RelNotes/1.6.3.txt @@ -10,7 +10,7 @@ To ease the transition plan, the receiving repository of such a push running this release will issue a big warning when the configuration variable is missing. Please refer to: - http://git.or.cz/gitwiki/GitFaq#non-bare + https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitFaq.html#non-bare https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the diff --git a/Documentation/RelNotes/1.6.4.txt b/Documentation/RelNotes/1.6.4.txt index a2a34b43a7..0fccfb0bf0 100644 --- a/Documentation/RelNotes/1.6.4.txt +++ b/Documentation/RelNotes/1.6.4.txt @@ -10,7 +10,7 @@ To ease the transition plan, the receiving repository of such a push running this release will issue a big warning when the configuration variable is missing. Please refer to: - http://git.or.cz/gitwiki/GitFaq#non-bare + https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitFaq.html#non-bare https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the diff --git a/Documentation/RelNotes/1.6.5.txt b/Documentation/RelNotes/1.6.5.txt index 6c7f7da7eb..79cb1b2b6d 100644 --- a/Documentation/RelNotes/1.6.5.txt +++ b/Documentation/RelNotes/1.6.5.txt @@ -21,7 +21,7 @@ To ease the transition plan, the receiving repository of such a push running this release will issue a big warning when the configuration variable is missing. Please refer to: - http://git.or.cz/gitwiki/GitFaq#non-bare + https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitFaq.html#non-bare https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the diff --git a/Documentation/RelNotes/1.6.6.txt b/Documentation/RelNotes/1.6.6.txt index 3ed1e01433..88b86a827e 100644 --- a/Documentation/RelNotes/1.6.6.txt +++ b/Documentation/RelNotes/1.6.6.txt @@ -63,7 +63,7 @@ users will fare this time. Please refer to: - http://git.or.cz/gitwiki/GitFaq#non-bare + https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitFaq.html#non-bare https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the diff --git a/Documentation/RelNotes/2.43.0.txt b/Documentation/RelNotes/2.43.0.txt new file mode 100644 index 0000000000..e0e5b535bb --- /dev/null +++ b/Documentation/RelNotes/2.43.0.txt @@ -0,0 +1,323 @@ +Git v2.43 Release Notes +======================= + +Backward Compatibility Notes + + * The "--rfc" option of "git format-patch" used to be a valid way to + override an earlier "--subject-prefix=<something>" on the command + line and replace it with "[RFC PATCH]", but from this release, it + merely prefixes the string "RFC " in front of the given subject + prefix. If you are negatively affected by this change, please use + "--subject-prefix=PATCH --rfc" as a replacement. + + * In Git 2.42, "git rev-list --stdin" learned to take non-revisions + (like "--not") from the standard input, but the way such a "--not" was + handled was quite confusing, which has been rethought. The updated + rule is that "--not" given from the command line only affects revs + given from the command line that comes but not revs read from the + standard input, and "--not" read from the standard input affects + revs given from the standard input and not revs given from the + command line. + +UI, Workflows & Features + + * A message written in olden time prevented a branch from getting + checked out, saying it is already checked out elsewhere. But these + days, we treat a branch that is being bisected or rebased just like + a branch that is checked out and protect it from getting modified + with the same codepath. The message has been rephrased to say that + the branch is "in use" to avoid confusion. + + * Hourly and other schedules of "git maintenance" jobs are randomly + distributed now. + + * "git cmd -h" learned to signal which options can be negated by + listing such options like "--[no-]opt". + + * The way authentication related data other than passwords (e.g., + oauth token and password expiration data) are stored in libsecret + keyrings has been rethought. + + * Update the libsecret and wincred credential helpers to correctly + match which credential to erase; they erased the wrong entry in + some cases. + + * Git GUI updates. + + * "git format-patch" learned a new "--description-file" option that + lets cover letter description to be fed; this can be used on + detached HEAD where there is no branch description available, and + also can override the branch description if there is one. + + * Use of the "--max-pack-size" option to allow multiple packfiles to + be created is now supported even when we are sending unreachable + objects to cruft packs. + + * "git format-patch --rfc --subject-prefix=<foo>" used to ignore the + "--subject-prefix" option and used "[RFC PATCH]"; now we will add + "RFC" prefix to whatever subject prefix is specified. + + * "git log --format" has been taught the %(decorate) placeholder for + further customization over what the "--decorate" option offers. + + * The default log message created by "git revert", when reverting a + commit that records a revert, has been tweaked, to encourage people + to describe complex "revert of revert of revert" situations better in + their own words. + + * The command-line completion support (in contrib/) learned to + complete "git commit --trailer=" for possible trailer keys. + + * "git update-index" learned the "--show-index-version" option to + inspect the index format version used by the on-disk index file. + + * "git diff" learned the "diff.statNameWidth" configuration variable, + to give the default width for the name part in the "--stat" output. + + * "git range-diff --notes=foo" compared "log --notes=foo --notes" of + the two ranges, instead of using just the specified notes tree, + which has been corrected to use only the specified notes tree. + + * The command line completion script (in contrib/) can be told to + complete aliases by including ": git <cmd> ;" in the alias to tell + it that the alias should be completed in a similar way to how "git + <cmd>" is completed. The parsing code for the alias has been + loosened to allow ';' without an extra space before it. + + * "git for-each-ref" and friends learned to apply mailmap to + authorname and other fields in a more flexible way than using + separate placeholder letters like %a[eElL] every time we want to + come up with small variants. + + * "git repack" machinery learned to pay attention to the "--filter=" + option. + + * "git repack" learned the "--max-cruft-size" option to prevent cruft + packs from growing without bounds. + + * "git merge-tree" learned to take strategy backend specific options + via the "-X" option, like "git merge" does. + + * "git log" and friends learned the "--dd" option that is a + short-hand for "--diff-merges=first-parent -p". + + * The attribute subsystem learned to honor the "attr.tree" + configuration variable that specifies which tree to read the + .gitattributes files from. + + * "git merge-file" learns a mode to read three variants of the + contents to be merged from blob objects. + + +Performance, Internal Implementation, Development Support etc. + + * "git check-attr" has been taught to work better with sparse-index. + + * It may be tempting to leave the help text NULL for a command line + option that is either hidden or too obvious, but "git subcmd -h" + and "git subcmd --help-all" would have segfaulted if done so. Now + the help text is truly optional. + + * Tests that are known to pass with LSan are now marked as such. + + * Flaky "git p4" tests, as well as "git svn" tests, are now skipped + in the (rather expensive) sanitizer CI job. + + * Tests with LSan from time to time seem to emit harmless messages + that make our tests unnecessarily flaky; we work around it by + filtering the uninteresting output. + + * Unused parameters to functions are marked as such, and/or removed, + in order to bring us closer to "-Wunused-parameter" clean. + + * The code to keep track of existing packs in the repository while + repacking has been refactored. + + * The "streaming" interface used for bulk-checkin codepath has been + narrowed to take only blob objects for now, with no real loss of + functionality. + + * GitHub CI workflow has learned to trigger Coverity check. + + * Test coverage for trailers has been improved. + + * The code to iterate over loose references has been optimized to + reduce the number of lstat() system calls. + + * The codepaths that read "chunk" formatted files have been corrected + to pay attention to the chunk size and notice broken files. + + * Replace macos-12 used at GitHub CI with macos-13. + (merge 682a868f67 js/ci-use-macos-13 later to maint). + + +Fixes since v2.42 +----------------- + + * Overly long label names used in the sequencer machinery are now + chopped to fit under filesystem limitation. + + * Scalar updates. + + * Tweak GitHub Actions CI so that pushing the same commit to multiple + branch tips at the same time will not waste building and testing + the same thing twice. + + * The commit-graph verification code that detects a mixture of zero and + non-zero generation numbers has been updated. + + * "git diff -w --exit-code" with various options did not work + correctly, which has been corrected. + + * The "transfer.unpackLimit" configuration variable ought to be used + as a fallback, but overrode the more specific "fetch.unpackLimit" + and "receive.unpackLimit" configuration variables by mistake, which + has been corrected. + + * The use of API between two calls to require_clean_work_tree() from + the sequencer code has been cleaned up for consistency. + + * "git diff --no-such-option" and other corner cases around the exit + status of the "diff" command have been corrected. + + * "git for-each-ref --sort='contents:size'" sorted the refs according + to size numerically, giving a ref that points at a blob twelve-byte + (12) long before showing a blob hundred-byte (100) long, which has + been corrected. + + * We now limit the depth of the tree objects and maximum length of + pathnames recorded in tree objects. + (merge 4d5693ba05 jk/tree-name-and-depth-limit later to maint). + + * Various fixes to the behavior of "rebase -i", when the command got + interrupted by conflicting changes, have been made. + + * References from a description of the `--patch` option in various + manual pages have been simplified and improved. + + * "git grep -e A --no-or -e B" is accepted, even though the negation + of the "--or" option did not mean anything, which has been tightened. + + * The completion script (in contrib/) has been taught to treat the + "-t" option to "git checkout" and "git switch" just like the + "--track" option, to complete remote-tracking branches. + + * "git diff --no-index -R <(one) <(two)" did not work correctly, + which has been corrected. + + * "git maintenance" timers' implementation has been updated, based on + systemd timers, to work with WSL. + + * "git diff --cached" codepath did not fill the necessary stat + information for a file when fsmonitor knows it is clean and ended + up behaving as if it were not clean, which has been corrected. + + * How "alias.foo = : git cmd ; aliased-command-string" should be + spelled with necessary whitespace around punctuation marks to work + has been more clearly documented (but this will be moot with newer + versions of Git where the parsing rules have been improved). + + * HTTP Header redaction code has been adjusted for a newer version of + cURL library that shows its traces differently from earlier + versions. + + * An error message given by "git send-email", when given a malformed + address, did not show the offending address, which has been corrected. + + * UBSan options were not propagated through the test framework to git + run via the httpd, unlike ASan options, which has been corrected. + + * "checkout --merge -- path" and "update-index --unresolve path" did + not resurrect conflicted state that was resolved to remove path, + but now they do. + (merge 5bdedac3c7 jc/unresolve-removal later to maint). + + * The display width table for unicode characters has been updated for + Unicode 15.1 + (merge 872976c37e bb/unicode-width-table-15 later to maint). + + * Update mailmap entry for Derrick. + (merge 6e5457d8c7 ds/mailmap-entry-update later to maint). + + * In the ".gitmodules" files, submodules are keyed by their names, + and the path to the submodule whose name is $name is specified by + the submodule.$name.path variable. There were a few codepaths that + mixed the name and path up when consulting the submodule database, + which have been corrected. It took long for these bugs to be found + as the name of a submodule initially is the same as its path, and + the problem does not surface until it is moved to a different path, + which apparently happens very rarely. + + * "git diff --merge-base X other args..." insisted that X must be a + commit and errored out when given an annotated tag that peels to a + commit, but we only need it to be a committish. This has been + corrected. + (merge 4adceb5a29 ar/diff-index-merge-base-fix later to maint). + + * "git merge-tree" used to segfault when the "--attr-source" + option is used, which has been corrected. + (merge e95bafc52f jc/merge-ort-attr-index-fix later to maint). + + * Unlike "git log --pretty=%D", "git log --pretty="%(decorate)" did + not auto-initialize the decoration subsystem, which has been + corrected. + + * Feeding "git stash store" with a random commit that was not created + by "git stash create" now errors out. + (merge d9b6634589 jc/fail-stash-to-store-non-stash later to maint). + + * The index file has room only for the lower 32-bit of the file size in + the cached stat information, which means cached stat information + will have 0 in its sd_size member for a file whose size is a multiple + of 4GiB. This is mistaken for a racily clean path. Avoid it by + storing a bogus sd_size value instead for such files. + (merge 5143ac07b1 bc/racy-4gb-files later to maint). + + * "git p4" tried to store symlinks to LFS when told, but has been + fixed not to do so, because it does not make sense. + (merge 10c89a02b0 mm/p4-symlink-with-lfs later to maint). + + * The codepath to handle recipient addresses `git send-email + --compose` learns from the user was completely broken, which has + been corrected. + (merge 3ec6167567 jk/send-email-fix-addresses-from-composed-messages later to maint). + + * "cd sub && git grep -f patterns" tried to read "patterns" file at + the top level of the working tree; it has been corrected to read + "sub/patterns" instead. + + * "git reflog expire --single-worktree" has been broken for the past + 20 months or so, which has been corrected. + + * "git send-email" did not have certain pieces of data computed yet + when it tried to validate the outgoing messages and its recipient + addresses, which has been sorted out. + + * "git bugreport" learned to complain when it received a command line + argument that it will not use. + + * The codepath to traverse the commit-graph learned to notice that a + commit is missing (e.g., corrupt repository lost an object), even + though it knows something about the commit (like its parents) from + what is in commit-graph. + (merge 7a5d604443 ps/do-not-trust-commit-graph-blindly-for-existence later to maint). + + * "git rev-list --missing" did not work for missing commit objects, + which has been corrected. + + * "git rev-list --unpacked --objects" failed to exclude packed + non-commit objects, which has been corrected. + (merge 7b3c8e9f38 tb/rev-list-unpacked-fix later to maint). + + * "To dereference" and "to peel" were sometimes used in in-code + comments and documentation but without description in the glossary. + (merge 893dce2ffb vd/glossary-dereference-peel later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge c2c349a15c xz/commit-title-soft-limit-doc later to maint). + (merge 1bd809938a tb/format-pack-doc-update later to maint). + (merge 8f81532599 an/clang-format-typofix later to maint). + (merge 3ca86adc2d la/strvec-header-fix later to maint). + (merge 6789275d37 jc/test-i18ngrep later to maint). + (merge 9972cd6004 ps/leakfixes later to maint). + (merge 46edab516b tz/send-email-helpfix later to maint). diff --git a/Documentation/RelNotes/2.43.1.txt b/Documentation/RelNotes/2.43.1.txt new file mode 100644 index 0000000000..20e96f2dfa --- /dev/null +++ b/Documentation/RelNotes/2.43.1.txt @@ -0,0 +1,82 @@ +Git 2.43.1 Release Notes +======================== + +There is nothing exciting to see here. Relative to Git 2.43, this +release contains the fixes that have already been merged to the +'master' branch of the development towards the next major release. + +Fixes since Git 2.43.0 +---------------------- + + * The way CI testing used "prove" could lead to running the test + suite twice needlessly, which has been corrected. + + * Newer versions of Getopt::Long started giving warnings against our + (ab)use of it in "git send-email". Bump the minimum version + requirement for Perl to 5.8.1 (from September 2002) to allow + simplifying our implementation. + + * Earlier we stopped relying on commit-graph that (still) records + information about commits that are lost from the object store, + which has negative performance implications. The default has been + flipped to disable this pessimization. + + * Stale URLs have been updated to their current counterparts (or + archive.org) and HTTP links are replaced with working HTTPS links. + + * trace2 streams used to record the URLs that potentially embed + authentication material, which has been corrected. + + * The sample pre-commit hook that tries to catch introduction of new + paths that use potentially non-portable characters did not notice + an existing path getting renamed to such a problematic path, when + rename detection was enabled. + + * The command line parser for the "log" family of commands was too + loose when parsing certain numbers, e.g., silently ignoring the + extra 'q' in "git log -n 1q" without complaining, which has been + tightened up. + + * "git $cmd --end-of-options --rev -- --path" for some $cmd failed + to interpret "--rev" as a rev, and "--path" as a path. This was + fixed for many programs like "reset" and "checkout". + + * "git bisect reset" has been taught to clean up state files and refs + even when BISECT_START file is gone. + + * Some codepaths did not correctly parse configuration variables + specified with valueless "true", which has been corrected. + + * Code clean-up for sanity checking of command line options for "git + show-ref". + + * The code to parse the From e-mail header has been updated to avoid + recursion. + + * "git fetch --atomic" issued an unnecessary empty error message, + which has been corrected. + + * Command line completion script (in contrib/) learned to work better + with the reftable backend. + + * "git status" is taught to show both the branch being bisected and + being rebased when both are in effect at the same time. + cf. <xmqqil76kyov.fsf@gitster.g> + + * "git archive --list extra garbage" silently ignored excess command + line parameters, which has been corrected. + + * "git sparse-checkout set" added default patterns even when the + patterns are being fed from the standard input, which has been + corrected. + + * Unlike other environment variables that took the usual + true/false/yes/no as well as 0/1, GIT_FLUSH only understood 0/1, + which has been corrected. + + * Clearing in-core repository (happens during e.g., "git fetch + --recurse-submodules" with commit graph enabled) made in-core + commit object in an inconsistent state by discarding the necessary + data from commit-graph too early, which has been corrected. + +Also contains various documentation updates, code clean-ups and minor fixups. diff --git a/Documentation/RelNotes/2.43.2.txt b/Documentation/RelNotes/2.43.2.txt new file mode 100644 index 0000000000..5895e23a54 --- /dev/null +++ b/Documentation/RelNotes/2.43.2.txt @@ -0,0 +1,37 @@ +Git 2.43.2 Release Notes +======================== + +Relative to Git 2.43.1, this release has two important fixes to allow +"git imap-send" to be built with NO_CURL defined, and to restore the +forced flushing behaviour when GIT_FLUSH=1 is set. It also contains +other, unexciting, fixes that have already been merged to the 'master' +branch of the development towards the next major release. + +Fixes since Git 2.43.1 +---------------------- + + * Update to a new feature recently added, "git show-ref --exists". + + * Rename detection logic ignored the final line of a file if it is an + incomplete line. + + * "git diff --no-rename A B" did not disable rename detection but did + not trigger an error from the command line parser. + + * "git diff --no-index file1 file2" segfaulted while invoking the + external diff driver, which has been corrected. + + * Rewrite //-comments to /* comments */ in files whose comments + prevalently use the latter. + + * A failed "git tag -s" did not necessarily result in an error + depending on the crypto backend, which has been corrected. + + * "git stash" sometimes was silent even when it failed due to + unwritable index file, which has been corrected. + + * Recent conversion to allow more than 0/1 in GIT_FLUSH broke the + mechanism by flipping what yes/no means by mistake, which has been + corrected. + +Also contains documentation updates, code clean-ups and minor fixups. diff --git a/Documentation/RelNotes/2.43.3.txt b/Documentation/RelNotes/2.43.3.txt new file mode 100644 index 0000000000..924f20594f --- /dev/null +++ b/Documentation/RelNotes/2.43.3.txt @@ -0,0 +1,12 @@ +Git 2.43.3 Release Notes +======================== + +Relative to Git 2.43.2, this release fixes one regression that +manifests while running "git commit -v --trailer". + +Fixes since Git 2.43.2 +---------------------- + + * "git commit -v --trailer=..." was broken with recent update and + placed the trailer _after_ the divider line, which has been + corrected. diff --git a/Documentation/RelNotes/2.43.4.txt b/Documentation/RelNotes/2.43.4.txt new file mode 100644 index 0000000000..0a842515ff --- /dev/null +++ b/Documentation/RelNotes/2.43.4.txt @@ -0,0 +1,7 @@ +Git v2.43.4 Release Notes +========================= + +This release merges up the fix that appears in v2.39.4, v2.40.2, +v2.41.1 and v2.42.2 to address the security issues CVE-2024-32002, +CVE-2024-32004, CVE-2024-32020, CVE-2024-32021 and CVE-2024-32465; +see the release notes for these versions for details. diff --git a/Documentation/RelNotes/2.43.5.txt b/Documentation/RelNotes/2.43.5.txt new file mode 100644 index 0000000000..236b234b06 --- /dev/null +++ b/Documentation/RelNotes/2.43.5.txt @@ -0,0 +1,26 @@ +Git v2.43.5 Release Notes +========================= + +In preparing security fixes for four CVEs, we made overly aggressive +"defense in depth" changes that broke legitimate use cases like 'git +lfs' and 'git annex.' This release is to revert these misguided, if +well-intentioned, changes that were shipped in 2.43.4 and were not +direct security fixes. + +Jeff King (5): + send-email: drop FakeTerm hack + send-email: avoid creating more than one Term::ReadLine object + ci: drop mention of BREW_INSTALL_PACKAGES variable + ci: avoid bare "gcc" for osx-gcc job + ci: stop installing "gcc-13" for osx-gcc + +Johannes Schindelin (6): + hook: plug a new memory leak + init: use the correct path of the templates directory again + Revert "core.hooksPath: add some protection while cloning" + tests: verify that `clone -c core.hooksPath=/dev/null` works again + clone: drop the protections where hooks aren't run + Revert "Add a helper function to compare file contents" + +Junio C Hamano (1): + Revert "fsck: warn about symlink pointing inside a gitdir" diff --git a/Documentation/RelNotes/2.44.0.txt b/Documentation/RelNotes/2.44.0.txt new file mode 100644 index 0000000000..14f9ce8226 --- /dev/null +++ b/Documentation/RelNotes/2.44.0.txt @@ -0,0 +1,334 @@ +Git v2.44 Release Notes +======================= + +Backward Compatibility Notes + + * "git checkout -B <branch>" used to allow switching to a branch that + is in use on another worktree, but this was by mistake. The users + need to use "--ignore-other-worktrees" option. + + +UI, Workflows & Features + + * "git add" and "git stash" learned to support the ":(attr:...)" + magic pathspec. + + * "git rebase --autosquash" is now enabled for non-interactive rebase, + but it is still incompatible with the apply backend. + + * Introduce "git replay", a tool meant on the server side without + working tree to recreate a history. + + * "git merge-file" learned to take the "--diff-algorithm" option to + use algorithm different from the default "myers" diff. + + * Command line completion (in contrib/) learned to complete path + arguments to the "add/set" subcommands of "git sparse-checkout" + better. + + * "git checkout -B <branch> [<start-point>]" allowed a branch that is + in use in another worktree to be updated and checked out, which + might be a bit unexpected. The rule has been tightened, which is a + breaking change. "--ignore-other-worktrees" option is required to + unbreak you, if you are used to the current behaviour that "-B" + overrides the safety. + + * The builtin_objectmode attribute is populated for each path + without adding anything in .gitattributes files, which would be + useful in magic pathspec, e.g., ":(attr:builtin_objectmode=100755)" + to limit to executables. + + * "git fetch" learned to pay attention to "fetch.all" configuration + variable, which pretends as if "--all" was passed from the command + line when no remote parameter was given. + + * In addition to (rather cryptic) Security Identifiers, show username + and domain in the error message when we barf on mismatch between + the Git directory and the current user on Windows. + + * The error message given when "git branch -d branch" fails due to + commits unique to the branch has been split into an error and a new + conditional advice message. + + * When given an existing but unreadable file as a configuration file, + gitweb behaved as if the file did not exist at all, but now it + errors out. This is a change that may break backward compatibility. + + * When $HOME/.gitconfig is missing but XDG config file is available, we + should write into the latter, not former. "git gc" and "git + maintenance" wrote into a wrong "global config" file, which have + been corrected. + + * Define "special ref" as a very narrow set that consists of + FETCH_HEAD and MERGE_HEAD, and clarify everything else that used to + be classified as such are actually just pseudorefs. + + * All conditional "advice" messages show how to turn them off, which + becomes repetitive. Setting advice.* configuration explicitly on + now omits the instruction part. + + * The "disable repository discovery of a bare repository" check, + triggered by setting safe.bareRepository configuration variable to + 'explicit', has been loosened to exclude the ".git/" directory inside + a non-bare repository from the check. So you can do "cd .git && + git cmd" to run a Git command that works on a bare repository without + explicitly specifying $GIT_DIR now. + + * The completion script (in contrib/) learned more options that can + be used with "git log". + + * The labels on conflict markers for the common ancestor, our version, + and the other version are available to custom 3-way merge driver + via %S, %X, and %Y placeholders. + + * The write codepath for the reftable data learned to honor + core.fsync configuration. + + * The "--fsck-objects" option of "git index-pack" now can take the + optional parameter to tweak severity of different fsck errors. + + * The wincred credential backend has been taught to support oauth + refresh token the same way as credential-cache and + credential-libsecret backends. + + * Command line completion support (in contrib/) has been + updated for "git bisect". + + * "git branch" and friends learned to use the formatted text as + sorting key, not the underlying timestamp value, when the --sort + option is used with author or committer timestamp with a format + specifier (e.g., "--sort=creatordate:format:%H:%M:%S"). + + * The command line completion script (in contrib/) learned to + complete configuration variable names better. + + +Performance, Internal Implementation, Development Support etc. + + * Process to add some form of low-level unit tests has started. + + * Add support for GitLab CI. + + * "git for-each-ref --no-sort" still sorted the refs alphabetically + which paid non-trivial cost. It has been redefined to show output + in an unspecified order, to allow certain optimizations to take + advantage of. + + * Simplify API implementation to delete references by eliminating + duplication. + + * Subject approxidate() and show_date() machinery to OSS-Fuzz. + + * A new helper to let us pretend that we called lstat() when we know + our cache_entry is up-to-date via fsmonitor. + + * The optimization based on fsmonitor in the "diff --cached" + codepath is resurrected with the "fake-lstat" introduced earlier. + + * Test balloon to use C99 "bool" type from <stdbool.h> has been + added. + + * "git clone" has been prepared to allow cloning a repository with + non-default hash function into a repository that uses the reftable + backend. + + * Streaming spans of packfile data used to be done only from a + single, primary, pack in a repository with multiple packfiles. It + has been extended to allow reuse from other packfiles, too. + + * Comment updates to help developers not to attempt to modify + messages from plumbing commands that must stay constant. + + It might make sense to reassess the plumbing needs every few years, + but that should be done as a separate effort. + + * Move test-ctype helper to the unit-test framework. + + * Instead of manually creating refs/ hierarchy on disk upon a + creation of a secondary worktree, which is only usable via the + files backend, use the refs API to populate it. + + * CI for GitLab learned to drive macOS jobs. + + * A few tests to "git commit -o <pathspec>" and "git commit -i + <pathspec>" has been added. + + * Tests on ref API are moved around to prepare for reftable. + + * The Makefile often had to say "-L$(path) -R$(path)" that repeats + the path to the same library directory for link time and runtime. + A Makefile template is used to reduce such repetition. + + * The priority queue test has been migrated to the unit testing + framework. + + * Setting `feature.experimental` opts the user into multi-pack reuse + experiment + + * Squelch node.js 16 deprecation warnings from GitHub Actions CI + by updating actions/github-script and actions/checkout that use + node.js 20. + + * The mechanism to report the filename in the source code, used by + the unit-test machinery, assumed that the compiler expanded __FILE__ + to the path to the source given to the $(CC), but some compilers + give full path, breaking the output. This has been corrected. + + +Fixes since v2.43 +----------------- + + * The way CI testing used "prove" could lead to running the test + suite twice needlessly, which has been corrected. + + * Update ref-related tests. + + * "git format-patch --encode-email-headers" ignored the option when + preparing the cover letter, which has been corrected. + + * Newer versions of Getopt::Long started giving warnings against our + (ab)use of it in "git send-email". Bump the minimum version + requirement for Perl to 5.8.1 (from September 2002) to allow + simplifying our implementation. + + * Earlier we stopped relying on commit-graph that (still) records + information about commits that are lost from the object store, + which has negative performance implications. The default has been + flipped to disable this pessimization. + + * Stale URLs have been updated to their current counterparts (or + archive.org) and HTTP links are replaced with working HTTPS links. + + * trace2 streams used to record the URLs that potentially embed + authentication material, which has been corrected. + + * The sample pre-commit hook that tries to catch introduction of new + paths that use potentially non-portable characters did not notice + an existing path getting renamed to such a problematic path, when + rename detection was enabled. + + * The command line parser for the "log" family of commands was too + loose when parsing certain numbers, e.g., silently ignoring the + extra 'q' in "git log -n 1q" without complaining, which has been + tightened up. + + * "git $cmd --end-of-options --rev -- --path" for some $cmd failed + to interpret "--rev" as a rev, and "--path" as a path. This was + fixed for many programs like "reset" and "checkout". + + * "git bisect reset" has been taught to clean up state files and refs + even when BISECT_START file is gone. + + * Some codepaths did not correctly parse configuration variables + specified with valueless "true", which has been corrected. + + * Code clean-up for sanity checking of command line options for "git + show-ref". + + * The code to parse the From e-mail header has been updated to avoid + recursion. + + * "git fetch --atomic" issued an unnecessary empty error message, + which has been corrected. + + * Command line completion script (in contrib/) learned to work better + with the reftable backend. + + * "git status" is taught to show both the branch being bisected and + being rebased when both are in effect at the same time. + + * "git archive --list extra garbage" silently ignored excess command + line parameters, which has been corrected. + + * "git sparse-checkout set" added default patterns even when the + patterns are being fed from the standard input, which has been + corrected. + + * "git sparse-checkout (add|set) --[no-]cone --end-of-options" did + not handle "--end-of-options" correctly after a recent update. + + * Unlike other environment variables that took the usual + true/false/yes/no as well as 0/1, GIT_FLUSH only understood 0/1, + which has been corrected. + + * Clearing in-core repository (happens during e.g., "git fetch + --recurse-submodules" with commit graph enabled) made in-core + commit object in an inconsistent state by discarding the necessary + data from commit-graph too early, which has been corrected. + + * Update to a new feature recently added, "git show-ref --exists". + + * oss-fuzz tests are built and run in CI. + (merge c4a9cf1df3 js/oss-fuzz-build-in-ci later to maint). + + * Rename detection logic ignored the final line of a file if it is an + incomplete line. + + * GitHub CI update. + (merge 0188b2c8e0 pb/ci-github-skip-logs-for-broken-tests later to maint). + + * "git diff --no-rename A B" did not disable rename detection but did + not trigger an error from the command line parser. + + * "git archive --remote=<remote>" learned to talk over the smart + http (aka stateless) transport. + (merge 176cd68634 jx/remote-archive-over-smart-http later to maint). + + * Fetching via protocol v0 over Smart HTTP transport sometimes failed + to correctly auto-follow tags. + (merge fba732c462 jk/fetch-auto-tag-following-fix later to maint). + + * The documentation for the --exclude-per-directory option marked it + as deprecated, which confused readers into thinking there may be a + plan to remove it in the future, which was not our intention. + (merge 0009542cab jc/ls-files-doc-update later to maint). + + * "git diff --no-index file1 file2" segfaulted while invoking the + external diff driver, which has been corrected. + + * Rewrite //-comments to /* comments */ in files whose comments + prevalently use the latter. + + * Cirrus CI jobs started breaking because we specified version of + FreeBSD that is no longer available, which has been corrected. + (merge 81fffb66d3 cb/use-freebsd-13-2-at-cirrus-ci later to maint). + + * A caller called index_file_exists() that takes a string expressed + as <ptr, length> with a wrong length, which has been corrected. + (merge 156e28b36d jh/sparse-index-expand-to-path-fix later to maint). + + * A failed "git tag -s" did not necessarily result in an error + depending on the crypto backend, which has been corrected. + + * "git stash" sometimes was silent even when it failed due to + unwritable index file, which has been corrected. + + * "git show-ref --verify" did not show things like "CHERRY_PICK_HEAD", + which has been corrected. + + * Recent conversion to allow more than 0/1 in GIT_FLUSH broke the + mechanism by flipping what yes/no means by mistake, which has been + corrected. + + * The sequencer machinery does not use the ref API and instead + records names of certain objects it needs for its correct operation + in temporary files, which makes these objects susceptible to loss + by garbage collection. These temporary files have been added as + starting points for reachability analysis to fix this. + (merge bc7f5db896 pw/gc-during-rebase later to maint). + + * "git cherry-pick" invoked during "git rebase -i" session lost + the authorship information, which has been corrected. + (merge e4301f73ff vn/rebase-with-cherry-pick-authorship later to maint). + + * The code paths that call repo_read_object_file() have been + tightened to react to errors. + (merge 568459bf5e js/check-null-from-read-object-file later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge 5aea3955bc rj/clarify-branch-doc-m later to maint). + (merge 9cce3be2df bk/bisect-doc-fix later to maint). + (merge 8430b438f6 vd/fsck-submodule-url-test later to maint). + (merge 3cb4384683 jc/t0091-with-unknown-git later to maint). + (merge 020456cb74 rs/receive-pack-remove-find-header later to maint). + (merge bc47139f4f la/trailer-cleanups later to maint). diff --git a/Documentation/RelNotes/2.44.1.txt b/Documentation/RelNotes/2.44.1.txt new file mode 100644 index 0000000000..b5135c3281 --- /dev/null +++ b/Documentation/RelNotes/2.44.1.txt @@ -0,0 +1,8 @@ +Git v2.44.1 Release Notes +========================= + +This release merges up the fix that appears in v2.39.4, v2.40.2, +v2.41.1, v2.42.2 and v2.43.4 to address the security issues +CVE-2024-32002, CVE-2024-32004, CVE-2024-32020, CVE-2024-32021 +and CVE-2024-32465; see the release notes for these versions +for details. diff --git a/Documentation/RelNotes/2.44.2.txt b/Documentation/RelNotes/2.44.2.txt new file mode 100644 index 0000000000..76700f0b73 --- /dev/null +++ b/Documentation/RelNotes/2.44.2.txt @@ -0,0 +1,26 @@ +Git v2.44.2 Release Notes +========================= + +In preparing security fixes for four CVEs, we made overly aggressive +"defense in depth" changes that broke legitimate use cases like 'git +lfs' and 'git annex.' This release is to revert these misguided, if +well-intentioned, changes that were shipped in 2.44.1 and were not +direct security fixes. + +Jeff King (5): + send-email: drop FakeTerm hack + send-email: avoid creating more than one Term::ReadLine object + ci: drop mention of BREW_INSTALL_PACKAGES variable + ci: avoid bare "gcc" for osx-gcc job + ci: stop installing "gcc-13" for osx-gcc + +Johannes Schindelin (6): + hook: plug a new memory leak + init: use the correct path of the templates directory again + Revert "core.hooksPath: add some protection while cloning" + tests: verify that `clone -c core.hooksPath=/dev/null` works again + clone: drop the protections where hooks aren't run + Revert "Add a helper function to compare file contents" + +Junio C Hamano (1): + Revert "fsck: warn about symlink pointing inside a gitdir" diff --git a/Documentation/RelNotes/2.45.0.txt b/Documentation/RelNotes/2.45.0.txt new file mode 100644 index 0000000000..aa0315259b --- /dev/null +++ b/Documentation/RelNotes/2.45.0.txt @@ -0,0 +1,476 @@ +Git v2.45 Release Notes +======================= + +Backward Compatibility Notes + +UI, Workflows & Features + + * Integrate the reftable code into the refs framework as a backend. + With "git init --ref-format=reftable", hopefully it would be a lot + more efficient to manage a repository with many references. + + * "git checkout -p" and friends learned that "@" is a synonym + for "HEAD". + + * Variants of vimdiff learned to honor mergetool.<variant>.layout + settings. + + * "git reflog" learned a "list" subcommand that enumerates known reflogs. + + * When a merge conflicted at a submodule, merge-ort backend used to + unconditionally give a lengthy message to suggest how to resolve + it. Now the message can be squelched as an advice message. + + * "git for-each-ref" learned "--include-root-refs" option to show + even the stuff outside the 'refs/' hierarchy. + + * "git rev-list --missing=print" has learned to optionally take + "--allow-missing-tips", which allows the objects at the starting + points to be missing. + + * "git merge-tree" has learned that the three trees involved in the + 3-way merge only need to be trees, not necessarily commits. + + * "git log --merge" learned to pay attention to CHERRY_PICK_HEAD and + other kinds of *_HEAD pseudorefs. + + * Platform specific tweaks for OS/390 has been added to + config.mak.uname. + + * Users with safe.bareRepository=explicit can still work from within + $GIT_DIR of a seconary worktree (which resides at .git/worktrees/$name/) + of the primary worktree without explicitly specifying the $GIT_DIR + environment variable or the --git-dir=<path> option. + + * The output format for dates "iso-strict" has been tweaked to show + a time in the Zulu timezone with "Z" suffix, instead of "+00:00". + + * "git diff" and friends learned two extra configuration variables, + diff.srcPrefix and diff.dstPrefix. + + * The status.showUntrackedFiles configuration variable had a name + that tempts users to set a Boolean value expressed in our usual + "false", "off", and "0", but it only took "no". This has been + corrected so "true" and its synonyms are taken as "normal", while + "false" and its synonyms are taken as "no". + + * Remove an ancient and not well maintained Hg-to-git migration + script from contrib/. + + * Hints that suggest what to do after resolving conflicts can now be + squelched by disabling advice.mergeConflict. + + * Allow git-cherry-pick(1) to automatically drop redundant commits via + a new `--empty` option, similar to the `--empty` options for + git-rebase(1) and git-am(1). Includes a soft deprecation of + `--keep-redundant-commits` as well as some related docs changes and + sequencer code cleanup. + + * "git config" learned "--comment=<message>" option to leave a + comment immediately after the "variable = value" on the same line + in the configuration file. + + * core.commentChar used to be limited to a single byte, but has been + updated to allow an arbitrary multi-byte sequence. + + * "git add -p" and other "interactive hunk selection" UI has learned to + skip showing the hunk immediately after it has already been shown, and + an additional action to explicitly ask to reshow the current hunk. + + * "git pack-refs" learned the "--auto" option, which defers the decision of + whether and how to pack to the ref backend. This is used by the reftable + backend to avoid repacking of an already-optimal ref database. The new mode + is triggered from "git gc --auto". + + * "git add -u <pathspec>" and "git commit [-i] <pathspec>" did not + diagnose a pathspec element that did not match any files in certain + situations, unlike "git add <pathspec>" did. + + * The userdiff patterns for C# has been updated. + + * Git writes a "waiting for your editor" message on an incomplete + line after launching an editor, and then append another error + message on the same line if the editor errors out. It now clears + the "waiting for..." line before giving the error message. + + * The filename used for rejected hunks "git apply --reject" creates + was limited to PATH_MAX, which has been lifted. + + * When "git bisect" reports the commit it determined to be the + culprit, we used to show it in a format that does not honor common + UI tweaks, like log.date and log.decorate. The code has been + taught to use "git show" to follow more customizations. + + +Performance, Internal Implementation, Development Support etc. + + * The code to iterate over refs with the reftable backend has seen + some optimization. + + * More tests that are marked as "ref-files only" have been updated to + improve test coverage of reftable backend. + + * Some parts of command line completion script (in contrib/) have + been micro-optimized. + + * The way placeholders are to be marked-up in documentation have been + specified; use "_<placeholder>_" to typeset the word inside a pair + of <angle-brackets> emphasized. + + * "git --no-lazy-fetch cmd" allows to run "cmd" while disabling lazy + fetching of objects from the promisor remote, which may be handy + for debugging. + + * The implementation in "git clean" that makes "-n" and "-i" ignore + clean.requireForce has been simplified, together with the + documentation. + + * Uses of xwrite() helper have been audited and updated for better + error checking and simpler code. + + * Some trace2 events that lacked def_param have learned to show it, + enriching the output. + + * The parse-options code that deals with abbreviated long option + names have been cleaned up. + + * The code in reftable backend that creates new table files works + better with the tempfile framework to avoid leaving cruft after a + failure. + + * The reftable code has its own custom binary search function whose + comparison callback has an unusual interface, which caused the + binary search to degenerate into a linear search, which has been + corrected. + + * The code to iterate over reflogs in the reftable has been optimized + to reduce memory allocation and deallocation. + + * Work to support a repository that work with both SHA-1 and SHA-256 + hash algorithms has started. + + * A new fuzz target that exercises config parsing code has been + added. + + * Fix the way recently added tests interpolate variables defined + outside them, and document the best practice to help future + developers. + + * Introduce an experimental protocol for contributors to propose the + topic description to be used in the "What's cooking" report, the + merge commit message for the topic, and in the release notes and + document it in the SubmittingPatches document. + + * The t/README file now gives a hint on running individual tests in + the "t/" directory with "make t<num>-*.sh t<num>-*.sh". + (merge 8d383806fc pb/test-scripts-are-build-targets later to maint). + + * The "hint:" messages given by the advice mechanism, when given a + message with a blank line, left a line with trailing whitespace, + which has been cleansed. + + * Documentation rules has been explicitly described how to mark-up + literal parts and a few manual pages have been updated as examples. + + * The .editorconfig file has been taught that a Makefile uses HT + indentation. + + * t-prio-queue test has been cleaned up by using C99 compound + literals; this is meant to also serve as a weather-balloon to smoke + out folks with compilers who have trouble compiling code that uses + the feature. + + * Windows binary used to decide the use of unix-domain socket at + build time, but it learned to make the decision at runtime instead. + + * The "shared repository" test in the t0610 reftable test failed + under restrictive umask setting (e.g. 007), which has been + corrected. + + * Document and apply workaround for a buggy version of dash that + mishandles "local var=val" construct. + + * The codepaths that reach date_mode_from_type() have been updated to + pass "struct date_mode" by value to make them thread safe. + + * The strategy to compact multiple tables of reftables after many + operations accumulate many entries has been improved to avoid + accumulating too many tables uncollected. + + * The code to iterate over reftable blocks has seen some optimization + to reduce memory allocation and deallocation. + + * The way "git fast-import" handles paths described in its input has + been tightened up and more clearly documented. + + * The cvsimport tests required that the platform understands + traditional timezone notations like CST6CDT, which has been + updated to work on those systems as long as they understand + POSIX notation with explicit tz transition dates. + + * The code to format trailers have been cleaned up. + + +Fixes since v2.44 +----------------- + + * "git apply" on a filesystem without filemode support have learned + to take a hint from what is in the index for the path, even when + not working with the "--index" or "--cached" option, when checking + the executable bit match what is required by the preimage in the + patch. + (merge 45b625142d cp/apply-core-filemode later to maint). + + * "git column" has been taught to reject negative padding value, as + it would lead to nonsense behaviour including division by zero. + (merge 76fb807faa kh/column-reject-negative-padding later to maint). + + * "git am --help" now tells readers what actions are available in + "git am --whitespace=<action>", in addition to saying that the + option is passed through to the underlying "git apply". + (merge a171dac734 jc/am-whitespace-doc later to maint). + + * "git tag --column" failed to check the exit status of its "git + column" invocation, which has been corrected. + (merge 92e66478fc rj/tag-column-fix later to maint). + + * Credential helper based on libsecret (in contrib/) has been updated + to handle an empty password correctly. + (merge 8f1f2023b7 mh/libsecret-empty-password-fix later to maint). + + * "git difftool --dir-diff" learned to honor the "--trust-exit-code" + option; it used to always exit with 0 and signalled success. + (merge eb84c8b6ce ps/difftool-dir-diff-exit-code later to maint). + + * The code incorrectly attempted to use textconv cache when asked, + even when we are not running in a repository, which has been + corrected. + (merge affe355fe7 jk/textconv-cache-outside-repo-fix later to maint). + + * Remove an empty file that shouldn't have been added in the first + place. + (merge 4f66942215 js/remove-cruft-files later to maint). + + * The logic to access reflog entries by date and number had ugly + corner cases at the boundaries, which have been cleaned up. + (merge 5edd126720 jk/reflog-special-cases-fix later to maint). + + * An error message from "git upload-pack", which responds to "git + fetch" requests, had a trailing NUL in it, which has been + corrected. + (merge 3f4c7a0805 sg/upload-pack-error-message-fix later to maint). + + * Clarify wording in the CodingGuidelines that requires <git-compat-util.h> + to be the first header file. + (merge 4e89f0e07c jc/doc-compat-util later to maint). + + * "git commit -v --cleanup=scissors" used to add the scissors line + twice in the log message buffer, which has been corrected. + (merge e90cc075cc jt/commit-redundant-scissors-fix later to maint). + + * A custom remote helper no longer cannot access the newly created + repository during "git clone", which is a regression in Git 2.44. + This has been corrected. + (merge 199f44cb2e ps/remote-helper-repo-initialization-fix later to maint). + + * Various parts of upload-pack have been updated to bound the resource + consumption relative to the size of the repository to protect from + abusive clients. + (merge 6cd05e768b jk/upload-pack-bounded-resources later to maint). + + * The upload-pack program, when talking over v2, accepted the + packfile-uris protocol extension from the client, even if it did + not advertise the capability, which has been corrected. + (merge a922bfa3b5 jk/upload-pack-v2-capability-cleanup later to maint). + + * Make sure failure return from merge_bases_many() is properly caught. + (merge 25fd20eb44 js/merge-base-with-missing-commit later to maint). + + * FSMonitor client code was confused when FSEvents were given in a + different case on a case-insensitive filesystem, which has been + corrected. + (merge 29c139ce78 jh/fsmonitor-icase-corner-case-fix later to maint). + + * The "core.commentChar" configuration variable only allows an ASCII + character, which was not clearly documented, which has been + corrected. + (merge fb7c556f58 kh/doc-commentchar-is-a-byte later to maint). + + * With release 2.44 we got rid of all uses of test_i18ngrep and there + is no in-flight topic that adds a new use of it. Make a call to + test_i18ngrep a hard failure, so that we can remove it at the end + of this release cycle. + (merge 381a83dfa3 jc/test-i18ngrep later to maint). + + * The command line completion script (in contrib/) learned to + complete "git reflog" better. + (merge 1284f9cc11 rj/complete-reflog later to maint). + + * The logic to complete the command line arguments to "git worktree" + subcommand (in contrib/) has been updated to correctly honor things + like "git -C dir" etc. + (merge 3574816d98 rj/complete-worktree-paths-fix later to maint). + + * When git refuses to create a branch because the proposed branch + name is not a valid refname, an advice message is given to refer + the user to exact naming rules. + (merge 8fbd903e58 kh/branch-ref-syntax-advice later to maint). + + * Code simplification by getting rid of code that sets an environment + variable that is no longer used. + (merge 72a8d3f027 pw/rebase-i-ignore-cherry-pick-help-environment later to maint). + + * The code to find the effective end of log messages can fall into an + endless loop, which has been corrected. + (merge 2541cba2d6 fs/find-end-of-log-message-fix later to maint). + + * Mark-up used in the documentation has been improved for + consistency. + (merge 45d5ed3e50 ja/doc-markup-fixes later to maint). + + * The status.showUntrackedFiles configuration variable was + incorrectly documented to accept "false", which has been corrected. + + * Leaks from "git restore" have been plugged. + (merge 2f64da0790 rj/restore-plug-leaks later to maint). + + * "git bugreport --no-suffix" was not supported and instead + segfaulted, which has been corrected. + (merge b3b57c69da js/bugreport-no-suffix-fix later to maint). + + * The documentation for "%(trailers[:options])" placeholder in the + "--pretty" option of commands in the "git log" family has been + updated. + (merge bff85a338c bl/doc-key-val-sep-fix later to maint). + + * "git checkout --conflict=bad" reported a bad conflictStyle as if it + were given to a configuration variable; it has been corrected to + report that the command line option is bad. + (merge 5a99c1ac1a pw/checkout-conflict-errorfix later to maint). + + * Code clean-up in the "git log" machinery that implements custom log + message formatting. + (merge 1c10b8e5b0 jk/pretty-subject-cleanup later to maint). + + * "git config" corrupted literal HT characters written in the + configuration file as part of a value, which has been corrected. + (merge e6895c3f97 ds/config-internal-whitespace-fix later to maint). + + * A unit test for reftable code tried to enumerate all files in a + directory after reftable operations and expected to see nothing but + the files it wanted to leave there, but was fooled by .nfs* cruft + files left, which has been corrected. + (merge 0068aa7946 ps/reftable-unit-test-nfs-workaround later to maint). + + * The implementation and documentation of "object-format" option + exchange between the Git itself and its remote helpers did not + quite match, which has been corrected. + + * The "--pretty=<shortHand>" option of the commands in the "git log" + family, defined as "[pretty] shortHand = <expansion>" should have + been looked up case insensitively, but was not, which has been + corrected. + (merge f999d5188b bl/pretty-shorthand-config-fix later to maint). + + * "git apply" failed to extract the filename the patch applied to, + when the change was about an empty file created in or deleted from + a directory whose name ends with a SP, which has been corrected. + (merge 776ffd1a30 jc/apply-parse-diff-git-header-names-fix later to maint). + + * Update a more recent tutorial doc. + (merge 95ab557b4b dg/myfirstobjectwalk-updates later to maint). + + * The test script had an incomplete and ineffective attempt to avoid + clobbering the testing user's real crontab (and its equivalents), + which has been completed. + (merge 73cb87773b es/test-cron-safety later to maint). + + * Use advice_if_enabled() API to rewrite a simple pattern to + call advise() after checking advice_enabled(). + (merge 6412d01527 rj/use-adv-if-enabled later to maint). + + * Another "set -u" fix for the bash prompt (in contrib/) script. + (merge d7805bc743 vs/complete-with-set-u-fix later to maint). + + * "git checkout/switch --detach foo", after switching to the detached + HEAD state, gave the tracking information for the 'foo' branch, + which was pointless. + + * "git apply" has been updated to lift the hardcoded pathname length + limit, which in turn allowed a mksnpath() function that is no + longer used. + (merge 708f7e0590 rs/apply-lift-path-length-limit later to maint). + + * A file descriptor leak in an error codepath, used when "git apply + --reject" fails to create the *.rej file, has been corrected. + (merge 2b1f456adf rs/apply-reject-fd-leakfix later to maint). + + * A config parser callback function fell through instead of returning + after recognising and processing a variable, wasting cycles, which + has been corrected. + (merge a816ccd642 ds/fetch-config-parse-microfix later to maint). + + * Fix was added to work around a regression in libcURL 8.7.0 (which has + already been fixed in their tip of the tree). + (merge 92a209bf24 jk/libcurl-8.7-regression-workaround later to maint). + + * The variable that holds the value read from the core.excludefile + configuration variable used to leak, which has been corrected. + (merge 0e0fefb29f jc/unleak-core-excludesfile later to maint). + + * vreportf(), which is used by error() and friends, has been taught + to give the error message printf-format string when its vsnprintf() + call fails, instead of showing nothing useful to identify the + nature of the error. + (merge c63adab961 rs/usage-fallback-to-show-message-format later to maint). + + * Adjust to an upcoming changes to GNU make that breaks our Makefiles. + (merge 227b8fd902 tb/make-indent-conditional-with-non-spaces later to maint). + + * Git 2.44 introduced a regression that makes the updated code to + barf in repositories with multi-pack index written by older + versions of Git, which has been corrected. + + * When .git/rr-cache/ rerere database gets corrupted or rerere is fed to + work on a file with conflicted hunks resolved incompletely, the rerere + machinery got confused and segfaulted, which has been corrected. + (merge 167395bb47 mr/rerere-crash-fix later to maint). + + * The "receive-pack" program (which responds to "git push") was not + converted to run "git maintenance --auto" when other codepaths that + used to run "git gc --auto" were updated, which has been corrected. + (merge 7bf3057d9c ps/run-auto-maintenance-in-receive-pack later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge f0e578c69c rs/use-xstrncmpz later to maint). + (merge 83e6eb7d7a ba/credential-test-clean-fix later to maint). + (merge 64562d784d jb/doc-interactive-singlekey-do-not-need-perl later to maint). + (merge c431a235e2 cp/t9146-use-test-path-helpers later to maint). + (merge 82d75402d5 ds/doc-send-email-capitalization later to maint). + (merge 41bff66e35 jc/doc-add-placeholder-fix later to maint). + (merge 6835f0efe9 jw/remote-doc-typofix later to maint). + (merge 244001aa20 hs/rebase-not-in-progress later to maint). + (merge 2ca6c07db2 jc/no-include-of-compat-util-from-headers later to maint). + (merge 87bd7fbb9c rs/fetch-simplify-with-starts-with later to maint). + (merge f39addd0d9 rs/name-rev-with-mempool later to maint). + (merge 9a97b43e03 rs/submodule-prefix-simplify later to maint). + (merge 40b8076462 ak/rebase-autosquash later to maint). + (merge 3223204456 eg/add-uflags later to maint). + (merge 5f78d52dce es/config-doc-sort-sections later to maint). + (merge 781fb7b4c2 as/option-names-in-messages later to maint). + (merge 51d41dc243 jk/doc-remote-helpers-markup-fix later to maint). + (merge e1aaf309db pb/ci-win-artifact-names-fix later to maint). + (merge ad538c61da jc/index-pack-fsck-levels later to maint). + (merge 67471bc704 ja/doc-formatting-fix later to maint). + (merge 86f9ce7dd6 bl/doc-config-fixes later to maint). + (merge 0d527842b7 az/grep-group-error-message-update later to maint). + (merge 7c43bdf07b rs/strbuf-expand-bad-format later to maint). + (merge 8b68b48d5c ds/typofix-core-config-doc later to maint). + (merge 39bb692152 rs/imap-send-use-xsnprintf later to maint). + (merge 8d320cec60 jc/t2104-style-fixes later to maint). + (merge b4454d5a7b pw/t3428-cleanup later to maint). + (merge 84a7c33a4b pf/commitish-committish later to maint). + (merge 8882ee9d68 la/mailmap-entry later to maint). + (merge 44bdba2fa6 rs/no-openssl-compilation-fix-on-macos later to maint). + (merge f412d72c19 yb/replay-doc-linkfix later to maint). + (merge 5da40be8d7 xx/rfc2822-date-format-in-doc later to maint). diff --git a/Documentation/RelNotes/2.45.1.txt b/Documentation/RelNotes/2.45.1.txt new file mode 100644 index 0000000000..3b0d60cfa3 --- /dev/null +++ b/Documentation/RelNotes/2.45.1.txt @@ -0,0 +1,8 @@ +Git v2.45.1 Release Notes +========================= + +This release merges up the fix that appears in v2.39.4, +v2.40.2, v2.41.1, v2.42.2, v2.43.4 and v2.44.1 to address the +security issues CVE-2024-32002, CVE-2024-32004, CVE-2024-32020, +CVE-2024-32021 and CVE-2024-32465; see the release notes for +these versions for details. diff --git a/Documentation/RelNotes/2.45.2.txt b/Documentation/RelNotes/2.45.2.txt new file mode 100644 index 0000000000..13429e6491 --- /dev/null +++ b/Documentation/RelNotes/2.45.2.txt @@ -0,0 +1,26 @@ +Git v2.45.2 Release Notes +========================= + +In preparing security fixes for four CVEs, we made overly aggressive +"defense in depth" changes that broke legitimate use cases like 'git +lfs' and 'git annex.' This release is to revert these misguided, if +well-intentioned, changes that were shipped in 2.45.1 and were not +direct security fixes. + +Jeff King (5): + send-email: drop FakeTerm hack + send-email: avoid creating more than one Term::ReadLine object + ci: drop mention of BREW_INSTALL_PACKAGES variable + ci: avoid bare "gcc" for osx-gcc job + ci: stop installing "gcc-13" for osx-gcc + +Johannes Schindelin (6): + hook: plug a new memory leak + init: use the correct path of the templates directory again + Revert "core.hooksPath: add some protection while cloning" + tests: verify that `clone -c core.hooksPath=/dev/null` works again + clone: drop the protections where hooks aren't run + Revert "Add a helper function to compare file contents" + +Junio C Hamano (1): + Revert "fsck: warn about symlink pointing inside a gitdir" diff --git a/Documentation/RelNotes/2.45.3.txt b/Documentation/RelNotes/2.45.3.txt new file mode 100644 index 0000000000..2a1e9aa608 --- /dev/null +++ b/Documentation/RelNotes/2.45.3.txt @@ -0,0 +1,107 @@ +Git v2.45.3 Release Notes +========================= + +This primarily is to backport various small fixes accumulated on the +'master' front during the development towards Git 2.46, the next +feature release. + + +Fixes since v2.45.2 +------------------- + + * Git-GUI has a new maintainer, Johannes Sixt. + + * Tests that try to corrupt in-repository files in chunked format did + not work well on macOS due to its broken "mv", which has been + worked around. + + * The maximum size of attribute files is enforced more consistently. + + * Unbreak CI jobs so that we do not attempt to use Python 2 that has + been removed from the platform. + + * Git 2.43 started using the tree of HEAD as the source of attributes + in a bare repository, which has severe performance implications. + For now, revert the change, without ripping out a more explicit + support for the attr.tree configuration variable. + + * Windows CI running in GitHub Actions started complaining about the + order of arguments given to calloc(); the imported regex code uses + the wrong order almost consistently, which has been corrected. + + * The SubmittingPatches document now refers folks to manpages + translation project. + + * "git rebase --signoff" used to forget that it needs to add a + sign-off to the resulting commit when told to continue after a + conflict stops its operation. + + * The procedure to build multi-pack-index got confused by the + replace-refs mechanism, which has been corrected by disabling the + latter. + + * "git stash -S" did not handle binary files correctly, which has + been corrected. + + * A scheduled "git maintenance" job is expected to work on all + repositories it knows about, but it stopped at the first one that + errored out. Now it keeps going. + + * zsh can pretend to be a normal shell pretty well except for some + glitches that we tickle in some of our scripts. Work them around + so that "vimdiff" and our test suite works well enough with it. + + * Command line completion support for zsh (in contrib/) has been + updated to stop exposing internal state to end-user shell + interaction. + + * The documentation for "git diff --name-only" has been clarified + that it is about showing the names in the post-image tree. + + * The chainlint script (invoked during "make test") did nothing when + it failed to detect the number of available CPUs. It now falls + back to 1 CPU to avoid the problem. + + * "git init" in an already created directory, when the user + configuration has includeif.onbranch, started to fail recently, + which has been corrected. + + * The safe.directory configuration knob has been updated to + optionally allow leading path matches. + + * An overly large ".gitignore" files are now rejected silently. + + * Fix for an embarrassing typo that prevented Python2 tests from running + anywhere. + + * Varargs functions that are unannotated as printf-like or execl-like + have been annotated as such. + + * The "-k" and "--rfc" options of "format-patch" will now error out + when used together, as one tells us not to add anything to the + title of the commit, and the other one tells us to add "RFC" in + addition to "PATCH". + + * When the user adds to "git rebase -i" instruction to "pick" a merge + commit, the error experience is not pleasant. Such an error is now + caught earlier in the process that parses the todo list. + + * We forgot to normalize the result of getcwd() to NFC on macOS where + all other paths are normalized, which has been corrected. This still + does not address the case where core.precomposeUnicode configuration + is not defined globally. + + * Earlier we stopped using the tree of HEAD as the default source of + attributes in a bare repository, but failed to document it. This + has been corrected. + + * An unused extern declaration for mingw has been removed to prevent + it from causing build failure. + + * A helper function shared between two tests had a copy-paste bug, + which has been corrected. + + * "git fetch-pack -k -k" without passing "--lock-pack" (which we + never do ourselves) did not work at all, which has been corrected. + +Also contains various documentation updates and code clean-ups. diff --git a/Documentation/RelNotes/2.46.0.txt b/Documentation/RelNotes/2.46.0.txt new file mode 100644 index 0000000000..c06a04a91b --- /dev/null +++ b/Documentation/RelNotes/2.46.0.txt @@ -0,0 +1,461 @@ +Git v2.46 Release Notes +======================= + +UI, Workflows & Features + + * The "--rfc" option of "git format-patch" learned to take an + optional string value to be used in place of "RFC" to tweak the + "[PATCH]" on the subject header. + + * The credential helper protocol, together with the HTTP layer, have + been enhanced to support authentication schemes different from + username & password pair, like Bearer and NTLM. + + * Command line completion script (in contrib/) learned to complete + "git symbolic-ref" a bit better (you need to enable plumbing + commands to be completed with GIT_COMPLETION_SHOW_ALL_COMMANDS). + + * When the user responds to a prompt given by "git add -p" with an + unsupported command, list of available commands were given, which + was too much if the user knew what they wanted to type but merely + made a typo. Now the user gets a much shorter error message. + + * The color parsing code learned to handle 12-bit RGB colors, spelled + as "#RGB" (in addition to "#RRGGBB" that is already supported). + + * The operation mode options (like "--get") the "git config" command + uses have been deprecated and replaced with subcommands (like "git + config get"). + + * "git tag" learned the "--trailer" option to futz with the trailers + in the same way as "git commit" does. + + * A new global "--no-advice" option can be used to disable all advice + messages, which is meant to be used only in scripts. + + * Updates to symbolic refs can now be made as a part of ref + transaction. + + * The trailer API has been reshuffled a bit. + + * Terminology to call various ref-like things are getting + straightened out. + + * The command line completion script (in contrib/) has been adjusted + to the recent update to "git config" that adopted subcommand based + UI. + + * The knobs to tweak how reftable files are written have been made + available as configuration variables. + + * When "git push" notices that the commit at the tip of the ref on + the other side it is about to overwrite does not exist locally, it + used to first try fetching it if the local repository is a partial + clone. The command has been taught not to do so and immediately + fail instead. + + * The promisor.quiet configuration knob can be set to true to make + lazy fetching from promisor remotes silent. + + * The inter/range-diff output has been moved to the end of the patch + when format-patch adds it to a single patch, instead of writing it + before the patch text, to be consistent with what is done for a + cover letter for a multi-patch series. + + * A new command has been added to migrate a repository that uses the + files backend for its ref storage to use the reftable backend, with + limitations. + + * "git diff --exit-code --ext-diff" learned to take the exit status + of the external diff driver into account when deciding the exit + status of the overall "git diff" invocation when configured to do + so. + + * "git update-ref --stdin" learned to handle transactional updates of + symbolic-refs. + + * "git format-patch --interdiff" for multi-patch series learned to + turn on cover letters automatically (unless told never to enable + cover letter with "--no-cover-letter" and such). + + * The "--heads" option of "ls-remote" and "show-ref" has been + deprecated; "--branches" replaces "--heads". + + * For over a year, setting add.interactive.useBuiltin configuration + variable did nothing but giving a "this does not do anything" + warning. The warning has been removed. + + * The http transport can now be told to send request with + authentication material without first getting a 401 response. + + * A handful of entries are added to the GitFAQ document. + + * "git var GIT_SHELL_PATH" should report the path to the shell used + to spawn external commands, but it didn't do so on Windows, which + has been corrected. + + +Performance, Internal Implementation, Development Support etc. + + * Advertise "git contacts", a tool for newcomers to find people to + ask review for their patches, a bit more in our developer + documentation. + + * In addition to building the objects needed, try to link the objects + that are used in fuzzer tests, to make sure at least they build + without bitrot, in Linux CI runs. + + * Code to write out reftable has seen some optimization and + simplification. + + * Tests to ensure interoperability between reftable written by jgit + and our code have been added and enabled in CI. + + * The singleton index_state instance "the_index" has been eliminated + by always instantiating "the_repository" and replacing references + to "the_index" with references to its .index member. + + * Git-GUI has a new maintainer, Johannes Sixt. + + * The "test-tool" has been taught to run testsuite tests in parallel, + bypassing the need to use the "prove" tool. + + * The "whitespace check" task that was enabled for GitHub Actions CI + has been ported to GitLab CI. + + * The refs API lost functions that implicitly assumes to work on the + primary ref_store by forcing the callers to pass a ref_store as an + argument. + + * Code clean-up to reduce inter-function communication inside + builtin/config.c done via the use of global variables. + + * The pack bitmap code saw some clean-up to prepare for a follow-up topic. + + * Preliminary code clean-up for "git send-email". + + * The default "creation-factor" used by "git format-patch" has been + raised to make it more aggressively find matching commits. + + * Before discovering the repository details, We used to assume SHA-1 + as the "default" hash function, which has been corrected. Hopefully + this will smoke out codepaths that rely on such an unwarranted + assumptions. + + * The project decision making policy has been documented. + + * The strcmp-offset tests have been rewritten using the unit test + framework. + + * "git add -p" learned to complain when an answer with more than one + letter is given to a prompt that expects a single letter answer. + + * The alias-expanded command lines are logged to the trace output. + + * A new test was added to ensure git commands that are designed to + run outside repositories do work. + + * A few tests in reftable library have been rewritten using the + unit test framework. + + * A pair of test helpers that essentially are unit tests on hash + algorithms have been rewritten using the unit-tests framework. + + * A test helper that essentially is unit tests on the "decorate" + logic has been rewritten using the unit-tests framework. + + * Many memory leaks in the sparse-checkout code paths have been + plugged. + + * "make check-docs" noticed problems and reported to its output but + failed to signal its findings with its exit status, which has been + corrected. + + * Building with "-Werror -Wwrite-strings" is now supported. + + * To help developers, the build procedure now allows builders to use + CFLAGS_APPEND to specify additional CFLAGS. + + * "oidtree" tests were rewritten to use the unit test framework. + + * The structure of the document that records longer-term project + decisions to deprecate/remove/update various behaviour has been + outlined. + + * The pseudo-merge reachability bitmap to help more efficient storage + of the reachability bitmap in a repository with too many refs has + been added. + + * When "git merge" sees that the index cannot be refreshed (e.g. due + to another process doing the same in the background), it died but + after writing MERGE_HEAD etc. files, which was useless for the + purpose to recover from the failure. + + * The output from "git cat-file --batch-check" and "--batch-command + (info)" should not be unbuffered, for which some tests have been + added. + + * A CPP macro USE_THE_REPOSITORY_VARIABLE is introduced to help + transition the codebase to rely less on the availability of the + singleton the_repository instance. + + * "git version --build-options" reports the version information of + OpenSSL and other libraries (if used) in the build. + + * Memory ownership rules for the in-core representation of + remote.*.url configuration values have been straightened out, which + resulted in a few leak fixes and code clarification. + + * When bundleURI interface fetches multiple bundles, Git failed to + take full advantage of all bundles and ended up slurping duplicated + objects, which has been corrected. + + * The code to deal with modified paths that are out-of-cone in a + sparsely checked out working tree has been optimized. + + * An existing test of oidmap API has been rewritten with the + unit-test framework. + + * The "ort" merge backend saw one bugfix for a crash that happens + when inner merge gets killed, and assorted code clean-ups. + + * A new warning message is issued when a command has to expand a + sparse index to handle working tree cruft that are outside of the + sparse checkout. + + * The test framework learned to take the test body not as a single + string but as a here-document. + + * "git push '' HEAD:there" used to hit a BUG(); it has been corrected + to die with "fatal: bad repository ''". + + * What happens when http.cookieFile gets the special value "" has + been clarified in the documentation. + + +Fixes since v2.45 +----------------- + + * "git rebase --signoff" used to forget that it needs to add a + sign-off to the resulting commit when told to continue after a + conflict stops its operation. + + * The procedure to build multi-pack-index got confused by the + replace-refs mechanism, which has been corrected by disabling the + latter. + + * The "-k" and "--rfc" options of "format-patch" will now error out + when used together, as one tells us not to add anything to the + title of the commit, and the other one tells us to add "RFC" in + addition to "PATCH". + + * "git stash -S" did not handle binary files correctly, which has + been corrected. + + * A scheduled "git maintenance" job is expected to work on all + repositories it knows about, but it stopped at the first one that + errored out. Now it keeps going. + + * zsh can pretend to be a normal shell pretty well except for some + glitches that we tickle in some of our scripts. Work them around + so that "vimdiff" and our test suite works well enough with it. + + * Command line completion support for zsh (in contrib/) has been + updated to stop exposing internal state to end-user shell + interaction. + + * Tests that try to corrupt in-repository files in chunked format did + not work well on macOS due to its broken "mv", which has been + worked around. + + * The maximum size of attribute files is enforced more consistently. + + * Unbreak CI jobs so that we do not attempt to use Python 2 that has + been removed from the platform. + + * Git 2.43 started using the tree of HEAD as the source of attributes + in a bare repository, which has severe performance implications. + For now, revert the change, without ripping out a more explicit + support for the attr.tree configuration variable. + + * The "--exit-code" option of "git diff" command learned to work with + the "--ext-diff" option. + + * Windows CI running in GitHub Actions started complaining about the + order of arguments given to calloc(); the imported regex code uses + the wrong order almost consistently, which has been corrected. + + * Expose "name conflict" error when a ref creation fails due to D/F + conflict in the ref namespace, to improve an error message given by + "git fetch". + (merge 9339fca23e it/refs-name-conflict later to maint). + + * The SubmittingPatches document now refers folks to manpages + translation project. + + * The documentation for "git diff --name-only" has been clarified + that it is about showing the names in the post-image tree. + + * The credential helper that talks with osx keychain learned to avoid + storing back the authentication material it just got received from + the keychain. + (merge e1ab45b2da kn/osxkeychain-skip-idempotent-store later to maint). + + * The chainlint script (invoked during "make test") did nothing when + it failed to detect the number of available CPUs. It now falls + back to 1 CPU to avoid the problem. + + * Revert overly aggressive "layered defence" that went into 2.45.1 + and friends, which broke "git-lfs", "git-annex", and other use + cases, so that we can rebuild necessary counterparts in the open. + + * "git init" in an already created directory, when the user + configuration has includeif.onbranch, started to fail recently, + which has been corrected. + + * Memory leaks in "git mv" has been plugged. + + * The safe.directory configuration knob has been updated to + optionally allow leading path matches. + + * An overly large ".gitignore" files are now rejected silently. + + * Upon expiration event, the credential subsystem forgot to clear + in-core authentication material other than password (whose support + was added recently), which has been corrected. + + * Fix for an embarrassing typo that prevented Python2 tests from running + anywhere. + + * Varargs functions that are unannotated as printf-like or execl-like + have been annotated as such. + + * "git am" has a safety feature to prevent it from starting a new + session when there already is a session going. It reliably + triggers when a mbox is given on the command line, but it has to + rely on the tty-ness of the standard input. Add an explicit way to + opt out of this safety with a command line option. + (merge 62c71ace44 jk/am-retry later to maint). + + * A leak in "git imap-send" that somehow escapes LSan has been + plugged. + + * Setting core.abbrev too early before the repository set-up + (typically in "git clone") caused segfault, which as been + corrected. + + * When the user adds to "git rebase -i" instruction to "pick" a merge + commit, the error experience is not pleasant. Such an error is now + caught earlier in the process that parses the todo list. + + * We forgot to normalize the result of getcwd() to NFC on macOS where + all other paths are normalized, which has been corrected. This still + does not address the case where core.precomposeUnicode configuration + is not defined globally. + + * Earlier we stopped using the tree of HEAD as the default source of + attributes in a bare repository, but failed to document it. This + has been corrected. + + * "git update-server-info" and "git commit-graph --write" have been + updated to use the tempfile API to avoid leaving cruft after + failing. + + * An unused extern declaration for mingw has been removed to prevent + it from causing build failure. + + * A helper function shared between two tests had a copy-paste bug, + which has been corrected. + + * "git fetch-pack -k -k" without passing "--lock-pack" (which we + never do ourselves) did not work at all, which has been corrected. + + * CI job to build minimum fuzzers learned to pass NO_CURL=NoThanks to + the build procedure, as its build environment does not offer, or + the rest of the build needs, anything cURL. + (merge 4e66b5a990 jc/fuzz-sans-curl later to maint). + + * "git diff --no-ext-diff" when diff.external is configured ignored + the "--color-moved" option. + (merge 0f4b0d4cf0 rs/diff-color-moved-w-no-ext-diff-fix later to maint). + + * "git archive --add-virtual-file=<path>:<contents>" never paid + attention to the --prefix=<prefix> option but the documentation + said it would. The documentation has been corrected. + (merge 72c282098d jc/archive-prefix-with-add-virtual-file later to maint). + + * When GIT_PAGER failed to spawn, depending on the code path taken, + we failed immediately (correct) or just spew the payload to the + standard output (incorrect). The code now always fail immediately + when GIT_PAGER fails. + (merge 78f0a5d187 rj/pager-die-upon-exec-failure later to maint). + + * date parser updates to be more careful about underflowing epoch + based timestamp. + (merge 9d69789770 db/date-underflow-fix later to maint). + + * The Bloom filter used for path limited history traversal was broken + on systems whose "char" is unsigned; update the implementation and + bump the format version to 2. + (merge 9c8a9ec787 tb/path-filter-fix later to maint). + + * Typofix. + (merge 231cf7370e as/pathspec-h-typofix later to maint). + + * Code clean-up. + (merge 4b837f821e rs/simplify-submodule-helper-super-prefix-invocation later to maint). + + * "git describe --dirty --broken" forgot to refresh the index before + seeing if there is any chang, ("git describe --dirty" correctly did + so), which has been corrected. + (merge b8ae42e292 as/describe-broken-refresh-index-fix later to maint). + + * Test suite has been taught not to unnecessarily rely on DNS failing + a bogus external name. + (merge 407cdbd271 jk/tests-without-dns later to maint). + + * GitWeb update to use committer date consistently in rss/atom feeds. + (merge cf6ead095b am/gitweb-feed-use-committer-date later to maint). + + * Custom control structures we invented more recently have been + taught to the clang-format file. + (merge 1457dff9be rs/clang-format-updates later to maint). + + * Developer build procedure fix. + (merge df32729866 tb/dev-build-pedantic-fix later to maint). + + * "git push" that pushes only deletion gave an unnecessary and + harmless error message when push negotiation is configured, which + has been corrected. + (merge 4d8ee0317f jc/disable-push-nego-for-deletion later to maint). + + * Address-looking strings found on the trailer are now placed on the + Cc: list after running through sanitize_address by "git send-email". + (merge c852531f45 cb/send-email-sanitize-trailer-addresses later to maint). + + * Tests that use GIT_TEST_SANITIZE_LEAK_LOG feature got their exit + status inverted, which has been corrected. + (merge 8c1d6691bc rj/test-sanitize-leak-log-fix later to maint). + + * The http.cookieFile and http.saveCookies configuration variables + have a few values that need to be avoided, which are now ignored + with warning messages. + (merge 4f5822076f jc/http-cookiefile later to maint). + + * Repacking a repository with multi-pack index started making stupid + pack selections in Git 2.45, which has been corrected. + (merge 8fb6d11fad ds/midx-write-repack-fix later to maint). + + * Fix documentation mark-up regression in 2.45. + (merge 6474da0aa4 ja/doc-markup-updates-fix later to maint). + + * Work around asciidoctor's css that renders `monospace` material + in the SYNOPSIS section of manual pages as block elements. + (merge d44ce6ddd5 js/doc-markup-updates-fix later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge 493fdae046 ew/object-convert-leakfix later to maint). + (merge 00f3661a0a ss/doc-eol-attr-fix later to maint). + (merge 428c40da61 ri/doc-show-branch-fix later to maint). + (merge 58696bfcaa jc/where-is-bash-for-ci later to maint). + (merge 616e94ca24 tb/doc-max-tree-depth-fix later to maint). diff --git a/Documentation/RelNotes/2.46.1.txt b/Documentation/RelNotes/2.46.1.txt new file mode 100644 index 0000000000..e55c2c4a46 --- /dev/null +++ b/Documentation/RelNotes/2.46.1.txt @@ -0,0 +1,75 @@ +Git 2.46.1 Release Notes +======================== + +This release is primarily to merge fixes accumulated on the 'master' +front to prepare for 2.47 release that are still relevant to 2.46.x +maintenance track. + +Fixes since Git 2.46 +-------------------- + + * "git checkout --ours" (no other arguments) complained that the + option is incompatible with branch switching, which is technically + correct, but found confusing by some users. It now says that the + user needs to give pathspec to specify what paths to checkout. + + * It has been documented that we avoid "VAR=VAL shell_func" and why. + + * "git add -p" by users with diff.suppressBlankEmpty set to true + failed to parse the patch that represents an unmodified empty line + with an empty line (not a line with a single space on it), which + has been corrected. + + * "git rebase --help" referred to "offset" (the difference between + the location a change was taken from and the change gets replaced) + incorrectly and called it "fuzz", which has been corrected. + + * "git notes add -m '' --allow-empty" and friends that take prepared + data to create notes should not invoke an editor, but it started + doing so since Git 2.42, which has been corrected. + + * An expensive operation to prepare tracing was done in re-encoding + code path even when the tracing was not requested, which has been + corrected. + + * Perforce tests have been updated. + + * The credential helper to talk to OSX keychain sometimes sent + garbage bytes after the username, which has been corrected. + + * A recent update broke "git ls-remote" used outside a repository, + which has been corrected. + + * "git config --value=foo --fixed-value section.key newvalue" barfed + when the existing value in the configuration file used the + valueless true syntax, which has been corrected. + + * "git reflog expire" failed to honor annotated tags when computing + reachable commits. + + * A flakey test and incorrect calls to strtoX() functions have been + fixed. + + * Follow-up on 2.45.1 regression fix. + + * "git rev-list ... | git diff-tree -p --remerge-diff --stdin" should + behave more or less like "git log -p --remerge-diff" but instead it + crashed, forgetting to prepare a temporary object store needed. + + * The patch parser in "git patch-id" has been tightened to avoid + getting confused by lines that look like a patch header in the log + message. + + * "git bundle unbundle" outside a repository triggered a BUG() + unnecessarily, which has been corrected. + + * The code forgot to discard unnecessary in-core commit buffer data + for commits that "git log --skip=<number>" traversed but omitted + from the output, which has been corrected. + + * "git verify-pack" and "git index-pack" started dying outside a + repository, which has been corrected. + + * A corner case bug in "git stash" was fixed. + +Also contains minor documentation updates and code clean-ups. diff --git a/Documentation/RelNotes/2.46.2.txt b/Documentation/RelNotes/2.46.2.txt new file mode 100644 index 0000000000..613386878d --- /dev/null +++ b/Documentation/RelNotes/2.46.2.txt @@ -0,0 +1,23 @@ +Git 2.46.2 Release Notes +======================== + +This release is primarily to merge changes to unbreak the 32-bit +GitHub actions jobs we use for CI testing, so that we can release +real fixes for the 2.46.x track after they pass CI. + +It also reverts the "git patch-id" change that went into 2.46.1, +as it seems to have got a regression reported (I haven't verified, +but it is better to keep a known breakage than adding an unintended +regression). + +Other than that, a handful of minor bugfixes are included. + + * In a few corner cases "git diff --exit-code" failed to report + "changes" (e.g., renamed without any content change), which has + been corrected. + + * Cygwin does have /dev/tty support that is needed by things like + single-key input mode. + + * The interpret-trailers command failed to recognise the end of the + message when the commit log ends in an incomplete line. diff --git a/Documentation/RelNotes/2.47.0.txt b/Documentation/RelNotes/2.47.0.txt new file mode 100644 index 0000000000..b63c3364af --- /dev/null +++ b/Documentation/RelNotes/2.47.0.txt @@ -0,0 +1,342 @@ +Git v2.47 Release Notes +======================= + +UI, Workflows & Features +------------------------ + + * Many Porcelain commands that internally use the merge machinery + were taught to consistently honor the diff.algorithm configuration. + + * A few descriptions in "git show-ref -h" have been clarified. + + * A 'P' command to "git add -p" that passes the patch hunk to the + pager has been added. + + * "git grep -W" omits blank lines that follow the found function at + the end of the file, just like it omits blank lines before the next + function. + + * The value of http.proxy can have "path" at the end for a socks + proxy that listens to a unix-domain socket, but we started to + discard it when we taught proxy auth code path to use the + credential helpers, which has been corrected. + + * The code paths to compact multiple reftable files have been updated + to correctly deal with multiple compaction triggering at the same + time. + + * Support to specify ref backend for submodules has been enhanced. + + * "git svn" has been taught about svn:global-ignores property + recent versions of Subversion has. + + * The default object hash and ref backend format used to be settable + only with explicit command line option to "git init" and + environment variables, but now they can be configured in the user's + global and system wide configuration. + + * "git send-email" learned "--translate-aliases" option that reads + addresses from the standard input and emits the result of applying + aliases on them to the standard output. + + * 'git for-each-ref' learned a new "--format" atom to find the branch + that the history leading to a given commit "%(is-base:<commit>)" is + likely based on. + + * The command line prompt support used to be littered with bash-isms, + which has been corrected to work with more shells. + + * Support for the RUNTIME_PREFIX feature has been added to z/OS port. + + * "git send-email" learned "--mailmap" option to allow rewriting the + recipient addresses. + + * "git mergetool" learned to use VSCode as a merge backend. + + * "git pack-redundant" has been marked for removal in Git 3.0. + + * One-line messages to "die" and other helper functions will get LF + added by these helper functions, but many existing messages had an + unnecessary LF at the end, which have been corrected. + + * The "scalar clone" command learned the "--no-tags" option. + + * The environment GIT_ADVICE has been intentionally kept undocumented + to discourage its use by interactive users. Add documentation to + help tool writers. + + * "git apply --3way" learned to take "--ours" and other options. + + +Performance, Internal Implementation, Development Support etc. +-------------------------------------------------------------- + + * A build tweak knob has been simplified by not setting the value + that is already the default; another unused one has been removed. + + * A CI job that use clang-format to check coding style issues in new + code has been added. + + * The reviewing guidelines document now explicitly encourages people + to give positive reviews and how. + + * Test script linter has been updated to catch an attempt to use + one-shot export construct "VAR=VAL func" for shell functions (which + does not work for some shells) better. + + * Some project conventions have been added to CodingGuidelines. + + * In the refs subsystem, implicit reliance of the_repository has been + eliminated; the repository associated with the ref store object is + used instead. + + * Various tests in reftable library have been rewritten using the unit test + framework. + + * A test that fails on an unusually slow machine was found, and made + less likely to cause trouble by lengthening the expiry value it + uses. + + * An existing test of hashmap API has been rewritten with the + unit-test framework. + + * A policy document that describes platform support levels and + expectation on platform stakeholders has been introduced. + + * The refs API has been taught to give symref target information to + the users of ref iterators, allowing for-each-ref and friends to + avoid an extra ref_resolve_* API call per a symbolic ref. + + * Unit-test framework has learned a simple control structure to allow + embedding test statements in-line instead of having to create a new + function to contain them. + + * Incremental updates of multi-pack index files is getting worked on. + + * Use of API functions that implicitly depend on the_repository + object in the config subsystem has been rewritten to pass a + repository object through the callchain. + + * Unused parameters have been either marked as UNUSED to squelch + -Wunused warnings or dropped from many functions.. + + * The code in the reftable library has been cleaned up by discarding + unused "generic" interface. + + * The underlying machinery for "git diff-index" has long been made to + expand the sparse index as needed, but the command fully expanded + the sparse index upfront, which now has been taught not to do. + + * More trace2 events at key points on push and fetch code paths have + been added. + + * Make our codebase compilable with the -Werror=unused-parameter + option. + + * "git cat-file" works well with the sparse-index, and gets marked as + such. + + * CI started failing completely for linux32 jobs, as the step to + upload failed test directory uses GitHub actions that is deprecated + and is now disabled. + + * Import clar unit tests framework libgit2 folks invented for our + use. + + * The error messages from the test script checker have been improved. + + * The convention to calling into built-in command implementation has + been updated to pass the repository, if known, together with the + prefix value. + + * "git apply" had custom buffer management code that predated before + use of strbuf got widespread, which has been updated to use strbuf, + which also plugged some memory leaks. + + * The reftable backend learned to more efficiently handle exclude + patterns while enumerating the refs. + + * CI updates. FreeBSD image has been updated to 13.4. + (merge 2eeb29702e cb/ci-freebsd-13-4 later to maint). + + * Give timeout to the locking code to write to reftable, instead of + failing on the first failure without retrying. + + * The checksum at the tail of files are now computed without + collision detection protection. This is safe as the consumer of + the information to protect itself from replay attacks checks for + hash collisions independently. + + +Fixes since v2.46 +----------------- + + * "git add -p" by users with diff.suppressBlankEmpty set to true + failed to parse the patch that represents an unmodified empty line + with an empty line (not a line with a single space on it), which + has been corrected. + + * "git checkout --ours" (no other arguments) complained that the + option is incompatible with branch switching, which is technically + correct, but found confusing by some users. It now says that the + user needs to give pathspec to specify what paths to checkout. + + * It has been documented that we avoid "VAR=VAL shell_func" and why. + + * "git rebase --help" referred to "offset" (the difference between + the location a change was taken from and the change gets replaced) + incorrectly and called it "fuzz", which has been corrected. + + * "git notes add -m '' --allow-empty" and friends that take prepared + data to create notes should not invoke an editor, but it started + doing so since Git 2.42, which has been corrected. + + * An expensive operation to prepare tracing was done in re-encoding + code path even when the tracing was not requested, which has been + corrected. + + * More leakfixes. + + * The credential helper to talk to OSX keychain sometimes sent + garbage bytes after the username, which has been corrected. + + * A recent update broke "git ls-remote" used outside a repository, + which has been corrected. + + * The patch parser in 'git apply' has been a bit more lenient against + unexpected mode bits, like 100664, recorded on extended header lines. + + * "git config --value=foo --fixed-value section.key newvalue" barfed + when the existing value in the configuration file used the + valueless true syntax, which has been corrected. + + * The patch parser in "git patch-id" has been tightened to avoid + getting confused by lines that look like a patch header in the log + message. + + * "git reflog expire" failed to honor annotated tags when computing + reachable commits. + + * A flakey test and incorrect calls to strtoX() functions have been + fixed. + + * Follow-up on 2.45.1 regression fix. + + * "git rev-list ... | git diff-tree -p --remerge-diff --stdin" should + behave more or less like "git log -p --remerge-diff" but instead it + crashed, forgetting to prepare a temporary object store needed. + + * "git bundle unbundle" outside a repository triggered a BUG() + unnecessarily, which has been corrected. + + * Maintenance tasks other than "gc" now properly go background when + "git maintenance" runs them. + + * We created a useless pseudo-merge reachability bitmap that is about + 0 commits, and attempted to include commits that are not in packs, + which made no sense. These bugs have been corrected. + (merge a72dfab8b8 tb/pseudo-merge-bitmap-fixes later to maint). + + * "git rebase -x --quiet" was not quiet, which was corrected. + + * The code path for compacting reftable files saw some bugfixes + against concurrent operation. + + * The code forgot to discard unnecessary in-core commit buffer data + for commits that "git log --skip=<number>" traversed but omitted + from the output, which has been corrected. + + * "git verify-pack" and "git index-pack" started dying outside a + repository, which has been corrected. + + * A data corruption bug when multi-pack-index is used and the same + objects are stored in multiple packfiles has been corrected. + + * "git pack-refs --auto" for the files backend was too aggressive, + which has been a bit tamed. + (merge c3459ae9ef ps/pack-refs-auto-heuristics later to maint). + + * A file descriptor left open is now properly closed when "git + sparse-checkout" updates the sparse patterns. + + * In a few corner cases "git diff --exit-code" failed to report + "changes" (e.g., renamed without any content change), which has + been corrected. + + * Cygwin does have /dev/tty support that is needed by things like + single-key input mode. + + * The interpret-trailers command failed to recognise the end of the + message when the commit log ends in an incomplete line. + + * "git rebase --autostash" failed to resurrect the autostashed + changes when the command gets aborted after giving back control + asking for hlep in conflict resolution. + (merge bf6ab087d1 pw/rebase-autostash-fix later to maint). + + * The "imap-send" now allows to be compiled with NO_OPENSSL and + OPENSSL_SHA1 defined together. + (merge 997950a750 jk/no-openssl-with-openssl-sha1 later to maint). + + * The support to customize build options to adjust for older versions + and/or older systems for the interop tests has been improved. + (merge 22ef5f02a8 jk/interop-test-build-options later to maint). + + * Update the character width table for Unicode 16. + (merge 44dc651132 bb/unicode-width-table-16 later to maint). + + * In Git 2.39, Git.pm stopped working in a bare repository, which has + been corrected. + (merge d3edb0bdde jk/git-pm-bare-repo-fix later to maint). + + * When a remote-helper dies before Git writes to it, SIGPIPE killed + Git silently. We now explain the situation a bit better to the end + user in our error message. + (merge 6e7fac9bca jk/diag-unexpected-remote-helper-death later to maint). + + * A few usability fixes to "git jump" (in contrib/). + (merge 083b82544d jk/jump-quickfix-fixes later to maint). + + * "git diff --exit-code" ignored modified binary files, which has + been corrected. + (merge 9a41735af6 rs/diff-exit-code-binary later to maint). + + * When a subprocess to work in a submodule spawned by "git submodule" + fails with SIGPIPE, the parent Git process caught the death of it, + but gave a generic "failed to work in that submodule", which was + misleading. We now behave as if the parent got SIGPIPE and die. + (merge 082caf527e pw/submodule-process-sigpipe later to maint). + + * "git archive" with pathspec magic that uses the attribute + information did not work well, which has been corrected. + (merge 296743a7ca rs/archive-with-attr-pathspec-fix later to maint). + + * Background tasks "git maintenance" runs may need to use credential + information when going over the network, but a credential helper + may work only in an interactive environment, and end up blocking a + scheduled task waiting for UI. Credential helpers can now behave + differently when they are not running interactively. + (merge b9183b0a02 ds/background-maintenance-with-credential later to maint). + + * "git --git-dir=nowhere cmd" failed to properly notice that it + wasn't in any repository while processing includeIf.onbranch + configuration and instead crashed. + + * When "git sparse-checkout disable" turns a sparse checkout into a + regular checkout, the index is fully expanded. This totally + expected behaviour however had an "oops, we are expanding the + index" advice message, which has been corrected. + (merge 537e516a39 ds/sparse-checkout-expansion-advice later to maint). + + * macOS with fsmonitor daemon can hang forever when a submodule is + involved, which has been corrected. + + * Other code cleanup, docfix, build fix, etc. + (merge be10ac7037 jc/mailinfo-header-cleanup later to maint). + (merge 4460e052e0 jc/range-diff-lazy-setup later to maint). + (merge 0627c58e7a ak/typofixes later to maint). + (merge 83799f1500 jk/t9001-deflake later to maint). + (merge e02cc08a88 ak/typofix-2.46-maint later to maint). + (merge 5c5d29e1c4 ps/ci-gitlab-upgrade later to maint). + (merge 9c4c840901 jc/doc-discarding-stalled-topics later to maint). + (merge 5e6f359f6b ds/read-cache-mempool-leakfix later to maint). diff --git a/Documentation/RelNotes/2.47.1.txt b/Documentation/RelNotes/2.47.1.txt new file mode 100644 index 0000000000..39206c09fd --- /dev/null +++ b/Documentation/RelNotes/2.47.1.txt @@ -0,0 +1,31 @@ +Git 2.47.1 Release Notes +======================== + +This is to flush accumulated fixes since 2.47.0 on the 'master' +front down to the maintenance track. + + +Fixes since Git 2.47 +-------------------- + + * Use after free and double freeing at the end in "git log -L... -p" + had been identified and fixed. + + * On macOS, fsmonitor can fall into a race condition that results in + a client waiting forever to be notified for an event that have + already happened. This problem has been corrected. + + * "git maintenance start" crashed due to an uninitialized variable + reference, which has been corrected. + + * Fail gracefully instead of crashing when attempting to write the + contents of a corrupt in-core index as a tree object. + + * A "git fetch" from the superproject going down to a submodule used + a wrong remote when the default remote names are set differently + between them. + + * The "gitk" project tree has been synchronized again with its new + maintainer, Johannes Sixt. + +Also contains minor documentation updates and code clean-ups. diff --git a/Documentation/RelNotes/2.48.0.txt b/Documentation/RelNotes/2.48.0.txt new file mode 100644 index 0000000000..a949a103b1 --- /dev/null +++ b/Documentation/RelNotes/2.48.0.txt @@ -0,0 +1,195 @@ +Git v2.48 Release Notes +======================= + +UI, Workflows & Features +------------------------ + + * A new configuration variable remote.<name>.serverOption makes the + transport layer act as if the --serverOption=<value> option is + given from the command line. + + * "git rebase --rebase-merges" now uses branch names as labels when + able. + + * Describe the policy to introduce breaking changes. + + * Teach 'git notes add' and 'git notes append' a new '-e' flag, + instructing them to open the note in $GIT_EDITOR before saving. + + * Documentation for "git bundle" saw improvements to more prominently + call out the use of '--all' when creating bundles. + + +Performance, Internal Implementation, Development Support etc. +-------------------------------------------------------------- + + * Document "amlog" notes. + (merge ddfb5bcfc6 tb/notes-amlog-doc later to maint). + + * The way AsciiDoc is used for SYNOPSIS part of the manual pages has + been revamped. The sources, at least for the simple cases, got + vastly pleasant to work with. + + * The reftable library is now prepared to expect that the memory + allocation function given to it may fail to allocate and to deal + with such an error. + + * An extra worktree attached to a repository points at each other to + allow finding the repository from the worktree and vice versa + possible. Turn this linkage to relative paths. + + * Enable Windows-based CI in GitLab. + + * Commands that can also work outside Git have learned to take the + repository instance "repo" when we know we are in a repository, and + NULL when we are not, in a parameter. The uses of the_repository + variable in a few of them have been removed using the new calling + convention. + + * The reftable sub-system grew a new reftable-specific strbuf + replacement to reduce its dependency on Git-specific data + structures. + + * The ref-filter machinery learns to recognize and avoid cases where + sorting would be redundant. + + * Various platform compatibility fixes split out of the larger effort + to use Meson as the primary build tool. + + * Treat ECONNABORTED the same as ECONNRESET in 'git credential-cache' + to work around a possible Cygwin regression. This resolves a race + condition caused by changes in Cygwin's handling of socket + closures, allowing the client to exit cleanly when encountering + ECONNABORTED. + + * Demonstrate an assertion failure in 'git mv'. + + * Documentation update to clarify that 'uploadpack.allowAnySHA1InWant' + implies both 'allowTipSHA1InWant' and 'allowReachableSHA1InWant'. + + * Replace various calls to atoi() with strtol_i() and strtoul_ui(), + and add improved error handling. + + * Documentation updates to 'git-update-ref(1)'. + + * Update the project's CodingGuidelines to discourage naming functions + with a "_1()" suffix. + + * Updates the '.clang-format' to match project conventions. + + * Centralize documentation for repository extensions into a single place. + + * Buildfix and upgrade of Clar to a newer version. + + * Documentation mark-up updates. + + * Renaming a handful of variables and structure fields. + + * Fix for clar unit tests to support CMake build. + + * C23 compatibility updates. + + * GCC 15 compatibility updates. + + * We now ensure "index-pack" is used with the "--promisor" option + only during a "git fetch". + + +Fixes since v2.47 +----------------- + + * Doc update to clarify how periodical maintenance are scheduled, + spread across time to avoid thundering hurds. + (merge 3d6ab4177d sk/doc-maintenance-schedule later to maint). + + * Use after free and double freeing at the end in "git log -L... -p" + had been identified and fixed. + + * On macOS, fsmonitor can fall into a race condition that results in + a client waiting forever to be notified for an event that have + already happened. This problem has been corrected. + + * "git maintenance start" crashed due to an uninitialized variable + reference, which has been corrected. + + * Fail gracefully instead of crashing when attempting to write the + contents of a corrupt in-core index as a tree object. + + * A "git fetch" from the superproject going down to a submodule used + a wrong remote when the default remote names are set differently + between them. + + * Fixes compile time warnings with 64-bit MSVC. + + * Teaches 'shortlog' to explicitly use SHA-1 when operating outside + of a repository. + + * Fix 'git grep' regression on macOS by disabling lookahead when + encountering invalid UTF-8 byte sequences. + + * The dumb-http code regressed when the result of re-indexing a pack + yielded an *.idx file that differs in content from the *.idx file + it downloaded from the remote. This has been corrected by no longer + relying on: the *.idx file we got from the remote. + + * When called with '--left-right' and '--use-bitmap-index', 'rev-list' + will produce output without any left/right markers, which has been + corrected. + + * More leakfixes. + + * Test modernization. + + * The "--shallow-exclude=<ref>" option to various history transfer + commands takes a ref, not an arbitrary revision. + + * A regression where commit objects missing from a commit-graph can + cause an infinite loop when doing a fetch in a partial clone has + been fixed. + + * The MinGW compatibility layer has been taught to support POSIX + semantics for atomic renames when other process(es) have a file + opened at the destination path. + + * "git gc" discards any objects that are outside promisor packs that + are referred to by an object in a promisor pack, and we do not + refetch them from the promisor at runtime, resulting an unusable + repository. Work it around by including these objects in the + referring promisor pack at the receiving end of the fetch. + + * Avoid build/test breakage on a system without working malloc debug + support dynamic library. + (merge 72ad6dc368 jk/test-malloc-debug-check later to maint). + + * Double-free fix. + (merge fe17a25905 jk/fetch-prefetch-double-free-fix later to maint). + + * Use of some uninitialized variables in "git difftool" has been + corrected. + + * Object reuse code based on multi-pack-index sent an unwanted copy + of object. + (merge e199290592 tb/multi-pack-reuse-dupfix later to maint). + + * "git fast-import" can be tricked into a replace ref that maps an + object to itself, which is a useless thing to do. + (merge 5e904f1a4a en/fast-import-avoid-self-replace later to maint). + + * The ref-transaction hook triggered for reflog updates, which has + been corrected. + (merge b886db48c6 kn/ref-transaction-hook-with-reflog later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge 1164e270b5 jk/output-prefix-cleanup later to maint). + (merge f36b8cbaef jh/config-unset-doc-fix later to maint). + (merge 4154ed4108 js/doc-platform-support-link-fix later to maint). + (merge 77af53f56f aa/t7300-modernize later to maint). + (merge 8ead1bba3e jc/doc-refspec-syntax later to maint). + (merge 432f666aa6 kn/loose-object-layer-wo-global-hash later to maint). + (merge c4b8fb6ef2 kh/merge-tree-doc later to maint). + (merge b8139c8f4e kh/checkout-ignore-other-docfix later to maint). + (merge 6dab49b9fb tc/bundle-uri-leakfix later to maint). + (merge f1ed39987b xx/protocol-v2-doc-markup-fix later to maint). + (merge 41869f7447 ak/typofixes later to maint). + (merge dcd590a39d bf/t-readme-mention-reftable later to maint). + (merge 68e3c69efa kh/trailer-in-glossary later to maint). diff --git a/Documentation/ReviewingGuidelines.txt b/Documentation/ReviewingGuidelines.txt index 0e323d5477..6534643cff 100644 --- a/Documentation/ReviewingGuidelines.txt +++ b/Documentation/ReviewingGuidelines.txt @@ -19,7 +19,7 @@ Principles Selecting patch(es) to review ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you are looking for a patch series in need of review, start by checking -latest "What's cooking in git.git" email +the latest "What's cooking in git.git" email (https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/[example]). The "What's cooking" emails & replies can be found using the query `s:"What's cooking"` on the https://lore.kernel.org/git/[`lore.kernel.org` mailing list archive]; @@ -72,12 +72,29 @@ guidance, and concrete tips for interacting with patches on the mailing list. could fix it. This not only helps the author to understand and fix the issue, it also deepens and improves your understanding of the topic. -- Reviews do not need to exclusively point out problems. Feel free to "think out +- Reviews do not need to exclusively point out problems. Positive + reviews indicate that it is not only the original author of the + patches who care about the issue the patches address, and are + highly encouraged. + +- Do not hesitate to give positive reviews on a series from your + work colleague. If your positive review is written well, it will + not make you look as if you two are representing corporate + interest on a series that is otherwise uninteresting to other + community members and shoving it down their throat. + +- Write a positive review in such a way that others can understand + why you support the goal, the approach, and the implementation the + patches took. Make sure to demonstrate that you did thoroughly read + the series and understood problem area well enough to be able to + say that the patches are written well. Feel free to "think out loud" in your review: describe how you read & understood a complex section of a patch, ask a question about something that confused you, point out something - you found exceptionally well-written, etc. In particular, uplifting feedback - goes a long way towards encouraging contributors to participate more actively - in the Git community. + you found exceptionally well-written, etc. + +- In particular, uplifting feedback goes a long way towards + encouraging contributors to participate more actively in the Git + community. ==== Performing your review - Provide your review comments per-patch in a plaintext "Reply-All" email to the @@ -126,7 +143,7 @@ Terminology ----------- nit: :: Denotes a small issue that should be fixed, such as a typographical error - or mis-alignment of conditions in an `if()` statement. + or misalignment of conditions in an `if()` statement. aside: :: optional: :: diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 973d7a81d4..db17bc7fe2 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -7,6 +7,73 @@ Here are some guidelines for contributing back to this project. There is also a link:MyFirstContribution.html[step-by-step tutorial] available which covers many of these same guidelines. +[[patch-flow]] +=== A typical life cycle of a patch series + +To help us understand the reason behind various guidelines given later +in the document, first let's understand how the life cycle of a +typical patch series for this project goes. + +. You come up with an itch. You code it up. You do not need any + pre-authorization from the project to do so. ++ +Your patches will be reviewed by other contributors on the mailing +list, and the reviews will be done to assess the merit of various +things, like the general idea behind your patch (including "is it +solving a problem worth solving in the first place?"), the reason +behind the design of the solution, and the actual implementation. +The guidelines given here are there to help your patches by making +them easier to understand by the reviewers. + +. You send the patches to the list and cc people who may need to know + about the change. Your goal is *not* necessarily to convince others + that what you are building is good. Your goal is to get help in + coming up with a solution for the "itch" that is better than what + you can build alone. ++ +The people who may need to know are the ones who worked on the code +you are touching. 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 them for help, +you don't demand). +git log -p {litdd} _$area_you_are_modifying_+ would +help you find out who they are. + +. You get comments and suggestions for improvements. You may even get + them in an "on top of your change" patch form. You are expected to + respond to them with "Reply-All" on the mailing list, while taking + them into account while preparing an updated set of patches. + +. Polish, refine, and re-send your patches to the list and to the people + who spent their time to improve your patch. Go back to step (2). + +. While the above iterations improve your patches, the maintainer may + pick the patches up from the list and queue them to the `seen` + branch, in order to make it easier for people to play with it + without having to pick up and apply the patches to their trees + themselves. Being in `seen` has no other meaning. Specifically, it + does not mean the patch was "accepted" in any way. + +. When the discussion reaches a consensus that the latest iteration of + the patches are in good enough shape, the maintainer includes the + topic in the "What's cooking" report that are sent out a few times a + week to the mailing list, marked as "Will merge to 'next'." This + decision is primarily made by the maintainer with help from those + who participated in the review discussion. + +. After the patches are merged to the 'next' branch, the discussion + can still continue to further improve them by adding more patches on + top, but by the time a topic gets merged to 'next', it is expected + that everybody agrees that the scope and the basic direction of the + topic are appropriate, so such an incremental updates are limited to + small corrections and polishing. After a topic cooks for some time + (like 7 calendar days) in 'next' without needing further tweaks on + top, it gets merged to the 'master' branch and wait to become part + of the next major release. + +In the following sections, many techniques and conventions are listed +to help your patches get reviewed effectively in such a life cycle. + + [[choose-starting-point]] === Choose a starting point. @@ -87,7 +154,7 @@ maintainer. Under truly exceptional circumstances where you absolutely must depend on a select few topic branches that are already in `next` but not in `master`, you may want to create your own custom base-branch by forking -`master` and merging the required topic branches to it. You could then +`master` and merging the required topic branches into it. You could then work on top of this base-branch. But keep in mind that this base-branch would only be known privately to you. So when you are ready to send your patches to the list, be sure to communicate how you created it in @@ -192,8 +259,9 @@ reasons: which case, they can explain why they extend your code to cover files, too). -The goal of your log message is to convey the _why_ behind your -change to help future developers. +The goal of your log message is to convey the _why_ behind your change +to help future developers. The reviewers will also make sure that +your proposed log message will serve this purpose well. The first line of the commit message should be a short description (50 characters is the soft limit, see DISCUSSION in linkgit:git-commit[1]), @@ -266,7 +334,7 @@ date)", like this: noticed that ... .... -The "Copy commit summary" command of gitk can be used to obtain this +The "Copy commit reference" 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`: @@ -344,20 +412,32 @@ Also notice that a real name is used in the `Signed-off-by` trailer. Please don't hide your real name. [[commit-trailers]] -If you like, you can put extra tags at the end: +If you like, you can put extra trailers at the end: . `Reported-by:` is used to credit someone who found the bug that the patch attempts to fix. . `Acked-by:` says that the person who is more familiar with the area the patch attempts to modify liked the patch. -. `Reviewed-by:`, unlike the other tags, can only be offered by the +. `Reviewed-by:`, unlike the other trailers, can only be offered by the reviewers themselves when they are completely satisfied with the patch after a detailed analysis. . `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:". +. `Co-authored-by:` is used to indicate that people exchanged drafts + of a patch before submitting it. +. `Helped-by:` is used to credit someone who suggested ideas for + changes without providing the precise changes in patch form. +. `Mentored-by:` is used to credit someone with helping develop a + patch as part of a mentorship program (e.g., GSoC or Outreachy). +. `Suggested-by:` is used to credit someone with suggesting the idea + for a patch. + +While you can also create your own trailer if the situation warrants it, we +encourage you to instead use one of the common trailers in this project +highlighted above. + +Only capitalize the very first letter of the trailer, i.e. favor +"Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By". [[git-tools]] === Generate your patch using Git tools out of your commits. @@ -385,16 +465,56 @@ letter. [[send-patches]] === Sending your patches. +==== Choosing your reviewers + :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 +NOTE: 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 +:contrib-scripts: footnoteref:[contrib-scripts,Scripts under `contrib/` are + +not part of the core `git` binary and must be called directly. Clone the Git + +codebase and run `perl contrib/contacts/git-contacts`.] + +Send your patch with "To:" set to the mailing list, with "cc:" listing +people who are involved in the area you are touching (the `git-contacts` +script in `contrib/contacts/`{contrib-scripts} can help to +identify them), to solicit comments and reviews. Also, when you made +trial merges of your topic to `next` and `seen`, you may have noticed +work by others conflicting with your changes. There is a good possibility +that these people may know the area you are touching well. + +If you are using `send-email`, you can feed it the output of `git-contacts` like +this: + +.... + git send-email --cc-cmd='perl contrib/contacts/git-contacts' feature/*.patch +.... + +:current-maintainer: footnote:[The current maintainer: gitster@pobox.com] +:git-ml: footnote:[The mailing list: git@vger.kernel.org] + +After the list reached a consensus that it is a good idea to apply the +patch, re-send it with "To:" set to the maintainer{current-maintainer} +and "cc:" the list{git-ml} for inclusion. This is especially relevant +when the maintainer did not heavily participate in the discussion and +instead left the review to trusted others. + +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, and "cc:" them when sending such a final version for inclusion. + +==== `format-patch` and `send-email` + +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. +your existing e-mail client (often optimized for "multipart/*" MIME +type e-mails) might render your patches unusable. + +NOTE: Here we outline the procedure using `format-patch` and +`send-email`, but you can instead use GitGitGadget to send in your +patches (see link:MyFirstContribution.html[MyFirstContribution]). People on the Git mailing list need to be able to read and comment on the changes you are submitting. It is important for @@ -403,10 +523,12 @@ e-mail tools, so that they may comment on specific portions of your code. For this reason, each patch should be submitted "inline" in a separate message. -Multiple related patches should be grouped into their own e-mail -thread to help readers find all parts of the series. To that end, -send them as replies to either an additional "cover letter" message -(see below), the first patch, or the respective preceding patch. +All subsequent versions of a patch series and other 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. +Here is a link:MyFirstContribution.html#v2-git-send-email[step-by-step guide] on +how to submit updated versions of a patch series. If your log message (including your name on the `Signed-off-by` trailer) is not writable in ASCII, make sure that @@ -447,6 +569,18 @@ 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`. +[[the-topic-summary]] +*This is EXPERIMENTAL*. + +When sending a topic, you can propose a one-paragraph summary that +should appear in the "What's cooking" report when it is picked up to +explain the topic. If you choose to do so, please write a 2-5 line +paragraph that will fit well in our release notes (see many bulleted +entries in the Documentation/RelNotes/* files for examples), and make +it the first paragraph of the cover letter. For a single-patch +series, use the space between the three-dash line and the diffstat, as +described earlier. + [[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 @@ -474,49 +608,100 @@ patch, format it as "multipart/signed", not a text/plain message that starts with `-----BEGIN PGP SIGNED MESSAGE-----`. That is not a text/plain, it's something else. -:security-ml-ref: footnoteref:[security-ml] +=== Handling Conflicts and Iterating Patches -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}. +When revising changes made to your patches, it's important to +acknowledge the possibility of conflicts with other ongoing topics. To +navigate these potential conflicts effectively, follow the recommended +steps outlined below: -Send your patch with "To:" set to the mailing list, with "cc:" listing -people who are involved in the area you are touching (the `git -contacts` command in `contrib/contacts/` can help to -identify them), to solicit comments and reviews. Also, when you made -trial merges of your topic to `next` and `seen`, you may have noticed -work by others conflicting with your changes. There is a good possibility -that these people may know the area you are touching well. +. Build on a suitable base branch, see the <<choose-starting-point, section above>>, +and format-patch the series. If you are doing "rebase -i" in-place to +update from the previous round, this will reuse the previous base so +(2) and (3) may become trivial. -:current-maintainer: footnote:[The current maintainer: gitster@pobox.com] -:git-ml: footnote:[The mailing list: git@vger.kernel.org] +. Find the base of where the last round was queued ++ + $ mine='kn/ref-transaction-symref' + $ git checkout "origin/seen^{/^Merge branch '$mine'}...master" -After the list reached a consensus that it is a good idea to apply the -patch, re-send it with "To:" set to the maintainer{current-maintainer} -and "cc:" the list{git-ml} for inclusion. This is especially relevant -when the maintainer did not heavily participate in the discussion and -instead left the review to trusted others. +. Apply your format-patch result. There are two cases +.. Things apply cleanly and tests fine. Go to (4). +.. Things apply cleanly but does not build or test fails, or things do +not apply cleanly. ++ +In the latter case, you have textual or semantic conflicts coming from +the difference between the old base and the base you used to build in +(1). Identify what caused the breakages (e.g., a topic or two may have +merged since the base used by (2) until the base used by (1)). ++ +Check out the latest 'origin/master' (which may be newer than the base +used by (2)), "merge --no-ff" the topics you newly depend on in there, +and use the result of the merge(s) as the base, rebuild the series and +test again. Run format-patch from the last such merges to the tip of +your topic. If you did ++ + $ git checkout origin/master + $ git merge --no-ff --into-name kn/ref-transaction-symref fo/obar + $ git merge --no-ff --into-name kn/ref-transaction-symref ba/zqux + ... rebuild the topic ... ++ +Then you'd just format your topic above these "preparing the ground" +merges, e.g. ++ + $ git format-patch "HEAD^{/^Merge branch 'ba/zqux'}"..HEAD ++ +Do not forget to write in the cover letter you did this, including the +topics you have in your base on top of 'master'. Then go to (4). -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, and "cc:" them when sending such a final version for inclusion. +. Make a trial merge of your topic into 'next' and 'seen', e.g. ++ + $ git checkout --detach 'origin/seen' + $ git revert -m 1 <the merge of the previous iteration into seen> + $ git merge kn/ref-transaction-symref ++ +The "revert" is needed if the previous iteration of your topic is +already in 'seen' (like in this case). You could choose to rebuild +master..origin/seen from scratch while excluding your previous +iteration, which may emulate what happens on the maintainers end more +closely. ++ +This trial merge may conflict. It is primarily to see what conflicts +_other_ topics may have with your topic. In other words, you do not +have to depend on it to make your topic work on 'master'. It may +become the job of the other topic owners to resolve conflicts if your +topic goes to 'next' before theirs. ++ +Make a note on what conflict you saw in the cover letter. You do not +necessarily have to resolve them, but it would be a good opportunity to +learn what others are doing in related areas. ++ + $ git checkout --detach 'origin/next' + $ git merge kn/ref-transaction-symref ++ +This is to see what conflicts your topic has with other topics that are +already cooking. This should not conflict if (3)-2 prepared a base on +top of updated master plus dependent topics taken from 'next'. Unless +the context is severe (one way to tell is try the same trial merge with +your old iteration, which may conflict in a similar way), expect that it +will be handled on maintainers end (if it gets unmanageable, I'll ask to +rebase when I receive your patches). == 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 Pratyush Yadav: +- `git-gui/` comes from git-gui project, maintained by Johannes Sixt: - https://github.com/prati0100/git-gui.git + https://github.com/j6t/git-gui - `gitk-git/` comes from Paul Mackerras's gitk project: git://git.ozlabs.org/~paulus/gitk - Those who are interested in improve gitk can volunteer to help Paul - in maintaining it cf. <YntxL/fTplFm8lr6@cleo>. + Those who are interested in improving gitk can volunteer to help Paul + maintain it, cf. <YntxL/fTplFm8lr6@cleo>. - `po/` comes from the localization coordinator, Jiang Xin: @@ -524,54 +709,12 @@ repositories. Patches to these parts should be based on their trees. -[[patch-flow]] -== An ideal patch flow - -Here is an ideal patch flow for this project the current maintainer -suggests to the contributors: - -. You come up with an itch. You code it up. - -. Send it to the list and cc people who may need to know about - the change. -+ -The people who may need to know are the ones whose code you -are butchering. These people happen to be the ones who are -most likely to be knowledgeable enough to help you, but -they have no obligation to help you (i.e. you ask for help, -don't demand). +git log -p {litdd} _$area_you_are_modifying_+ would -help you find out who they are. - -. You get comments and suggestions for improvements. You may - even get them in an "on top of your change" patch form. - -. Polish, refine, and re-send to the list and the people who - spend their time to improve your patch. Go back to step (2). - -. The list forms consensus that the last round of your patch is - good. Send it to the maintainer and cc the list. - -. A topic branch is created with the patch and is merged to `next`, - and cooked further and eventually graduates to `master`. - -In any time between the (2)-(3) cycle, the maintainer may pick it up -from the list and queue it to `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. - -[[patch-status]] -== Know the status of your patch after submission +- The "Git documentation translations" project, led by Jean-Noël + Avila, translates our documentation pages. Their work products are + maintained separately from this project, not as part of our tree: -* You can use Git itself to find out when your patch is merged in - master. `git pull --rebase` will automatically skip already-applied - patches, and will let you know. This works only if you rebase on top - of the branch in which your patch has been merged (i.e. it will not - tell you if your patch is merged in `seen` if you rebase on top of - master). + https://github.com/jnavila/git-manpages-l10n/ -* 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. == GitHub CI[[GHCI]] @@ -590,11 +733,12 @@ After the initial setup, 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://github.com/<Your GitHub handle>/git/actions/workflows/main.yml` -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 job and navigate to -"ci/run-build-and-tests.sh" and/or "ci/print-test-failures.sh". You -can also download "Artifacts" which are tarred (or zipped) archives -with test data relevant for debugging. +If a branch does not pass all test cases then it will be marked with a +red +x+, instead of a green check. In that case, you can click on the +failing job and navigate to "ci/run-build-and-tests.sh" and/or +"ci/print-test-failures.sh". You can also download "Artifacts" which +are zip archives containing tarred (or zipped) archives with test data +relevant for debugging. Then fix the problem and push your fix to your GitHub fork. This will trigger a new CI build to ensure all tests pass. @@ -686,7 +830,7 @@ message to an external program, and this is a handy way to drive `git am`. However, if the message is MIME encoded, what is piped into the program is the representation you see in your `*Article*` buffer after unwrapping MIME. This is often not what -you would want for two reasons. It tends to screw up non ASCII +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 diff --git a/Documentation/ToolsForGit.txt b/Documentation/ToolsForGit.txt index 5060d0d231..ae7690b45d 100644 --- a/Documentation/ToolsForGit.txt +++ b/Documentation/ToolsForGit.txt @@ -5,7 +5,7 @@ Tools for developing Git [[summary]] == Summary -This document gathers tips, scripts and configuration file to help people +This document gathers tips, scripts, and configuration files to help people working on Git's codebase use their favorite tools while following Git's coding style. @@ -32,7 +32,7 @@ information on using the script. This is adapted from Linux's suggestion in its CodingStyle document: -- To follow rules of the CodingGuideline, it's useful to put the following in +- To follow the rules in CodingGuidelines, it's useful to put the following in GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode: ---- ;; note the first part is useful for C editing, too diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf index 60f76f43ed..f6da6d1fbd 100644 --- a/Documentation/asciidoc.conf +++ b/Documentation/asciidoc.conf @@ -28,6 +28,10 @@ ifdef::backend-docbook[] {0#<citerefentry>} {0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>} {0#</citerefentry>} + +[literal-inlinemacro] +{eval:re.sub(r'(<[-a-zA-Z0-9.]+>)', r'<emphasis>\1</emphasis>', re.sub(r'([\[\s|()>]|^|\]|>)(\.?([-a-zA-Z0-9:+=~@,\/_^\$]+\.?)+)',r'\1<literal>\2</literal>', re.sub(r'(\.\.\.?)([^\]$.])', r'<literal>\1</literal>\2', macros.passthroughs[int(attrs['passtext'][1:-1])] if attrs['passtext'][1:-1].isnumeric() else attrs['passtext'][1:-1])))} + endif::backend-docbook[] ifdef::backend-docbook[] @@ -56,4 +60,20 @@ ifdef::backend-xhtml11[] git-relative-html-prefix= [linkgit-inlinemacro] <a href="{git-relative-html-prefix}{target}.html">{target}{0?({0})}</a> + +[literal-inlinemacro] +{eval:re.sub(r'(<[-a-zA-Z0-9.]+>)', r'<em>\1</em>', re.sub(r'([\[\s|()>]|^|\]|>)(\.?([-a-zA-Z0-9:+=~@,\/_^\$]+\.?)+)',r'\1<code>\2</code>', re.sub(r'(\.\.\.?)([^\]$.])', r'<code>\1</code>\2', macros.passthroughs[int(attrs['passtext'][1:-1])] if attrs['passtext'][1:-1].isnumeric() else attrs['passtext'][1:-1])))} + +endif::backend-xhtml11[] + +ifdef::backend-docbook[] +ifdef::doctype-manpage[] +[paradef-default] +synopsis-style=template="verseparagraph",filter="sed 's!…\\(\\]\\|$\\)!<phrase>\\0</phrase>!g;s!\\([\\[ |()]\\|^\\|\\]\\|>\\)\\([-=a-zA-Z0-9:+@,\\/_^\\$.]\\+\\|…\\)!\\1<literal>\\2</literal>!g;s!<[-a-zA-Z0-9.]\\+>!<emphasis>\\0</emphasis>!g'" +endif::doctype-manpage[] +endif::backend-docbook[] + +ifdef::backend-xhtml11[] +[paradef-default] +synopsis-style=template="verseparagraph",filter="sed 's!…\\(\\]\\|$\\)!<span>\\0</span>!g;s!\\([\\[ |()]\\|^\\|\\]\\|>\\)\\([-=a-zA-Z0-9:+@,\\/_^\\$.]\\+\\|…\\)!\\1<code>\\2</code>!g;s!<[-a-zA-Z0-9.]\\+>!<em>\\0</em>!g'" endif::backend-xhtml11[] diff --git a/Documentation/asciidoctor-extensions.rb b/Documentation/asciidoctor-extensions.rb index d906a00803..cb24480b63 100644 --- a/Documentation/asciidoctor-extensions.rb +++ b/Documentation/asciidoctor-extensions.rb @@ -1,5 +1,7 @@ require 'asciidoctor' require 'asciidoctor/extensions' +require 'asciidoctor/converter/docbook5' +require 'asciidoctor/converter/html5' module Git module Documentation @@ -39,10 +41,95 @@ module Git output end end + + class SynopsisBlock < Asciidoctor::Extensions::BlockProcessor + + use_dsl + named :synopsis + parse_content_as :simple + + def process parent, reader, attrs + outlines = reader.lines.map do |l| + l.gsub(/(\.\.\.?)([^\]$.])/, '`\1`\2') + .gsub(%r{([\[\] |()>]|^)([-a-zA-Z0-9:+=~@,/_^\$]+)}, '\1{empty}`\2`{empty}') + .gsub(/(<[-a-zA-Z0-9.]+>)/, '__\\1__') + .gsub(']', ']{empty}') + end + create_block parent, :verse, outlines, attrs + end + end + + class GitDBConverter < Asciidoctor::Converter::DocBook5Converter + + extend Asciidoctor::Converter::Config + register_for 'docbook5' + + def convert_inline_quoted node + if (type = node.type) == :asciimath + # NOTE fop requires jeuclid to process mathml markup + asciimath_available? ? %(<inlineequation>#{(::AsciiMath.parse node.text).to_mathml 'mml:', 'xmlns:mml' => 'http://www.w3.org/1998/Math/MathML'}</inlineequation>) : %(<inlineequation><mathphrase><![CDATA[#{node.text}]]></mathphrase></inlineequation>) + elsif type == :latexmath + # unhandled math; pass source to alt and required mathphrase element; dblatex will process alt as LaTeX math + %(<inlineequation><alt><![CDATA[#{equation = node.text}]]></alt><mathphrase><![CDATA[#{equation}]]></mathphrase></inlineequation>) + elsif type == :monospaced + node.text.gsub(/(\.\.\.?)([^\]$.])/, '<literal>\1</literal>\2') + .gsub(%r{([\[\s|()>.]|^|\]|>)(\.?([-a-zA-Z0-9:+=~@,/_^\$]+\.{0,2})+)}, '\1<literal>\2</literal>') + .gsub(/(<[-a-zA-Z0-9.]+>)/, '<emphasis>\1</emphasis>') + else + open, close, supports_phrase = QUOTE_TAGS[type] + text = node.text + if node.role + if supports_phrase + quoted_text = %(#{open}<phrase role="#{node.role}">#{text}</phrase>#{close}) + else + quoted_text = %(#{open.chop} role="#{node.role}">#{text}#{close}) + end + else + quoted_text = %(#{open}#{text}#{close}) + end + node.id ? %(<anchor#{common_attributes node.id, nil, text}/>#{quoted_text}) : quoted_text + end + end + end + + # register a html5 converter that takes in charge to convert monospaced text into Git style synopsis + class GitHTMLConverter < Asciidoctor::Converter::Html5Converter + + extend Asciidoctor::Converter::Config + register_for 'html5' + + def convert_inline_quoted node + if node.type == :monospaced + node.text.gsub(/(\.\.\.?)([^\]$.])/, '<code>\1</code>\2') + .gsub(%r{([\[\s|()>.]|^|\]|>)(\.?([-a-zA-Z0-9:+=~@,/_^\$]+\.{0,2})+)}, '\1<code>\2</code>') + .gsub(/(<[-a-zA-Z0-9.]+>)/, '<em>\1</em>') + + else + open, close, tag = QUOTE_TAGS[node.type] + if node.id + class_attr = node.role ? %( class="#{node.role}") : '' + if tag + %(#{open.chop} id="#{node.id}"#{class_attr}>#{node.text}#{close}) + else + %(<span id="#{node.id}"#{class_attr}>#{open}#{node.text}#{close}</span>) + end + elsif node.role + if tag + %(#{open.chop} class="#{node.role}">#{node.text}#{close}) + else + %(<span class="#{node.role}">#{open}#{node.text}#{close}</span>) + end + else + %(#{open}#{node.text}#{close}) + end + end + end + end end end Asciidoctor::Extensions.register do inline_macro Git::Documentation::LinkGitProcessor, :linkgit + block Git::Documentation::SynopsisBlock postprocessor Git::Documentation::DocumentPostProcessor end diff --git a/Documentation/config.txt b/Documentation/config.txt index 229b63a454..8c0b3ed807 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -11,7 +11,7 @@ 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 +and the porcelain commands. The variables are divided into sections, wherein the fully qualified variable name of the variable itself is the last dot-separated segment and the section name is everything before the last dot. The variable names are case-insensitive, allow only alphanumeric @@ -22,9 +22,10 @@ multivalued. Syntax ~~~~~~ -The syntax is fairly flexible and permissive; whitespaces are mostly -ignored. The '#' and ';' characters begin comments to the end of line, -blank lines are ignored. +The syntax is fairly flexible and permissive. Whitespace characters, +which in this context are the space character (SP) and the horizontal +tabulation (HT), are mostly ignored. The '#' and ';' characters begin +comments to the end of line. Blank lines are ignored. The file consists of sections and variables. A section begins with the name of the section in square brackets and continues until the next @@ -63,16 +64,17 @@ the variable is the boolean "true"). The variable names are case-insensitive, allow only alphanumeric characters and `-`, and must start with an alphabetic character. -A line that defines a value can be continued to the next line by -ending it with a `\`; the backslash 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. +Whitespace characters surrounding `name`, `=` and `value` are discarded. +Internal whitespace characters within 'value' are retained verbatim. +Comments starting with either `#` or `;` and extending to the end of line +are discarded. A line that defines a value can be continued to the next +line by ending it with a backslash (`\`); the backslash and the end-of-line +characters are discarded. -Inside double quotes, double quote `"` and backslash `\` characters -must be escaped: use `\"` for `"` and `\\` for `\`. +If `value` needs to contain leading or trailing whitespace characters, +it must be enclosed in double quotation marks (`"`). Inside double quotation +marks, 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) @@ -103,7 +105,7 @@ was found. See below for examples. Conditional includes ~~~~~~~~~~~~~~~~~~~~ -You can include a config file from another conditionally by setting a +You can conditionally include a config file from another by setting an `includeIf.<condition>.path` variable to the name of the file to be included. @@ -118,7 +120,7 @@ are: 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 +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. @@ -314,7 +316,8 @@ terminals, this is usually not the same as setting to "white black". 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`. +hex, like `#ff0ab3`, or 12-bit RGB values like `#f1b`, which is +equivalent to the 24-bit color `#ff11bb`. + The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`, `italic`, and `strike` (for crossed-out or "strikethrough" letters). @@ -369,18 +372,20 @@ inventing new variables for use in your own tool, make sure their names do not conflict with those that are used by Git itself and other popular tools, and describe them in your documentation. -include::config/advice.txt[] - -include::config/core.txt[] - include::config/add.txt[] +include::config/advice.txt[] + include::config/alias.txt[] include::config/am.txt[] include::config/apply.txt[] +include::config/attr.txt[] + +include::config/bitmap-pseudo-merge.txt[] + include::config/blame.txt[] include::config/branch.txt[] @@ -403,10 +408,12 @@ include::config/commit.txt[] include::config/commitgraph.txt[] -include::config/credential.txt[] - include::config/completion.txt[] +include::config/core.txt[] + +include::config/credential.txt[] + include::config/diff.txt[] include::config/difftool.txt[] @@ -419,10 +426,10 @@ include::config/feature.txt[] include::config/fetch.txt[] -include::config/format.txt[] - include::config/filter.txt[] +include::config/format.txt[] + include::config/fsck.txt[] include::config/fsmonitor--daemon.txt[] @@ -433,10 +440,10 @@ include::config/gitcvs.txt[] include::config/gitweb.txt[] -include::config/grep.txt[] - include::config/gpg.txt[] +include::config/grep.txt[] + include::config/gui.txt[] include::config/guitool.txt[] @@ -483,6 +490,8 @@ include::config/pager.txt[] include::config/pretty.txt[] +include::config/promisor.txt[] + include::config/protocol.txt[] include::config/pull.txt[] @@ -493,6 +502,8 @@ include::config/rebase.txt[] include::config/receive.txt[] +include::config/reftable.txt[] + include::config/remote.txt[] include::config/remotes.txt[] @@ -517,10 +528,10 @@ include::config/splitindex.txt[] include::config/ssh.txt[] -include::config/status.txt[] - include::config/stash.txt[] +include::config/status.txt[] + include::config/submodule.txt[] include::config/tag.txt[] diff --git a/Documentation/config/add.txt b/Documentation/config/add.txt index e0354ceaed..7497533cbc 100644 --- a/Documentation/config/add.txt +++ b/Documentation/config/add.txt @@ -1,13 +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:: - Unused configuration variable. Used in Git versions v2.25.0 to - v2.36.0 to enable the built-in version of linkgit:git-add[1]'s - interactive mode, which then became the default in Git - versions v2.37.0 to v2.39.0. +`add.ignoreErrors`:: +`add.ignore-errors` (deprecated):: + Tells `git add` to continue adding files when some files cannot be + added due to indexing errors. +ifdef::git-add[] + Equivalent to the `--ignore-errors` option. +endif::git-add[] +ifndef::git-add[] + Equivalent to the `--ignore-errors` option of linkgit:git-add[1]. +endif::git-add[] + `add.ignore-errors` is deprecated, as it does not follow the usual + naming convention for configuration variables. diff --git a/Documentation/config/advice.txt b/Documentation/config/advice.txt index c548a91e67..257db58918 100644 --- a/Documentation/config/advice.txt +++ b/Documentation/config/advice.txt @@ -1,30 +1,71 @@ 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': + aid new users. When left unconfigured, Git will give the message + alongside instructions on how to squelch it. You can tell Git + that you have understood the issue and no longer need a specific + help message by setting the corresponding variable to `false`. ++ +As they are intended to help human users, these messages are output to +the standard error. When tools that run Git as a subprocess find them +disruptive, they can set `GIT_ADVICE=0` in the environment to squelch +all advice messages. + -- + addEmbeddedRepo:: + Shown when the user accidentally adds one + git repo inside of another. + addEmptyPathspec:: + Shown when the user runs `git add` without providing + the pathspec parameter. + addIgnoredFile:: + Shown when the user attempts to add an ignored file to + the index. + amWorkDir:: + Shown when linkgit:git-am[1] fails to apply a patch + file, to tell the user the location of the file. ambiguousFetchRefspec:: - Advice shown when fetch refspec for multiple remotes map to + Shown when a fetch refspec for multiple remotes maps to the same remote-tracking branch namespace and causes branch tracking set-up to fail. + checkoutAmbiguousRemoteBranchName:: + 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 be used by default in some situations where this + advice would be printed. + commitBeforeMerge:: + Shown when linkgit:git-merge[1] refuses to + merge to avoid overwriting local changes. + detachedHead:: + Shown when the user uses + linkgit:git-switch[1] or linkgit:git-checkout[1] + to move to the detached HEAD state, to tell the user how + to create a local branch after the fact. + diverging:: + Shown when a fast-forward is not possible. fetchShowForcedUpdates:: - Advice shown when linkgit:git-fetch[1] takes a long time + 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', 'pushNeedsForce', and 'pushRefNeedsUpdate' - 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. + forceDeleteBranch:: + Shown when the user tries to delete a not fully merged + branch without the force option set. + ignoredHook:: + Shown when a hook is ignored because the hook is not + set as executable. + implicitIdentity:: + Shown when the user's information is guessed from the + system username and domain name, to tell the user how to + set their identity configuration. + mergeConflict:: + Shown when various commands stop because of conflicts. + nestedTag:: + Shown when a user attempts to recursively tag a tag object. pushAlreadyExists:: Shown when linkgit:git-push[1] rejects an update that does not qualify for fast-forwarding (e.g., a tag.) @@ -37,20 +78,54 @@ advice.*:: 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. + pushNonFFCurrent:: + Shown when linkgit:git-push[1] fails due to a + non-fast-forward update to the current branch. + pushNonFFMatching:: + Shown when the user ran linkgit:git-push[1] and pushed + "matching refs" explicitly (i.e. used `:`, or + specified a refspec that isn't the current branch) and + it resulted in a non-fast-forward error. + pushRefNeedsUpdate:: + Shown when linkgit:git-push[1] rejects a forced update of + a branch when its remote-tracking ref has updates that we + do not have locally. 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 + `refs/heads/*` or `refs/tags/*` based on the type of the source object. - pushRefNeedsUpdate:: - Shown when linkgit:git-push[1] rejects a forced update of - a branch when its remote-tracking ref has updates that we - do not have locally. + pushUpdateRejected:: + Set this variable to `false` if you want to disable + `pushNonFFCurrent`, `pushNonFFMatching`, `pushAlreadyExists`, + `pushFetchFirst`, `pushNeedsForce`, and `pushRefNeedsUpdate` + simultaneously. + rebaseTodoError:: + Shown when there is an error after editing the rebase todo list. + refSyntax:: + Shown when the user provides an illegal ref name, to + tell the user about the ref syntax documentation. + resetNoRefresh:: + Shown when linkgit:git-reset[1] takes more than 2 + seconds to refresh the index after reset, to tell the user + that they can use the `--no-refresh` option. + resolveConflict:: + Shown by various commands when conflicts + prevent the operation from being performed. + rmHints:: + Shown on failure in the output of linkgit:git-rm[1], to + give directions on how to proceed from the current state. + sequencerInUse:: + Shown when a sequencer command is already in progress. skippedCherryPicks:: Shown when linkgit:git-rebase[1] skips a commit that has already been cherry-picked onto the upstream branch. + sparseIndexExpanded:: + Shown when a sparse index is expanded to a full index, which is likely + due to an unexpected set of files existing outside of the + sparse-checkout. statusAheadBehind:: Shown when linkgit:git-status[1] computes the ahead/behind counts for a local ref compared to its remote tracking ref, @@ -63,83 +138,32 @@ advice.*:: 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. + linkgit:git-checkout[1] when switching branches. 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. - resetNoRefresh:: - Advice to consider using the `--no-refresh` option to - linkgit:git-reset[1] when the command takes more than 2 seconds - to refresh the index 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. - suggestDetachingHead:: - Advice shown when linkgit:git-switch[1] refuses to detach HEAD - without the explicit `--detach` option. - 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. + Shown when linkgit:git-status[1] takes more than 2 + seconds to enumerate untracked files, to tell the user that + they can use the `-u` option. submoduleAlternateErrorStrategyDie:: - Advice shown when a submodule.alternateErrorStrategy option + Shown when a submodule.alternateErrorStrategy option configured to "die" causes a fatal error. + submoduleMergeConflict:: + Advice shown when a non-trivial submodule merge conflict is + encountered. submodulesNotUpdated:: - Advice shown when a user runs a submodule command that fails + Shown when a user runs a submodule command that fails because `git submodule update --init` was not run. - 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. + suggestDetachingHead:: + Shown when linkgit:git-switch[1] refuses to detach HEAD + without the explicit `--detach` option. updateSparsePath:: - Advice shown when either linkgit:git-add[1] or linkgit:git-rm[1] + Shown when either linkgit:git-add[1] or linkgit:git-rm[1] is asked to update index entries outside the current sparse checkout. - diverging:: - Advice shown when a fast-forward is not possible. + waitingForEditor:: + Shown when Git is waiting for editor input. Relevant + when e.g. the editor is not launched inside the terminal. worktreeAddOrphan:: - Advice shown when a user tries to create a worktree from an - invalid reference, to instruct how to create a new orphan + Shown when the user tries to create a worktree from an + invalid reference, to tell the user how to create a new unborn branch instead. -- diff --git a/Documentation/config/alias.txt b/Documentation/config/alias.txt index f1ca739d57..2c5db0ad84 100644 --- a/Documentation/config/alias.txt +++ b/Documentation/config/alias.txt @@ -4,7 +4,7 @@ alias.*:: `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. + spaces, the usual shell quoting and escaping are 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 @@ -21,8 +21,23 @@ 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]. +`gitk --all --not ORIG_HEAD`. Note: ++ +* 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]. +* Shell command aliases always receive any extra arguments provided to + the Git command-line as positional arguments. +** Care should be taken if your shell alias is a "one-liner" script + with multiple commands (e.g. in a pipeline), references multiple + arguments, or is otherwise not able to handle positional arguments + added at the end. For example: `alias.cmd = "!echo $1 | grep $2"` + called as `git cmd 1 2` will be executed as 'echo $1 | grep $2 + 1 2', which is not what you want. +** A convenient way to deal with this is to write your script + operations in an inline function that is then called with any + arguments from the command-line. For example `alias.cmd = "!c() { + echo $1 | grep $2 ; }; c" will correctly execute the prior example. +** Setting `GIT_TRACE=1` can help you debug the command being run for + your alias. diff --git a/Documentation/config/apply.txt b/Documentation/config/apply.txt index 8fb8ef763d..f9908e210a 100644 --- a/Documentation/config/apply.txt +++ b/Documentation/config/apply.txt @@ -2,10 +2,10 @@ 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 + When set to one of: no, none, never, false, it 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 + Tells 'git apply' how to handle whitespace, in the same way as the `--whitespace` option. See linkgit:git-apply[1]. diff --git a/Documentation/config/attr.txt b/Documentation/config/attr.txt new file mode 100644 index 0000000000..c4a5857993 --- /dev/null +++ b/Documentation/config/attr.txt @@ -0,0 +1,6 @@ +attr.tree:: + A reference to a tree in the repository from which to read attributes, + instead of the `.gitattributes` file in the working tree. If the value + does not resolve to a valid tree object, an empty tree is used instead. + When the `GIT_ATTR_SOURCE` environment variable or `--attr-source` + command line option are used, this configuration variable has no effect. diff --git a/Documentation/config/bitmap-pseudo-merge.txt b/Documentation/config/bitmap-pseudo-merge.txt new file mode 100644 index 0000000000..1f264eca99 --- /dev/null +++ b/Documentation/config/bitmap-pseudo-merge.txt @@ -0,0 +1,91 @@ +NOTE: The configuration options in `bitmapPseudoMerge.*` are considered +EXPERIMENTAL and may be subject to change or be removed entirely in the +future. For more information about the pseudo-merge bitmap feature, see +the "Pseudo-merge bitmaps" section of linkgit:gitpacking[7]. + +bitmapPseudoMerge.<name>.pattern:: + Regular expression used to match reference names. Commits + pointed to by references matching this pattern (and meeting + the below criteria, like `bitmapPseudoMerge.<name>.sampleRate` + and `bitmapPseudoMerge.<name>.threshold`) will be considered + for inclusion in a pseudo-merge bitmap. ++ +Commits are grouped into pseudo-merge groups based on whether or not +any reference(s) that point at a given commit match the pattern, which +is an extended regular expression. ++ +Within a pseudo-merge group, commits may be further grouped into +sub-groups based on the capture groups in the pattern. These +sub-groupings are formed from the regular expressions by concatenating +any capture groups from the regular expression, with a '-' dash in +between. ++ +For example, if the pattern is `refs/tags/`, then all tags (provided +they meet the below criteria) will be considered candidates for the +same pseudo-merge group. However, if the pattern is instead +`refs/remotes/([0-9])+/tags/`, then tags from different remotes will +be grouped into separate pseudo-merge groups, based on the remote +number. + +bitmapPseudoMerge.<name>.decay:: + Determines the rate at which consecutive pseudo-merge bitmap + groups decrease in size. Must be non-negative. This parameter + can be thought of as `k` in the function `f(n) = C * n^-k`, + where `f(n)` is the size of the `n`th group. ++ +Setting the decay rate equal to `0` will cause all groups to be the +same size. Setting the decay rate equal to `1` will cause the `n`th +group to be `1/n` the size of the initial group. Higher values of the +decay rate cause consecutive groups to shrink at an increasing rate. +The default is `1`. ++ +If all groups are the same size, it is possible that groups containing +newer commits will be able to be used less often than earlier groups, +since it is more likely that the references pointing at newer commits +will be updated more often than a reference pointing at an old commit. + +bitmapPseudoMerge.<name>.sampleRate:: + Determines the proportion of non-bitmapped commits (among + reference tips) which are selected for inclusion in an + unstable pseudo-merge bitmap. Must be between `0` and `1` + (inclusive). The default is `1`. + +bitmapPseudoMerge.<name>.threshold:: + Determines the minimum age of non-bitmapped commits (among + reference tips, as above) which are candidates for inclusion + in an unstable pseudo-merge bitmap. The default is + `1.week.ago`. + +bitmapPseudoMerge.<name>.maxMerges:: + Determines the maximum number of pseudo-merge commits among + which commits may be distributed. ++ +For pseudo-merge groups whose pattern does not contain any capture +groups, this setting is applied for all commits matching the regular +expression. For patterns that have one or more capture groups, this +setting is applied for each distinct capture group. ++ +For example, if your capture group is `refs/tags/`, then this setting +will distribute all tags into a maximum of `maxMerges` pseudo-merge +commits. However, if your capture group is, say, +`refs/remotes/([0-9]+)/tags/`, then this setting will be applied to +each remote's set of tags individually. ++ +Must be non-negative. The default value is 64. + +bitmapPseudoMerge.<name>.stableThreshold:: + Determines the minimum age of commits (among reference tips, + as above, however stable commits are still considered + candidates even when they have been covered by a bitmap) which + are candidates for a stable a pseudo-merge bitmap. The default + is `1.month.ago`. ++ +Setting this threshold to a smaller value (e.g., 1.week.ago) will cause +more stable groups to be generated (which impose a one-time generation +cost) but those groups will likely become stale over time. Using a +larger value incurs the opposite penalty (fewer stable groups which are +more useful). + +bitmapPseudoMerge.<name>.stableSize:: + Determines the size (in number of commits) of a stable + psuedo-merge bitmap. The default is `512`. diff --git a/Documentation/config/branch.txt b/Documentation/config/branch.txt index 445341a906..432b9cd2c0 100644 --- a/Documentation/config/branch.txt +++ b/Documentation/config/branch.txt @@ -36,7 +36,7 @@ branch.sort:: 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 + which remote to fetch from or 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 @@ -64,7 +64,7 @@ branch.<name>.merge:: 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 + The merge information is used by 'git pull' (which 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. @@ -99,5 +99,5 @@ 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 + automatically added to the format-patch cover letter or request-pull summary. diff --git a/Documentation/config/checkout.txt b/Documentation/config/checkout.txt index bfbca90f0e..a323022993 100644 --- a/Documentation/config/checkout.txt +++ b/Documentation/config/checkout.txt @@ -30,7 +30,7 @@ checkout.workers:: all commands that perform checkout. E.g. checkout, clone, reset, sparse-checkout, etc. + -Note: parallel checkout usually delivers better performance for repositories +Note: Parallel checkout usually delivers better performance for repositories located on SSDs or over NFS. For repositories on spinning disks and/or machines with a small number of cores, the default sequential checkout often performs better. The size and compression level of a repository might also influence how @@ -39,6 +39,6 @@ well the parallel version performs. checkout.thresholdForParallelism:: When running parallel checkout with a small number of files, the cost of subprocess spawning and inter-process communication might outweigh - the parallelization gains. This setting allows to define the minimum + the parallelization gains. This setting allows you to define the minimum number of files for which parallel checkout should be attempted. The default is 100. diff --git a/Documentation/config/clean.txt b/Documentation/config/clean.txt index a807c925b9..c0188ead4e 100644 --- a/Documentation/config/clean.txt +++ b/Documentation/config/clean.txt @@ -1,3 +1,3 @@ clean.requireForce:: - A boolean to make git-clean do nothing unless given -f, - -i or -n. Defaults to true. + A boolean to make git-clean refuse to delete files unless -f + is given. Defaults to true. diff --git a/Documentation/config/clone.txt b/Documentation/config/clone.txt index 26f4fb137a..0a10efd174 100644 --- a/Documentation/config/clone.txt +++ b/Documentation/config/clone.txt @@ -1,13 +1,23 @@ -clone.defaultRemoteName:: +`clone.defaultRemoteName`:: The name of the remote to create when cloning a repository. Defaults to - `origin`, and can be overridden by passing the `--origin` command-line + `origin`. +ifdef::git-clone[] + It can be overridden by passing the `--origin` command-line + option. +endif::[] +ifndef::git-clone[] + It can be overridden by passing the `--origin` command-line option to linkgit:git-clone[1]. +endif::[] -clone.rejectShallow:: - Reject to clone a repository if it is a shallow one, can be overridden by - passing option `--reject-shallow` in command line. See linkgit:git-clone[1] +`clone.rejectShallow`:: + Reject cloning a repository if it is a shallow one; this can be overridden by + passing the `--reject-shallow` option on the command line. +ifndef::git-clone[] + See linkgit:git-clone[1]. +endif::[] -clone.filterSubmodules:: +`clone.filterSubmodules`:: If a partial clone filter is provided (see `--filter` in linkgit:git-rev-list[1]) and `--recurse-submodules` is used, also apply the filter to submodules. diff --git a/Documentation/config/color.txt b/Documentation/config/color.txt index 1795b2d16b..2f2275ac69 100644 --- a/Documentation/config/color.txt +++ b/Documentation/config/color.txt @@ -106,7 +106,7 @@ color.grep.<slot>:: matching text in context lines `matchSelected`;; matching text in selected lines. Also, used to customize the following - linkgit:git-log[1] subcommands: `--grep`, `--author` and `--committer`. + linkgit:git-log[1] subcommands: `--grep`, `--author`, and `--committer`. `selected`;; non-matching text in selected lines. Also, used to customize the following linkgit:git-log[1] subcommands: `--grep`, `--author` and diff --git a/Documentation/config/column.txt b/Documentation/config/column.txt index 76aa2f29dc..01e4198429 100644 --- a/Documentation/config/column.txt +++ b/Documentation/config/column.txt @@ -43,7 +43,7 @@ column.branch:: See `column.ui` for details. column.clean:: - Specify the layout when list items in `git clean -i`, which always + Specify the layout when listing items in `git clean -i`, which always shows files and directories in columns. See `column.ui` for details. column.status:: @@ -51,5 +51,5 @@ column.status:: See `column.ui` for details. column.tag:: - Specify whether to output tag listing in `git tag` in columns. + Specify whether to output tag listings in `git tag` in columns. See `column.ui` for details. diff --git a/Documentation/config/commit.txt b/Documentation/config/commit.txt index 2c95573930..62f0d92fda 100644 --- a/Documentation/config/commit.txt +++ b/Documentation/config/commit.txt @@ -2,7 +2,7 @@ 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 + with the 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). @@ -25,5 +25,5 @@ commit.template:: new commit messages. commit.verbose:: - A boolean or int to specify the level of verbose with `git commit`. + A boolean or int to specify the level of verbosity with `git commit`. See linkgit:git-commit[1]. diff --git a/Documentation/config/commitgraph.txt b/Documentation/config/commitgraph.txt index 30604e4a4c..7f8c9d6638 100644 --- a/Documentation/config/commitgraph.txt +++ b/Documentation/config/commitgraph.txt @@ -9,6 +9,29 @@ commitGraph.maxNewFilters:: commit-graph write` (c.f., linkgit:git-commit-graph[1]). commitGraph.readChangedPaths:: - If true, then git will use the changed-path Bloom filters in the - commit-graph file (if it exists, and they are present). Defaults to - true. See linkgit:git-commit-graph[1] for more information. + Deprecated. Equivalent to commitGraph.changedPathsVersion=-1 if true, and + commitGraph.changedPathsVersion=0 if false. (If commitGraph.changedPathVersion + is also set, commitGraph.changedPathsVersion takes precedence.) + +commitGraph.changedPathsVersion:: + Specifies the version of the changed-path Bloom filters that Git will read and + write. May be -1, 0, 1, or 2. Note that values greater than 1 may be + incompatible with older versions of Git which do not yet understand + those versions. Use caution when operating in a mixed-version + environment. ++ +Defaults to -1. ++ +If -1, Git will use the version of the changed-path Bloom filters in the +repository, defaulting to 1 if there are none. ++ +If 0, Git will not read any Bloom filters, and will write version 1 Bloom +filters when instructed to write. ++ +If 1, Git will only read version 1 Bloom filters, and will write version 1 +Bloom filters. ++ +If 2, Git will only read version 2 Bloom filters, and will write version 2 +Bloom filters. ++ +See linkgit:git-commit-graph[1] for more information. diff --git a/Documentation/config/core.txt b/Documentation/config/core.txt index dfbdaf00b8..8f6d8e7754 100644 --- a/Documentation/config/core.txt +++ b/Documentation/config/core.txt @@ -366,7 +366,7 @@ default in a bare repository. core.repositoryFormatVersion:: Internal variable identifying the repository format and layout - version. + version. See linkgit:gitrepository-layout[5]. core.sharedRepository:: When 'group' (or 'true'), the repository is made shareable between @@ -520,6 +520,7 @@ core.editor:: `GIT_EDITOR` is not set. See linkgit:git-var[1]. core.commentChar:: +core.commentString:: 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 @@ -527,6 +528,20 @@ core.commentChar:: + If set to "auto", `git-commit` would select a character that is not the beginning character of any line in existing commit messages. ++ +Note that these two variables are aliases of each other, and in modern +versions of Git you are free to use a string (e.g., `//` or `⁑⁕⁑`) with +`commentChar`. Versions of Git prior to v2.45.0 will ignore +`commentString` but will reject a value of `commentChar` that consists +of more than a single ASCII byte. If you plan to use your config with +older and newer versions of Git, you may want to specify both: ++ + [core] + # single character for older versions + commentChar = "#" + # string for newer versions (which will override commentChar + # because it comes later in the file) + commentString = "//" core.filesRefLockTimeout:: The length of time, in milliseconds, to retry when trying to @@ -688,7 +703,7 @@ core.createObject:: 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 +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:: @@ -736,3 +751,10 @@ core.abbrev:: If set to "no", no abbreviation is made and the object names are shown in their full length. The minimum length is 4. + +core.maxTreeDepth:: + The maximum depth Git is willing to recurse while traversing a + tree (e.g., "a/b/cde/f" has a depth of 4). This is a fail-safe + to allow Git to abort cleanly, and should not generally need to + be adjusted. When Git is compiled with MSVC, the default is 512. + Otherwise, the default is 2048. diff --git a/Documentation/config/credential.txt b/Documentation/config/credential.txt index 512f31876e..470482ff4c 100644 --- a/Documentation/config/credential.txt +++ b/Documentation/config/credential.txt @@ -9,6 +9,14 @@ credential.helper:: Note that multiple helpers may be defined. See linkgit:gitcredentials[7] for details and examples. +credential.interactive:: + By default, Git and any configured credential helpers will ask for + user input when new credentials are required. Many of these helpers + will succeed based on stored credentials if those credentials are + still valid. To avoid the possibility of user interactivity from + Git, set `credential.interactive=false`. Some credential helpers + respect this option as well. + credential.useHttpPath:: When acquiring credentials, consider the "path" component of an http or https URL to be important. Defaults to false. See @@ -21,7 +29,7 @@ credential.username:: credential.<url>.*:: Any of the credential.* options above can be applied selectively to - some credentials. For example "credential.https://example.com.username" + 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. @@ -31,6 +39,6 @@ credentialCache.ignoreSIGHUP:: credentialStore.lockTimeoutMS:: The length of time, in milliseconds, for git-credential-store to retry - when trying to lock the credentials file. Value 0 means not to retry at + when trying to lock the credentials file. A value of 0 means not to retry at all; -1 means to try indefinitely. Default is 1000 (i.e., retry for 1s). diff --git a/Documentation/config/diff.txt b/Documentation/config/diff.txt index 35a7bf86d7..190bda17e5 100644 --- a/Documentation/config/diff.txt +++ b/Documentation/config/diff.txt @@ -1,6 +1,6 @@ diff.autoRefreshIndex:: When using 'git diff' to compare with work tree - files, do not consider stat-only change as changed. + files, do not consider stat-only changes as changed. Instead, silently run `git update-index --refresh` to update the cached stat information for paths whose contents in the work tree match the contents in the @@ -52,6 +52,10 @@ directories with less than 10% of the total amount of changed files, and accumulating child directory counts in the parent directories: `files,10,cumulative`. +diff.statNameWidth:: + Limit the width of the filename part in --stat output. If set, applies + to all commands generating --stat output except format-patch. + diff.statGraphWidth:: Limit the width of the graph part in --stat output. If set, applies to all commands generating --stat output except format-patch. @@ -75,6 +79,15 @@ diff.external:: you want to use an external diff program only on a subset of your files, you might want to use linkgit:gitattributes[5] instead. +diff.trustExitCode:: + If this boolean value is set to true then the + `diff.external` command is expected to return exit code + 0 if it considers the input files to be equal or 1 if it + considers them to be different, like `diff(1)`. + If it is set to false, which is the default, then the command + is expected to return exit code 0 regardless of equality. + Any other exit code causes Git to report a fatal error. + diff.ignoreSubmodules:: Sets the default value of --ignore-submodules. Note that this affects only 'git diff' Porcelain, and not lower level 'diff' @@ -104,9 +117,15 @@ diff.mnemonicPrefix:: `git diff --no-index a b`;; compares two non-git things (1) and (2). -diff.noprefix:: +diff.noPrefix:: If set, 'git diff' does not show any source or destination prefix. +diff.srcPrefix:: + If set, 'git diff' uses this source prefix. Defaults to "a/". + +diff.dstPrefix:: + If set, 'git diff' uses this destination prefix. Defaults to "b/". + diff.relative:: If set to 'true', 'git diff' does not show changes outside of the directory and show pathnames relative to the current directory. @@ -154,6 +173,15 @@ diff.<driver>.command:: The custom diff driver command. See linkgit:gitattributes[5] for details. +diff.<driver>.trustExitCode:: + If this boolean value is set to true then the + `diff.<driver>.command` command is expected to return exit code + 0 if it considers the input files to be equal or 1 if it + considers them to be different, like `diff(1)`. + If it is set to false, which is the default, then the command + is expected to return exit code 0 regardless of equality. + Any other exit code causes Git to report a fatal error. + diff.<driver>.xfuncname:: The regular expression that the diff driver should use to recognize the hunk header. A built-in pattern may also be used. @@ -219,5 +247,5 @@ diff.colorMoved:: 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]. + 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/extensions.txt b/Documentation/config/extensions.txt index bccaec7a96..5dc569d1c9 100644 --- a/Documentation/config/extensions.txt +++ b/Documentation/config/extensions.txt @@ -1,13 +1,69 @@ -extensions.objectFormat:: +extensions.*:: + Unless otherwise stated, is an error to specify an extension if + `core.repositoryFormatVersion` is not `1`. See + linkgit:gitrepository-layout[5]. ++ +-- +compatObjectFormat:: + Specify a compatibility hash algorithm to use. The acceptable values + are `sha1` and `sha256`. The value specified must be different from the + value of `extensions.objectFormat`. This allows client level + interoperability between git repositories whose objectFormat matches + this compatObjectFormat. In particular when fully implemented the + pushes and pulls from a repository in whose objectFormat matches + compatObjectFormat. As well as being able to use oids encoded in + compatObjectFormat in addition to oids encoded with objectFormat to + locally specify objects. + +noop:: + This extension does not change git's behavior at all. It is useful only + for testing format-1 compatibility. ++ +For historical reasons, this extension is respected regardless of the +`core.repositoryFormatVersion` setting. + +noop-v1:: + This extension does not change git's behavior at all. It is useful only + for testing format-1 compatibility. + +objectFormat:: Specify the hash algorithm to use. The acceptable values are `sha1` and - `sha256`. If not specified, `sha1` is assumed. It is an error to specify - this key unless `core.repositoryFormatVersion` is 1. + `sha256`. If not specified, `sha1` is assumed. + Note that this setting should only be set by linkgit:git-init[1] or linkgit:git-clone[1]. Trying to change it after initialization will not work and will produce hard-to-diagnose issues. -extensions.worktreeConfig:: +partialClone:: + When enabled, 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. ++ +For historical reasons, this extension is respected regardless of the +`core.repositoryFormatVersion` setting. + +preciousObjects:: + If enabled, indicates that objects in the repository MUST NOT be deleted + (e.g., by `git-prune` or `git repack -d`). ++ +For historical reasons, this extension is respected regardless of the +`core.repositoryFormatVersion` setting. + +refStorage:: + Specify the ref storage format to use. The acceptable values are: ++ +include::../ref-storage-format.txt[] + ++ +Note that this setting should only be set by linkgit:git-init[1] or +linkgit:git-clone[1]. Trying to change it after initialization will not +work and will produce hard-to-diagnose issues. + +worktreeConfig:: If enabled, then worktrees will load config settings from the `$GIT_DIR/config.worktree` file in addition to the `$GIT_COMMON_DIR/config` file. Note that `$GIT_COMMON_DIR` and @@ -17,7 +73,7 @@ extensions.worktreeConfig:: `config.worktree` file will override settings from any other config files. + -When enabling `extensions.worktreeConfig`, you must be careful to move +When enabling this extension, you must be careful to move certain values from the common config file to the main working tree's `config.worktree` file, if present: + @@ -25,15 +81,17 @@ certain values from the common config file to the main working tree's `$GIT_COMMON_DIR/config.worktree`. * If `core.bare` is true, then it must be moved from `$GIT_COMMON_DIR/config` to `$GIT_COMMON_DIR/config.worktree`. + + It may also be beneficial to adjust the locations of `core.sparseCheckout` and `core.sparseCheckoutCone` depending on your desire for customizable sparse-checkout settings for each worktree. By default, the `git -sparse-checkout` builtin enables `extensions.worktreeConfig`, assigns +sparse-checkout` builtin enables this extension, assigns these config values on a per-worktree basis, and uses the `$GIT_DIR/info/sparse-checkout` file to specify the sparsity for each worktree independently. See linkgit:git-sparse-checkout[1] for more details. + -For historical reasons, `extensions.worktreeConfig` is respected -regardless of the `core.repositoryFormatVersion` setting. +For historical reasons, this extension is respected regardless of the +`core.repositoryFormatVersion` setting. +-- diff --git a/Documentation/config/fastimport.txt b/Documentation/config/fastimport.txt index c1166e330d..903677d7ef 100644 --- a/Documentation/config/fastimport.txt +++ b/Documentation/config/fastimport.txt @@ -1,8 +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 + 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 index bf9546fca4..f061b64b74 100644 --- a/Documentation/config/feature.txt +++ b/Documentation/config/feature.txt @@ -17,6 +17,9 @@ skipping more commits at a time, reducing the number of round trips. + * `pack.useBitmapBoundaryTraversal=true` may improve bitmap traversal times by walking fewer objects. ++ +* `pack.allowPackReuse=multi` may improve the time it takes to create a pack by +reusing objects from multiple packs instead of just one. feature.manyFiles:: Enable config options that optimize for repos with many files in the diff --git a/Documentation/config/fetch.txt b/Documentation/config/fetch.txt index 568f0f75b3..d7dc461bd1 100644 --- a/Documentation/config/fetch.txt +++ b/Documentation/config/fetch.txt @@ -50,10 +50,16 @@ fetch.pruneTags:: refs. See also `remote.<name>.pruneTags` and the PRUNING section of linkgit:git-fetch[1]. +fetch.all:: + If true, fetch will attempt to update all available remotes. + This behavior can be overridden by passing `--no-all` or by + explicitly specifying one or more remote(s) to fetch from. + Defaults to false. + 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. + `full` and `compact`. Default value is `full`. See the + OUTPUT section in linkgit:git-fetch[1] for details. fetch.negotiationAlgorithm:: Control how information about the commits in the local repository diff --git a/Documentation/config/format.txt b/Documentation/config/format.txt index 8cf6f00d93..7410e930e5 100644 --- a/Documentation/config/format.txt +++ b/Documentation/config/format.txt @@ -68,7 +68,7 @@ format.encodeEmailHeaders:: Defaults to true. format.pretty:: - The default pretty format for log/show/whatchanged command, + The default pretty format for log/show/whatchanged command. See linkgit:git-log[1], linkgit:git-show[1], linkgit:git-whatchanged[1]. @@ -119,7 +119,7 @@ format.notes:: `--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 +If one wishes to use the ref `refs/notes/true`, please use that literal instead. + This configuration can be specified multiple times in order to allow diff --git a/Documentation/config/fsck.txt b/Documentation/config/fsck.txt index a3c865df56..8e9e508933 100644 --- a/Documentation/config/fsck.txt +++ b/Documentation/config/fsck.txt @@ -11,13 +11,13 @@ 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. +`fetch.fsck.*`. variables. + -Unlike variables like `color.ui` and `core.editor` the +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. +uniformly configure the same fsck settings in different circumstances, +all three of them must be 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 @@ -36,19 +36,19 @@ 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. + -See `Fsck Messages` section of linkgit:git-fsck[1] for supported +See the `Fsck Messages` section of linkgit:git-fsck[1] for supported values of `<msg-id>`. 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 + be ignored. On versions of Git 2.20 and later, comments ('#'), empty + lines, and any leading and trailing whitespace are 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 +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. + @@ -58,11 +58,11 @@ Like `fsck.<msg-id>` this variable has corresponding 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. +uniformly configure the same fsck settings in different circumstances, +all three of them must be 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 +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 diff --git a/Documentation/config/fsmonitor--daemon.txt b/Documentation/config/fsmonitor--daemon.txt index c225c6c9e7..671f9b9462 100644 --- a/Documentation/config/fsmonitor--daemon.txt +++ b/Documentation/config/fsmonitor--daemon.txt @@ -1,5 +1,5 @@ fsmonitor.allowRemote:: - By default, the fsmonitor daemon refuses to work against network-mounted + By default, the fsmonitor daemon refuses to work with network-mounted repositories. Setting `fsmonitor.allowRemote` to `true` overrides this behavior. Only respected when `core.fsmonitor` is set to `true`. diff --git a/Documentation/config/gc.txt b/Documentation/config/gc.txt index ca47eb2008..21d56db279 100644 --- a/Documentation/config/gc.txt +++ b/Documentation/config/gc.txt @@ -24,7 +24,7 @@ gc.auto:: 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 +number of loose objects, but also any other heuristic `git gc --auto` will otherwise use to determine if there's work to do, such as `gc.autoPackLimit`. @@ -39,8 +39,9 @@ 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. + Make `git gc --auto` return immediately and run in the background + if the system supports it. Default is true. This config variable acts + as a fallback in case `maintenance.autoDetach` is not set. gc.bigPackThreshold:: If non-zero, all non-cruft packs larger than this limit are kept @@ -86,6 +87,12 @@ gc.cruftPacks:: linkgit:git-repack[1]) instead of as loose objects. The default is `true`. +gc.maxCruftSize:: + Limit the size of new cruft packs when repacking. When + specified in addition to `--max-cruft-size`, the command line + option takes priority. See the `--max-cruft-size` option of + linkgit:git-repack[1]. + gc.pruneExpire:: When 'git gc' is run, it will call 'prune --expire 2.weeks.ago' (and 'repack --cruft --cruft-expiration 2.weeks.ago' if using @@ -145,6 +152,22 @@ Multiple hooks are supported, but all must exit successfully, else the operation (either generating a cruft pack or unpacking unreachable objects) will be halted. +gc.repackFilter:: + When repacking, use the specified filter to move certain + objects into a separate packfile. See the + `--filter=<filter-spec>` option of linkgit:git-repack[1]. + +gc.repackFilterTo:: + When repacking and using a filter, see `gc.repackFilter`, the + specified location will be used to create the packfile + containing the filtered out objects. **WARNING:** The + specified location should be accessible, using for example the + Git alternates mechanism, otherwise the repo could be + considered corrupt by Git as it might not be able to access the + objects in that packfile. See the `--filter-to=<dir>` option + of linkgit:git-repack[1] and the `objects/info/alternates` + section of linkgit:gitrepository-layout[5]. + gc.rerereResolved:: Records of conflicted merge you resolved earlier are kept for this many days when 'git rerere gc' is run. diff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt index 37e2831cd5..5cf32b179d 100644 --- a/Documentation/config/gpg.txt +++ b/Documentation/config/gpg.txt @@ -4,7 +4,7 @@ gpg.program:: 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 + code 0. 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. @@ -25,7 +25,7 @@ gpg.<format>.program:: 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 requires 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, @@ -38,7 +38,7 @@ gpg.minTrustLevel:: * `ultimate` gpg.ssh.defaultKeyCommand:: - This command that will be run when user.signingkey is not set and a ssh + This command will be run when user.signingkey is not set and a ssh signature is requested. On successful exit a valid ssh public key prefixed with `key::` is expected in the first line of its output. This allows for a script doing a dynamic lookup of the correct public diff --git a/Documentation/config/grep.txt b/Documentation/config/grep.txt index e521f20390..10041f27b0 100644 --- a/Documentation/config/grep.txt +++ b/Documentation/config/grep.txt @@ -24,5 +24,5 @@ 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 + 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 index 0c087fd8c9..171be774d2 100644 --- a/Documentation/config/gui.txt +++ b/Documentation/config/gui.txt @@ -24,7 +24,7 @@ gui.matchTrackingBranch:: not. Default: "false". gui.newBranchTemplate:: - Is used as suggested name when creating new branches using the + Is used as a suggested name when creating new branches using the linkgit:git-gui[1]. gui.pruneDuringFetch:: diff --git a/Documentation/config/http.txt b/Documentation/config/http.txt index 51a70781e5..a14371b5c9 100644 --- a/Documentation/config/http.txt +++ b/Documentation/config/http.txt @@ -5,8 +5,13 @@ http.proxy:: 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 + '[protocol://][user[:password]@]proxyhost[:port][/path]'. This can be + overridden on a per-remote basis; see remote.<name>.proxy ++ +Any proxy, however configured, must be completely transparent and must not +modify, transform, or buffer the request or response in any way. Proxies which +are not completely transparent are known to cause various forms of breakage +with Git. http.proxyAuthMethod:: Set the method with which to authenticate against the HTTP proxy. This @@ -56,6 +61,26 @@ http.emptyAuth:: a username in the URL, as libcurl normally requires a username for authentication. +http.proactiveAuth:: + Attempt authentication without first making an unauthenticated attempt and + receiving a 401 response. This can be used to ensure that all requests are + authenticated. If `http.emptyAuth` is set to true, this value has no effect. ++ +If the credential helper used specifies an authentication scheme (i.e., via the +`authtype` field), that value will be used; if a username and password is +provided without a scheme, then Basic authentication is used. The value of the +option determines the scheme requested from the helper. Possible values are: ++ +-- +* `basic` - Request Basic authentication from the helper. +* `auto` - Allow the helper to pick an appropriate scheme. +* `none` - Disable proactive authentication. +-- ++ +Note that TLS should always be used with this configuration, since otherwise it +is easy to accidentally expose plaintext credentials if Basic authentication +is selected. + http.delegation:: Control GSSAPI credential delegation. The delegation is disabled by default in libcurl since version 7.21.7. Set parameter to tell @@ -82,12 +107,16 @@ http.cookieFile:: 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)`). + Set it to an empty string, to accept only new cookies from + the server and send them back in successive requests within same + connection. 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.cookieFile. Has no effect if http.cookieFile is unset, or set to + an empty string. http.version:: Use the specified HTTP protocol version when communicating with a server. @@ -254,13 +283,13 @@ http.lowSpeedLimit, http.lowSpeedTime:: http.noEPSV:: A boolean which disables using of EPSV ftp command by curl. - This can helpful with some "poor" ftp servers which don't + This can be 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. + value represents the version of the Git client 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 diff --git a/Documentation/config/i18n.txt b/Documentation/config/i18n.txt index cc25621731..6e72fdb45b 100644 --- a/Documentation/config/i18n.txt +++ b/Documentation/config/i18n.txt @@ -2,7 +2,7 @@ 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 + browser (and possibly in other places in the future or in other porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'. i18n.logOutputEncoding:: diff --git a/Documentation/config/imap.txt b/Documentation/config/imap.txt index 06166fb5c0..3d28f72643 100644 --- a/Documentation/config/imap.txt +++ b/Documentation/config/imap.txt @@ -4,7 +4,7 @@ imap.folder:: "[Gmail]/Drafts". Required. imap.tunnel:: - Command used to setup a tunnel to the IMAP server through which + Command used to set up 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. @@ -37,7 +37,7 @@ imap.preformattedHTML:: format=fixed email. Default is `false`. imap.authMethod:: - Specify authenticate method for authentication with IMAP server. + Specify the authentication method for authenticating with the 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 diff --git a/Documentation/config/index.txt b/Documentation/config/index.txt index 23c7985eb4..3eff420360 100644 --- a/Documentation/config/index.txt +++ b/Documentation/config/index.txt @@ -23,7 +23,7 @@ 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 + CPUs and set the number of threads accordingly. Specifying 1 or 'false' will disable multithreading. Defaults to 'true'. index.version:: diff --git a/Documentation/config/init.txt b/Documentation/config/init.txt index 79c79d6617..e45b2a8121 100644 --- a/Documentation/config/init.txt +++ b/Documentation/config/init.txt @@ -1,7 +1,20 @@ -init.templateDir:: - Specify the directory from which templates will be copied. - (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) +:see-git-init: +ifndef::git-init[] +:see-git-init: (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) +endif::[] -init.defaultBranch:: +`init.templateDir`:: + Specify the directory from which templates will be copied. {see-git-init} +`init.defaultBranch`:: Allows overriding the default branch name e.g. when initializing a new repository. +`init.defaultObjectFormat`:: + Allows overriding the default object format for new repositories. See + `--object-format=` in linkgit:git-init[1]. Both the command line option + and the `GIT_DEFAULT_HASH` environment variable take precedence over + this config. +`init.defaultRefFormat`:: + Allows overriding the default ref storage format for new repositories. + See `--ref-format=` in linkgit:git-init[1]. Both the command line + option and the `GIT_DEFAULT_REF_FORMAT` environment variable take + precedence over this config. diff --git a/Documentation/config/interactive.txt b/Documentation/config/interactive.txt index a2d3c7ec44..8b876cb4eb 100644 --- a/Documentation/config/interactive.txt +++ b/Documentation/config/interactive.txt @@ -1,12 +1,10 @@ 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], + When set to true, allow the user to provide one-letter input + with a single key (i.e., without hitting the Enter key) in + interactive commands. This is currently 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. + linkgit:git-reset[1], and linkgit:git-stash[1]. interactive.diffFilter:: When an interactive command (such as `git add --patch`) shows diff --git a/Documentation/config/log.txt b/Documentation/config/log.txt index 5f96cf87fb..9003a82191 100644 --- a/Documentation/config/log.txt +++ b/Documentation/config/log.txt @@ -9,7 +9,7 @@ log.date:: `--date` option. See linkgit:git-log[1] for details. + 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 +"foo" will be used for the date format. Otherwise, "default" will be used. log.decorate:: diff --git a/Documentation/config/mailinfo.txt b/Documentation/config/mailinfo.txt index 3854d4ae37..ec3a5d81f7 100644 --- a/Documentation/config/mailinfo.txt +++ b/Documentation/config/mailinfo.txt @@ -1,6 +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 + was provided on the command-line. When active, this feature removes everything from the message body before a scissors line (i.e. consisting mainly of ">8", "8<" and "-"). diff --git a/Documentation/config/maintenance.txt b/Documentation/config/maintenance.txt index 18f0562131..72a9d6cf81 100644 --- a/Documentation/config/maintenance.txt +++ b/Documentation/config/maintenance.txt @@ -3,6 +3,17 @@ maintenance.auto:: `git maintenance run --auto` after doing their normal work. Defaults to true. +maintenance.autoDetach:: + Many Git commands trigger automatic maintenance after they have + written data into the repository. This boolean config option + controls whether this automatic maintenance shall happen in the + foreground or whether the maintenance process shall detach and + continue to run in the background. ++ +If unset, the value of `gc.autoDetach` is used as a fallback. Defaults +to true if both are unset, meaning that the maintenance process will +detach. + maintenance.strategy:: This string config option provides a way to specify one of a few recommended schedules for background maintenance. This only affects @@ -12,7 +23,7 @@ maintenance.strategy:: then that value is used instead of the one provided by `maintenance.strategy`. The possible strategy strings are: + -* `none`: This default setting implies no task are run at any schedule. +* `none`: This default setting implies no tasks are run at any schedule. * `incremental`: This setting optimizes for performing small maintenance activities that do not delete any data. This does not schedule the `gc` task, but runs the `prefetch` and `commit-graph` tasks hourly, the diff --git a/Documentation/config/man.txt b/Documentation/config/man.txt index a727d987a8..5a0f82cc23 100644 --- a/Documentation/config/man.txt +++ b/Documentation/config/man.txt @@ -5,7 +5,7 @@ man.viewer:: 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].) + passed as an argument. (See linkgit:git-help[1].) man.<tool>.path:: Override the path for the given tool that may be used to diff --git a/Documentation/config/merge.txt b/Documentation/config/merge.txt index 99e83dd36e..8851b6cede 100644 --- a/Documentation/config/merge.txt +++ b/Documentation/config/merge.txt @@ -7,7 +7,7 @@ merge.conflictStyle:: marker and the original text before the `=======` marker. The "merge" style tends to produce smaller conflict regions than diff3, both because of the exclusion of the original text, and because - when a subset of lines match on the two sides they are just pulled + when a subset of lines match on the two sides, they are just pulled out of the conflict region. Another alternate style, "zdiff3", is similar to diff3 but removes matching lines on the two sides from the conflict region when those matching lines appear near either diff --git a/Documentation/config/mergetool.txt b/Documentation/config/mergetool.txt index 56a7eeeffb..00bf665aa0 100644 --- a/Documentation/config/mergetool.txt +++ b/Documentation/config/mergetool.txt @@ -22,8 +22,8 @@ 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 + timestamp is checked, and the merge is 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:: @@ -37,7 +37,7 @@ mergetool.meld.hasOutput:: mergetool.meld.useAutoMerge:: When the `--auto-merge` is given, meld will merge all non-conflicting - parts automatically, highlight the conflicting parts and wait for + parts automatically, highlight the conflicting parts, and wait for user decision. Setting `mergetool.meld.useAutoMerge` to `true` tells Git to unconditionally use the `--auto-merge` option with `meld`. Setting this value to `auto` makes git detect whether `--auto-merge` @@ -45,17 +45,24 @@ mergetool.meld.useAutoMerge:: value of `false` avoids using `--auto-merge` altogether, and is the default value. -mergetool.vimdiff.layout:: - The vimdiff backend uses this variable to control how its split - windows look like. Applies even if you are using Neovim (`nvim`) or - gVim (`gvim`) as the merge tool. See BACKEND SPECIFIC HINTS section +mergetool.<vimdiff variant>.layout:: + Configure the split window layout for vimdiff's `<variant>`, which is any of `vimdiff`, + `nvimdiff`, `gvimdiff`. + Upon launching `git mergetool` with `--tool=<variant>` (or without `--tool` + if `merge.tool` is configured as `<variant>`), Git will consult + `mergetool.<variant>.layout` to determine the tool's layout. If the + variant-specific configuration is not available, `vimdiff`'s is used as + fallback. If that too is not available, a default layout with 4 windows + will be used. To configure the layout, see the `BACKEND SPECIFIC HINTS` +ifdef::git-mergetool[] + section. +endif::[] ifndef::git-mergetool[] - in linkgit:git-mergetool[1]. + section in linkgit:git-mergetool[1]. endif::[] - for details. mergetool.hideResolved:: - During a merge Git will automatically resolve as many conflicts as + During a merge, Git will automatically resolve as many conflicts as possible and write the 'MERGED' file containing conflict markers around any conflicts that it cannot resolve; 'LOCAL' and 'REMOTE' normally represent the versions of the file from before Git's conflict @@ -74,7 +81,7 @@ 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 + preserved; otherwise, they will be removed after the tool has exited. Defaults to `false`. mergetool.writeToTemp:: diff --git a/Documentation/config/notes.txt b/Documentation/config/notes.txt index c7c4811734..43db8e808d 100644 --- a/Documentation/config/notes.txt +++ b/Documentation/config/notes.txt @@ -1,7 +1,7 @@ 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" + `cat_sort_uniq`. Defaults to `manual`. See the "NOTES MERGE STRATEGIES" section of linkgit:git-notes[1] for more information on each strategy. + This setting can be overridden by passing the `--strategy` option to diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt index 3748136d14..da527377fa 100644 --- a/Documentation/config/pack.txt +++ b/Documentation/config/pack.txt @@ -28,11 +28,16 @@ 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. + When true or "single", and when reachability bitmaps are + enabled, pack-objects will try to send parts of the bitmapped + packfile verbatim. When "multi", and when a multi-pack + reachability bitmap is available, pack-objects will try to send + parts of all packs in the MIDX. ++ +If only a single pack bitmap is available, and `pack.allowPackReuse` +is set to "multi", reuse parts of just the bitmapped packfile. 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 @@ -74,7 +79,7 @@ pack.threads:: 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 + Specifying 0 will cause Git to auto-detect the number of CPUs and set the number of threads accordingly. pack.indexVersion:: @@ -83,11 +88,11 @@ pack.indexVersion:: 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 + and this config option is 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") +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, @@ -102,8 +107,8 @@ pack.packSizeLimit:: in the creation of multiple packfiles. + Note that this option is rarely useful, and may result in a larger total -on-disk size (because Git will not store deltas between packs), as well -as worse runtime performance (object lookup within multiple packs is +on-disk size (because Git will not store deltas between packs) and +worse runtime performance (object lookup within multiple packs is slower than a single pack, and optimizations like reachability bitmaps cannot cope with multiple packs). + diff --git a/Documentation/config/promisor.txt b/Documentation/config/promisor.txt new file mode 100644 index 0000000000..98c5cb2ec2 --- /dev/null +++ b/Documentation/config/promisor.txt @@ -0,0 +1,3 @@ +promisor.quiet:: + If set to "true" assume `--quiet` when fetching additional + objects for a partial clone. diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt index 43338b65e8..0acbbea18a 100644 --- a/Documentation/config/push.txt +++ b/Documentation/config/push.txt @@ -35,7 +35,7 @@ push.default:: * `tracking` - This is a deprecated synonym for `upstream`. -* `simple` - pushes the current branch with the same name on the remote. +* `simple` - push the current branch with the same name on the remote. + If you are working on a centralized workflow (pushing to the same repository you pull from, which is typically `origin`), then you need to configure an upstream @@ -67,7 +67,7 @@ new default). -- push.followTags:: - If set to true enable `--follow-tags` option by default. You + If set to true, enable `--follow-tags` option by default. You may override this configuration at time of push by specifying `--no-follow-tags`. diff --git a/Documentation/config/rebase.txt b/Documentation/config/rebase.txt index 9c248accec..c6187ab28b 100644 --- a/Documentation/config/rebase.txt +++ b/Documentation/config/rebase.txt @@ -9,7 +9,9 @@ rebase.stat:: rebase. False by default. rebase.autoSquash:: - If set to true enable `--autosquash` option by default. + If set to true, enable the `--autosquash` option of + linkgit:git-rebase[1] by default for interactive mode. + This can be overridden with the `--no-autosquash` option. rebase.autoStash:: When set to true, automatically create a temporary stash entry @@ -38,7 +40,7 @@ rebase.missingCommitsCheck:: 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. + automatically have the commit hash prepended to the format. rebase.abbreviateCommands:: If set to true, `git rebase` will use abbreviated command names in the diff --git a/Documentation/config/receive.txt b/Documentation/config/receive.txt index 85d5b5a3d2..36a1e6f2d2 100644 --- a/Documentation/config/receive.txt +++ b/Documentation/config/receive.txt @@ -8,18 +8,18 @@ receive.advertisePushOptions:: capability to its clients. False by default. receive.autogc:: - By default, git-receive-pack will run "git-gc --auto" after + By default, git-receive-pack will run "git maintenance run --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 + will accept a `git push --signed` and verify 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 + When a `git push --signed` sends 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 diff --git a/Documentation/config/reftable.txt b/Documentation/config/reftable.txt new file mode 100644 index 0000000000..57087803a5 --- /dev/null +++ b/Documentation/config/reftable.txt @@ -0,0 +1,56 @@ +reftable.blockSize:: + The size in bytes used by the reftable backend when writing blocks. + The block size is 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 4kB or 8kB) are recommended. Larger sizes (64kB) can +yield better compression, with a possible increased cost incurred by +readers during access. ++ +The largest block size is `16777215` bytes (15.99 MiB). The default value is +`4096` bytes (4kB). A value of `0` will use the default value. + +reftable.restartInterval:: + The interval at which to create restart points. The reftable backend + determines the restart points at file creation. 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. ++ +The default value is to create restart points every 16 records. A value of `0` +will use the default value. + +reftable.indexObjects:: + Whether the reftable backend shall write object blocks. Object blocks + are a reverse mapping of object ID to the references pointing to them. ++ +The default value is `true`. + +reftable.geometricFactor:: + Whenever the reftable backend appends a new table to the stack, it + performs auto compaction to ensure that there is only a handful of + tables. The backend does this by ensuring that tables form a geometric + sequence regarding the respective sizes of each table. ++ +By default, the geometric sequence uses a factor of 2, meaning that for any +table, the next-biggest table must at least be twice as big. A maximum factor +of 256 is supported. + +reftable.lockTimeout:: + Whenever the reftable backend appends a new table to the stack, it has + to lock the central "tables.list" file before updating it. This config + controls how long the process will wait to acquire the lock in case + another process has already acquired it. Value 0 means not to retry at + all; -1 means to try indefinitely. Default is 100 (i.e., retry for + 100ms). diff --git a/Documentation/config/remote.txt b/Documentation/config/remote.txt index 0678b4bcfe..6d8b7d6c63 100644 --- a/Documentation/config/remote.txt +++ b/Documentation/config/remote.txt @@ -5,10 +5,19 @@ remote.pushDefault:: remote.<name>.url:: The URL of a remote repository. See linkgit:git-fetch[1] or - linkgit:git-push[1]. + linkgit:git-push[1]. A configured remote can have multiple URLs; + in this case the first is used for fetching, and all are used + for pushing (assuming no `remote.<name>.pushurl` is defined). + Setting this key to the empty string clears the list of urls, + allowing you to override earlier config. remote.<name>.pushurl:: The push URL of a remote repository. See linkgit:git-push[1]. + If a `pushurl` option is present in a configured remote, it + is used for pushing instead of `remote.<name>.url`. A configured + remote can have multiple push URLs; in this case a push goes to + all of them. Setting this key to the empty string clears the + list of urls, allowing you to override earlier config. remote.<name>.proxy:: For remotes that require curl (http, https and ftp), the URL to @@ -33,14 +42,15 @@ remote.<name>.mirror:: 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]. + A deprecated synonym to `remote.<name>.skipFetchAll` (if + both are set in the configuration files with different + values, the value of the last occurrence will be used). 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]. + If true, this remote will be skipped when updating + using linkgit:git-fetch[1], the `update` subcommand of + linkgit:git-remote[1], and ignored by the prefetch task + of `git maintenance`. remote.<name>.receivepack:: The default program to execute on the remote side when pushing. See @@ -86,3 +96,13 @@ remote.<name>.partialclonefilter:: Changing or clearing this value will only affect fetches for new commits. To fetch associated objects for commits already present in the local object database, use the `--refetch` option of linkgit:git-fetch[1]. + +remote.<name>.serverOption:: + The default set of server options used when fetching from this remote. + These server options can be overridden by the `--server-option=` command + line arguments. ++ +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`). diff --git a/Documentation/config/rerere.txt b/Documentation/config/rerere.txt index 40abdf6a6b..3a78b5ebb1 100644 --- a/Documentation/config/rerere.txt +++ b/Documentation/config/rerere.txt @@ -1,7 +1,7 @@ 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. + previously recorded resolutions. Defaults to false. rerere.enabled:: Activate recording of resolved conflicts, so that identical diff --git a/Documentation/config/safe.txt b/Documentation/config/safe.txt index bde7f31459..2d45c98b12 100644 --- a/Documentation/config/safe.txt +++ b/Documentation/config/safe.txt @@ -14,7 +14,7 @@ repository that contains a bare repository and running a Git command within that directory. + This config setting is only respected in protected configuration (see -<<SCOPES>>). This prevents the untrusted repository from tampering with +<<SCOPES>>). This prevents untrusted repositories from tampering with this value. safe.directory:: @@ -32,7 +32,7 @@ override any such directories specified in the system config), add a `safe.directory` entry with an empty value. + This config setting is only respected in protected configuration (see -<<SCOPES>>). This prevents the untrusted repository from tampering with this +<<SCOPES>>). This prevents untrusted repositories from tampering with this value. + The value of this setting is interpolated, i.e. `~/<path>` expands to a @@ -44,7 +44,8 @@ string `*`. This will allow all repositories to be treated as if their directory was listed in the `safe.directory` list. If `safe.directory=*` is set in system config and you want to re-enable this protection, then initialize your list with an empty value before listing the repositories -that you deem safe. +that you deem safe. Giving a directory with `/*` appended to it will +allow access to all repositories under the named directory. + As explained, Git only allows you to access repositories owned by yourself, i.e. the user who is running Git, by default. When Git diff --git a/Documentation/config/sendemail.txt b/Documentation/config/sendemail.txt index 92a9ebe98c..5ffcfc9f2a 100644 --- a/Documentation/config/sendemail.txt +++ b/Documentation/config/sendemail.txt @@ -8,7 +8,7 @@ sendemail.smtpEncryption:: See linkgit:git-send-email[1] for description. Note that this setting is not subject to the 'identity' mechanism. -sendemail.smtpsslcertpath:: +sendemail.smtpSSLCertPath:: Path to ca-certificates (either a directory or a single file). Set it to an empty string to disable certificate verification. @@ -30,13 +30,28 @@ sendemail.confirm:: in the linkgit:git-send-email[1] documentation for the meaning of these values. +sendemail.mailmap:: + If true, makes linkgit:git-send-email[1] assume `--mailmap`, + otherwise assume `--no-mailmap`. False by default. + +sendemail.mailmap.file:: + The location of a linkgit:git-send-email[1] specific augmenting + mailmap file. The default mailmap and `mailmap.file` are loaded + first. Thus, entries in this file take precedence over entries in + the default mailmap locations. See linkgit:gitmailmap[5]. + +sendemail.mailmap.blob:: + Like `sendemail.mailmap.file`, but consider the value as a reference + to a blob in the repository. Entries in `sendemail.mailmap.file` + take precedence over entries here. See linkgit:gitmailmap[5]. + sendemail.aliasesFile:: To avoid typing long email addresses, point this to one or more email aliases files. You must also supply `sendemail.aliasFileType`. sendemail.aliasFileType:: Format of the file(s) specified in sendemail.aliasesFile. Must be - one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus', or 'sendmail'. + one of 'mutt', 'mailrc', 'pine', 'elm', '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 @@ -62,12 +77,12 @@ sendemail.chainReplyTo:: sendemail.envelopeSender:: sendemail.from:: sendemail.headerCmd:: -sendemail.signedoffbycc:: +sendemail.signedOffByCc:: sendemail.smtpPass:: -sendemail.suppresscc:: +sendemail.suppressCc:: sendemail.suppressFrom:: sendemail.to:: -sendemail.tocmd:: +sendemail.toCmd:: sendemail.smtpDomain:: sendemail.smtpServer:: sendemail.smtpServerPort:: @@ -81,8 +96,8 @@ sendemail.xmailer:: linkgit:git-send-email[1] command-line options. See its documentation for details. -sendemail.signedoffcc (deprecated):: - Deprecated alias for `sendemail.signedoffbycc`. +sendemail.signedOffCc (deprecated):: + Deprecated alias for `sendemail.signedOffByCc`. sendemail.smtpBatchSize:: Number of messages to be sent per connection, after that a relogin @@ -91,7 +106,7 @@ sendemail.smtpBatchSize:: See also the `--batch-size` option of linkgit:git-send-email[1]. sendemail.smtpReloginDelay:: - Seconds wait before reconnecting to smtp server. + Seconds to wait before reconnecting to the smtp server. See also the `--relogin-delay` option of linkgit:git-send-email[1]. sendemail.forbidSendmailVariables:: diff --git a/Documentation/config/sequencer.txt b/Documentation/config/sequencer.txt index b48d532a96..e664eef01d 100644 --- a/Documentation/config/sequencer.txt +++ b/Documentation/config/sequencer.txt @@ -2,4 +2,4 @@ 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. + When not configured, the default commit message editor is used instead. diff --git a/Documentation/config/splitindex.txt b/Documentation/config/splitindex.txt index afdb186df8..cfaa29610b 100644 --- a/Documentation/config/splitindex.txt +++ b/Documentation/config/splitindex.txt @@ -3,10 +3,10 @@ splitIndex.maxPercentChange:: 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 + 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 + 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]. diff --git a/Documentation/config/stash.txt b/Documentation/config/stash.txt index b9f609ed76..ec1edaeba6 100644 --- a/Documentation/config/stash.txt +++ b/Documentation/config/stash.txt @@ -1,14 +1,14 @@ stash.showIncludeUntracked:: If this is set to true, the `git stash show` command will show the untracked files of a stash entry. Defaults to false. See - description of 'show' command in linkgit:git-stash[1]. + the description of the 'show' command in linkgit:git-stash[1]. 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]. + See the description of the '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]. + option will show a diffstat of the stash entry. Defaults to true. + See the description of the 'show' command in linkgit:git-stash[1]. diff --git a/Documentation/config/status.txt b/Documentation/config/status.txt index 0fc704ab80..8caf90f51c 100644 --- a/Documentation/config/status.txt +++ b/Documentation/config/status.txt @@ -47,7 +47,7 @@ status.showUntrackedFiles:: 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 + systems. So, this variable controls how the commands display the untracked files. Possible values are: + -- @@ -57,12 +57,14 @@ status.showUntrackedFiles:: -- + If this variable is not specified, it defaults to 'normal'. +All usual spellings for Boolean value `true` are taken as `normal` +and `false` as `no`. 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 + 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 diff --git a/Documentation/config/submodule.txt b/Documentation/config/submodule.txt index 6490527b45..0672d99117 100644 --- a/Documentation/config/submodule.txt +++ b/Documentation/config/submodule.txt @@ -2,7 +2,7 @@ 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 + update'. If neither submodule.<name>.active nor 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. @@ -35,7 +35,7 @@ submodule.<name>.ignore:: 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 + to the submodule's 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. diff --git a/Documentation/config/trace2.txt b/Documentation/config/trace2.txt index fe1642f0d4..3b6bca2b7a 100644 --- a/Documentation/config/trace2.txt +++ b/Documentation/config/trace2.txt @@ -66,6 +66,6 @@ trace2.destinationDebug:: 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 additional traces if doing so 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 index c3ac767d1e..f1ce50f4a6 100644 --- a/Documentation/config/transfer.txt +++ b/Documentation/config/transfer.txt @@ -7,7 +7,7 @@ transfer.credentialsInUrl:: and any other direct use of the configured URL. + Note that this is currently limited to detecting credentials in -`remote.<name>.url` configuration, it won't detect credentials in +`remote.<name>.url` configuration; it won't detect credentials in `remote.<name>.pushurl` configuration. + You might want to enable this to prevent inadvertent credentials @@ -21,12 +21,12 @@ exposure, e.g. because: system. * The git programs will pass the full URL to one another as arguments on the command-line, meaning the credentials will be exposed to other - users on OS's or systems that allow other users to see the full + unprivileged users on systems that allow them to see the full process list of other users. On linux the "hidepid" setting documented in procfs(5) allows for configuring this behavior. + If such concerns don't apply to you then you probably don't need to be -concerned about credentials exposure due to storing that sensitive +concerned about credentials exposure due to storing sensitive data in git's configuration files. If you do want to use this, set `transfer.credentialsInUrl` to one of these values: + @@ -121,3 +121,7 @@ transfer.bundleURI:: information from the remote server (if advertised) and download bundles before continuing the clone through the Git protocol. Defaults to `false`. + +transfer.advertiseObjectInfo:: + When `true`, the `object-info` capability is advertised by + servers. Defaults to false. diff --git a/Documentation/config/uploadpack.txt b/Documentation/config/uploadpack.txt index 16264d82a7..0e1dda944a 100644 --- a/Documentation/config/uploadpack.txt +++ b/Documentation/config/uploadpack.txt @@ -25,7 +25,11 @@ uploadpack.allowReachableSHA1InWant:: uploadpack.allowAnySHA1InWant:: Allow `upload-pack` to accept a fetch request that asks for any object at all. - Defaults to `false`. + It implies `uploadpack.allowTipSHA1InWant` and + `uploadpack.allowReachableSHA1InWant`. If set to `true` it will + enable both of them, it set to `false` it will disable both of + them. + By default not set. uploadpack.keepAlive:: When `upload-pack` has started `pack-objects`, there may be a diff --git a/Documentation/config/user.txt b/Documentation/config/user.txt index ec9233b060..2ffc38d164 100644 --- a/Documentation/config/user.txt +++ b/Documentation/config/user.txt @@ -5,14 +5,14 @@ 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 + up in the `author` and `committer` fields of commit objects. If you need the `author` or `committer` to be different, the - `author.name`, `author.email`, `committer.name` or + `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`, + All of these can be overridden by the `GIT_AUTHOR_NAME`, `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_NAME`, - `GIT_COMMITTER_EMAIL` and `EMAIL` environment variables. + `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 @@ -40,7 +40,7 @@ user.signingKey:: your private ssh key or the public key when ssh-agent is used. Alternatively it can contain a public key prefixed with `key::` directly (e.g.: "key::ssh-rsa XXXXXX identifier"). The private key - needs to be available via ssh-agent. If not set git will call + needs to be available via ssh-agent. If not set Git will call gpg.ssh.defaultKeyCommand (e.g.: "ssh-add -L") and try to use the first key available. For backward compatibility, a raw key which begins with "ssh-", such as "ssh-rsa XXXXXX identifier", is treated diff --git a/Documentation/config/versionsort.txt b/Documentation/config/versionsort.txt index 6c7cc054fa..0cff090819 100644 --- a/Documentation/config/versionsort.txt +++ b/Documentation/config/versionsort.txt @@ -19,14 +19,14 @@ 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 +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 +If more than one suffix matches 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 +the tagname. If more than one different matching suffix starts 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 diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt index 67645cae64..e24517c496 100644 --- a/Documentation/date-formats.txt +++ b/Documentation/date-formats.txt @@ -11,7 +11,7 @@ Git internal format:: 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 + The standard date format as described by RFC 2822, for example `Thu, 07 Apr 2005 22:13:13 +0200`. ISO 8601:: diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt index 546adf79e5..4b5aa5c2e0 100644 --- a/Documentation/diff-generate-patch.txt +++ b/Documentation/diff-generate-patch.txt @@ -17,7 +17,7 @@ You can customize the creation of patch text via the What the -p option produces is slightly different from the traditional diff format: -1. It is preceded with a "git diff" header that looks like this: +1. It is preceded by a "git diff" header that looks like this: diff --git a/file1 b/file2 + @@ -25,9 +25,9 @@ The `a/` and `b/` filenames are the same unless rename/copy is involved. Especially, even for a creation or a deletion, `/dev/null` is _not_ used in place of the `a/` or `b/` filenames. + -When rename/copy is involved, `file1` and `file2` show the +When a rename/copy is involved, `file1` and `file2` show the name of the source file of the rename/copy and the name of -the file that rename/copy produces, respectively. +the file that the rename/copy produces, respectively. 2. It is followed by one or more extended header lines: @@ -77,7 +77,7 @@ separate lines indicate the old and the new mode. 5. Hunk headers mention the name of the function to which the hunk applies. See "Defining a custom hunk-header" in - linkgit:gitattributes[5] for details of how to tailor to this to + linkgit:gitattributes[5] for details of how to tailor this to specific languages. @@ -89,7 +89,7 @@ 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 suitable `--diff-merges` option to any of these commands to force generation of -diffs in specific format. +diffs in a specific format. A "combined diff" format looks like this: @@ -123,7 +123,7 @@ index fabadb8,cc95eb0..4866510 for_each_ref(get_name); ------------ -1. It is preceded with a "git diff" header, that looks like +1. It is preceded by a "git diff" header, that looks like this (when the `-c` option is used): diff --combined file @@ -142,22 +142,22 @@ or like this (when the `--cc` option is used): + The `mode <mode>,<mode>..<mode>` line appears only if at least one of the <mode> is different from the rest. Extended headers with -information about detected contents movement (renames and -copying detection) are designed to work with diff of two +information about detected content movement (renames and +copying detection) are designed to work with the diff of two <tree-ish> and are not used by combined diff format. -3. It is followed by two-line from-file/to-file header +3. It is followed by a two-line from-file/to-file header: --- a/file +++ b/file + -Similar to two-line header for traditional 'unified' diff +Similar to the two-line header for the 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 +two-line from-file/to-file, you get an N+1 line from-file/to-file header, +where N is the number of parents in the merge commit: --- a/file --- a/file @@ -197,7 +197,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 or 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 c07488b123..cd0b81adbb 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -37,66 +37,79 @@ endif::git-diff[] endif::git-format-patch[] ifdef::git-log[] ---diff-merges=(off|none|on|first-parent|1|separate|m|combined|c|dense-combined|cc|remerge|r):: +-m:: + Show diffs for merge commits in the default format. This is + similar to '--diff-merges=on', except `-m` will + produce no output unless `-p` is given as well. + +-c:: + Produce combined diff output for merge commits. + Shortcut for '--diff-merges=combined -p'. + +--cc:: + Produce dense combined diff output for merge commits. + Shortcut for '--diff-merges=dense-combined -p'. + +--dd:: + Produce diff with respect to first parent for both merge and + regular commits. + Shortcut for '--diff-merges=first-parent -p'. + +--remerge-diff:: + Produce remerge-diff output for merge commits. + Shortcut for '--diff-merges=remerge -p'. + --no-diff-merges:: + Synonym for '--diff-merges=off'. + +--diff-merges=<format>:: Specify diff format to be used for merge commits. Default is - {diff-merges-default} unless `--first-parent` is in use, in which case - `first-parent` is the default. + {diff-merges-default} unless `--first-parent` is in use, in + which case `first-parent` is the default. + ---diff-merges=(off|none)::: ---no-diff-merges::: +The following formats are supported: ++ +-- +off, none:: Disable output of diffs for merge commits. Useful to override implied value. + ---diff-merges=on::: ---diff-merges=m::: --m::: - This option makes diff output for merge commits to be shown in - the default format. `-m` will produce the output only if `-p` - is given as well. The default format could be changed using - `log.diffMerges` configuration parameter, which default value +on, m:: + Make diff output for merge commits to be shown in the default + format. The default format can be changed using + `log.diffMerges` configuration variable, whose default value is `separate`. + ---diff-merges=first-parent::: ---diff-merges=1::: - This option makes merge commits show the full diff with - respect to the first parent only. +first-parent, 1:: + Show full diff with respect to first parent. This is the same + format as `--patch` produces for non-merge commits. ++ +separate:: + Show full diff with respect to each of parents. + Separate log entry and diff is generated for each parent. + ---diff-merges=separate::: - This makes merge commits show the full diff with respect to - each of the parents. Separate log entry and diff is generated - for each parent. +combined, c:: + Show differences from each of the parents to the merge + result simultaneously instead of showing pairwise diff between + a parent and the result one at a time. Furthermore, it lists + only files which were modified from all parents. + ---diff-merges=remerge::: ---diff-merges=r::: ---remerge-diff::: - With this option, two-parent merge commits are remerged to - create a temporary tree object -- potentially containing files - with conflict markers and such. A diff is then shown between - that temporary tree and the actual merge commit. +dense-combined, cc:: + Further compress output produced by `--diff-merges=combined` + by omitting uninteresting hunks whose contents in the parents + have only two variants and the merge result picks one of them + without modification. ++ +remerge, r:: + Remerge two-parent merge commits to create a temporary tree + object--potentially containing files with conflict markers + and such. A diff is then shown between that temporary tree + and the actual merge commit. + The output emitted when this option is used is subject to change, and so is its interaction with other options (unless explicitly documented). -+ ---diff-merges=combined::: ---diff-merges=c::: --c::: - With this option, diff output for a merge commit shows the - differences from each of the parents to the merge result - simultaneously instead of showing pairwise diff between a - parent and the result one at a time. Furthermore, it lists - only files which were modified from all parents. `-c` implies - `-p`. -+ ---diff-merges=dense-combined::: ---diff-merges=cc::: ---cc::: - With this option the output produced by - `--diff-merges=combined` is further compressed by omitting - uninteresting hunks whose contents in the parents have only - two variants and the merge result picks one of them without - modification. `--cc` implies `-p`. +-- --combined-all-paths:: This flag causes combined diffs (used for merge commits) to @@ -204,14 +217,15 @@ have to use `--diff-algorithm=default` option. part. Maximum width defaults to terminal width, or 80 columns if not connected to a terminal, and can be overridden by `<width>`. The width of the filename part can be limited by - giving another width `<name-width>` after a comma. The width - of the graph part can be limited by using - `--stat-graph-width=<width>` (affects all commands generating - a stat graph) or by setting `diff.statGraphWidth=<width>` - (does not affect `git format-patch`). - By giving a third parameter `<count>`, you can limit the - output to the first `<count>` lines, followed by `...` if - there are more. + giving another width `<name-width>` after a comma or by setting + `diff.statNameWidth=<width>`. The width of the graph part can be + limited by using `--stat-graph-width=<width>` or by setting + `diff.statGraphWidth=<width>`. Using `--stat` or + `--stat-graph-width` affects all commands generating a stat graph, + while setting `diff.statNameWidth` or `diff.statGraphWidth` + does not affect `git format-patch`. + By giving a third parameter `<count>`, you can limit the output to + the first `<count>` lines, followed by `...` if there are more. + These parameters can also be set individually with `--stat-width=<width>`, `--stat-name-width=<name-width>` and `--stat-count=<count>`. @@ -285,7 +299,7 @@ and accumulating child directory counts in the parent directories: Synonym for --dirstat=cumulative --dirstat-by-file[=<param1,param2>...]:: - Synonym for --dirstat=files,param1,param2... + Synonym for --dirstat=files,<param1>,<param2>... --summary:: Output a condensed summary of extended header information @@ -300,7 +314,7 @@ ifndef::git-format-patch[] -z:: ifdef::git-log[] - Separate the commits with NULs instead of with new newlines. + Separate the commits with NULs instead of newlines. + Also, when `--raw` or `--numstat` has been given, do not munge pathnames and use NULs as output field terminators. @@ -315,12 +329,13 @@ explained for the configuration variable `core.quotePath` (see linkgit:git-config[1]). --name-only:: - Show only names of changed files. The file names are often encoded in UTF-8. + Show only the name of each changed file in the post-image tree. + The file names are often encoded in UTF-8. For more information see the discussion about encoding in the linkgit:git-log[1] manual page. --name-status:: - Show only names and status of changed files. See the description + Show only the name(s) and status of each changed file. See the description of the `--diff-filter` option on what the status letters mean. Just like `--name-only` the file names are often encoded in UTF-8. @@ -732,7 +747,7 @@ matches "`fooasdfbar`" and "`foo/bar/baz/asdf`" but not "`foobarx`". --rotate-to=<file>:: Discard the files before the named <file> from the output (i.e. 'skip to'), or move them to the end of the output - (i.e. 'rotate to'). These were invented primarily for use + (i.e. 'rotate to'). These options were invented primarily for the use of the `git difftool` command, and may not be very useful otherwise. @@ -805,6 +820,11 @@ ifndef::git-log[] --quiet:: Disable all output of the program. Implies `--exit-code`. + Disables execution of external diff helpers whose exit code + is not trusted, i.e. their respective configuration option + `diff.trustExitCode` or `diff.<driver>.trustExitCode` or + environment variable `GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE` is + false. endif::git-log[] endif::git-format-patch[] @@ -851,8 +871,9 @@ endif::git-format-patch[] --default-prefix:: Use the default source and destination prefixes ("a/" and "b/"). - This is usually the default already, but may be used to override - config such as `diff.noprefix`. + This overrides configuration variables such as `diff.noprefix`, + `diff.srcPrefix`, `diff.dstPrefix`, and `diff.mnemonicPrefix` + (see `git-config`(1)). --line-prefix=<prefix>:: Prepend an additional prefix to every line of output. diff --git a/Documentation/docinfo-html.in b/Documentation/docinfo-html.in new file mode 100644 index 0000000000..fb3560eb92 --- /dev/null +++ b/Documentation/docinfo-html.in @@ -0,0 +1,5 @@ +<style> +pre>code { + display: inline; +} +</style> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 41fc7ca3c6..b01372e4b3 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -1,5 +1,7 @@ ---all:: - Fetch all remotes. +--[no-]all:: + Fetch all remotes, except for the ones that has the + `remote.<name>.skipFetchAll` configuration variable set. + This overrides the configuration variable fetch.all`. -a:: --append:: @@ -27,7 +29,7 @@ Deepen or shorten the history of a shallow repository to include all reachable commits after <date>. ---shallow-exclude=<revision>:: +--shallow-exclude=<ref>:: 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. @@ -43,7 +45,7 @@ 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 + .git/shallow. This option updates .git/shallow and accepts such refs. --negotiation-tip=<commit|glob>:: @@ -96,7 +98,7 @@ endif::git-pull[] -f:: --force:: - When 'git fetch' is used with `<src>:<dst>` refspec it may + 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] @@ -201,7 +203,7 @@ endif::git-pull[] destination of an explicit refspec; see `--prune`). ifndef::git-pull[] ---recurse-submodules[=yes|on-demand|no]:: +--recurse-submodules[=(yes|on-demand|no)]:: This option controls if and under what conditions new commits of submodules should be fetched too. When recursing through submodules, `git fetch` always attempts to fetch "changed" submodules, that is, a @@ -303,6 +305,9 @@ endif::git-pull[] 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. + When no `--server-option=<option>` is given from the command line, + the values of configuration variable `remote.<name>.serverOption` + are used instead. --show-forced-updates:: By default, git checks if a branch is force-updated during diff --git a/Documentation/fsck-msgids.txt b/Documentation/fsck-msgids.txt index 12eae8a222..b14bc44ca4 100644 --- a/Documentation/fsck-msgids.txt +++ b/Documentation/fsck-msgids.txt @@ -19,6 +19,18 @@ `badParentSha1`:: (ERROR) A commit object has a bad parent sha1. +`badRefContent`:: + (ERROR) A ref has bad content. + +`badRefFiletype`:: + (ERROR) A ref has a bad file type. + +`badRefName`:: + (ERROR) A ref has an invalid format. + +`badReferentName`:: + (ERROR) The referent name of a symref is invalid. + `badTagName`:: (INFO) A tag has an invalid format. @@ -103,6 +115,13 @@ `hasDotgit`:: (WARN) A tree contains an entry named `.git`. +`largePathname`:: + (WARN) A tree contains an entry with a very long path name. If + the value of `fsck.largePathname` contains a colon, that value + is used as the maximum allowable length (e.g., "warn:10" would + complain about any path component of 11 or more bytes). The + default value is 4096. + `mailmapSymlink`:: (INFO) `.mailmap` is a symlink. @@ -125,7 +144,7 @@ (ERROR) Missing space before date in an author/committer line. `missingSpaceBeforeEmail`:: - (ERROR) Missing space before the email in author/committer line. + (ERROR) Missing space before the email in an author/committer line. `missingTag`:: (ERROR) Unexpected end after `type` line in a tag object. @@ -157,6 +176,35 @@ `nullSha1`:: (WARN) Tree contains entries pointing to a null sha1. +`refMissingNewline`:: + (INFO) A loose ref that does not end with newline(LF). As + valid implementations of Git never created such a loose ref + file, it may become an error in the future. Report to the + git@vger.kernel.org mailing list if you see this error, as + we need to know what tools created such a file. + +`symlinkRef`:: + (INFO) A symbolic link is used as a symref. Report to the + git@vger.kernel.org mailing list if you see this error, as we + are assessing the feasibility of dropping the support to drop + creating symbolic links as symrefs. + +`symrefTargetIsNotARef`:: + (INFO) The target of a symbolic reference points neither to + a root reference nor to a reference starting with "refs/". + Although we allow create a symref pointing to the referent which + is outside the "ref" by using `git symbolic-ref`, we may tighten + the rule in the future. Report to the git@vger.kernel.org + mailing list if you see this error, as we need to know what tools + created such a file. + +`trailingRefContent`:: + (INFO) A loose ref has trailing content. As valid implementations + of Git never created such a loose ref file, it may become an + error in the future. Report to the git@vger.kernel.org mailing + list if you see this error, as we need to know what tools + created such a file. + `treeNotSorted`:: (ERROR) A tree is not properly sorted. @@ -167,7 +215,7 @@ (FATAL) Missing end-of-line in the object header. `zeroPaddedDate`:: - (ERROR) Found a zero padded date in an author/commiter line. + (ERROR) Found a zero padded date in an author/committer line. `zeroPaddedFilemode`:: (WARN) Found a zero padded filemode in a tree. diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index ed44c1cb31..5f2c3592b8 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -7,12 +7,12 @@ git-add - Add file contents to the index SYNOPSIS -------- -[verse] -'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] - [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--sparse] - [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize] - [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]] - [--] [<pathspec>...] +[synopsis] +git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] + [--edit | -e] [--[no-]all | -A | --[no-]ignore-removal | [--update | -u]] [--sparse] + [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize] + [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]] + [--] [<pathspec>...] DESCRIPTION ----------- @@ -41,7 +41,7 @@ The `git add` command will not add ignored files by default. If any ignored files were explicitly specified on the command line, `git add` will fail with a list of ignored files. Ignored files reached by directory recursion or filename globbing performed by Git (quote your -globs before the shell) will be silently ignored. The 'git add' command can +globs before the shell) will be silently ignored. The `git add` command can be used to add ignored files with the `-f` (force) option. Please see linkgit:git-commit[1] for alternative ways to add content to a @@ -50,7 +50,7 @@ commit. OPTIONS ------- -<pathspec>...:: +`<pathspec>...`:: Files to add content from. Fileglobs (e.g. `*.c`) can be given to add all matching files. Also a leading directory name (e.g. `dir` to add `dir/file1` @@ -63,38 +63,38 @@ OPTIONS 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 +For more details about the _<pathspec>_ syntax, see the 'pathspec' entry in linkgit:gitglossary[7]. --n:: ---dry-run:: +`-n`:: +`--dry-run`:: Don't actually add the file(s), just show if they exist and/or will be ignored. --v:: ---verbose:: +`-v`:: +`--verbose`:: Be verbose. --f:: ---force:: +`-f`:: +`--force`:: Allow adding otherwise ignored files. ---sparse:: +`--sparse`:: Allow updating index entries outside of the sparse-checkout cone. Normally, `git add` refuses to update index entries whose paths do not fit within the sparse-checkout cone, since those files might be removed from the working tree without warning. See linkgit:git-sparse-checkout[1] for more details. --i:: ---interactive:: +`-i`:: +`--interactive`:: Add modified contents in the working tree interactively to the index. Optional path arguments may be supplied to limit operation to a subset of the working tree. See ``Interactive mode'' for details. --p:: ---patch:: +`-p`:: +`--patch`:: Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the @@ -104,8 +104,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. @@ -116,101 +116,101 @@ quicker and more flexible than using the interactive hunk selector. However, it is easy to confuse oneself and create a patch that does not apply to the index. See EDITING PATCHES below. --u:: ---update:: +`-u`:: +`--update`:: Update the index just where it already has an entry matching - <pathspec>. This removes as well as modifies index entries to + _<pathspec>_. This removes as well as modifies index entries to match the working tree, but adds no new files. + -If no <pathspec> is given when `-u` option is used, all +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:: +`-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 + matching _<pathspec>_ but also where the index already has an entry. This adds, modifies, and removes index entries to match the working tree. + -If no <pathspec> is given when `-A` option is used, all +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:: +`--no-all`:: +`--ignore-removal`:: Update the index by adding new files that are unknown to the index and files modified in the working tree, but ignore files that have been removed from the working tree. This - option is a no-op when no <pathspec> is used. + option is a no-op when no _<pathspec>_ is used. + This option is primarily to help users who are used to older -versions of Git, whose "git add <pathspec>..." was a synonym -for "git add --no-all <pathspec>...", i.e. ignored removed files. +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:: +`-N`:: +`--intent-to-add`:: Record only the fact that the path will be added later. An entry for the path is placed in the index with no content. This is useful for, among other things, showing the unstaged content of such files with `git diff` and committing them with `git commit -a`. ---refresh:: +`--refresh`:: Don't add the file(s), but only refresh their stat() information in the index. ---ignore-errors:: +`--ignore-errors`:: If some files could not be added because of errors indexing them, do not abort the operation, but continue adding the others. The command shall still exit with non-zero status. The configuration variable `add.ignoreErrors` can be set to true to make this the default behaviour. ---ignore-missing:: - This option can only be used together with --dry-run. By using +`--ignore-missing`:: + This option can only be used together with `--dry-run`. By using this option the user can check if any of the given files would be ignored, no matter if they are already present in the work tree or not. ---no-warn-embedded-repo:: +`--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:: +`--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. + in order to correct files added with wrong _CRLF/LF_ line endings. This option implies `-u`. Lone CR characters are untouched, thus - while a CRLF cleans to LF, a CRCRLF sequence is only partially - cleaned to CRLF. + while a _CRLF_ cleans to _LF_, a _CRCRLF_ sequence is only partially + cleaned to _CRLF_. ---chmod=(+|-)x:: +`--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 +`--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:: +`--pathspec-file-nul`:: Only meaningful with `--pathspec-from-file`. Pathspec elements are - separated with NUL character and all other characters are taken + 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). @@ -219,18 +219,18 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files. EXAMPLES -------- -* Adds content from all `*.txt` files under `Documentation` directory +* Adds content from all ++*.txt++ files under `Documentation` directory and its subdirectories: + ------------ $ git add Documentation/\*.txt ------------ + -Note that the asterisk `*` is quoted from the shell in this +Note that the asterisk ++*++ is quoted from the shell in this example; this lets the command include the files from subdirectories of `Documentation/` directory. -* Considers adding content from all git-*.sh scripts: +* Considers adding content from all ++git-*.sh++ scripts: + ------------ $ git add git-*.sh @@ -265,7 +265,7 @@ The main command loop has 6 subcommands (plus help and quit). status:: - This shows the change between HEAD and index (i.e. what will be + This shows the change between `HEAD` and index (i.e. what will be committed if you say `git commit`), and between index and working tree files (i.e. what you could stage further before `git commit` using `git add`) for each path. A sample output @@ -277,12 +277,12 @@ status:: 2: +403/-35 +1/-1 add-interactive.c ------------ + -It shows that foo.png has differences from HEAD (but that is +It shows that `foo.png` has differences from `HEAD` (but that is binary so line count cannot be shown) and there is no difference between indexed copy and the working tree version (if the working tree version were also different, 'binary' would have been shown in place of 'nothing'). The -other file, add-interactive.c, has 403 lines added +other file, `add-interactive.c`, has 403 lines added and 35 lines deleted if you commit what is in the index, but working tree file has further modifications (one addition and one deletion). @@ -348,6 +348,7 @@ patch:: K - leave this hunk undecided, see previous hunk s - split the current hunk into smaller hunks e - manually edit the current hunk + p - print the current hunk ? - print help + After deciding the fate for all hunks, if there is any hunk @@ -359,7 +360,7 @@ variable `interactive.singleKey` to `true`. diff:: This lets you review what will be committed (i.e. between - HEAD and index). + `HEAD` and index). EDITING PATCHES @@ -398,7 +399,7 @@ There are also more complex operations that can be performed. But beware that because the patch is applied only to the index and not the working tree, the working tree will appear to "undo" the change in the index. For example, introducing a new line into the index that is in neither -the HEAD nor the working tree will stage the new line for commit, but +the `HEAD` nor the working tree will stage the new line for commit, but the line will appear to be reverted in the working tree. Avoid using these constructs, or do so with extreme caution. @@ -438,6 +439,7 @@ CONFIGURATION include::includes/cmd-config-section-all.txt[] +:git-add: 1 include::config/add.txt[] SEE ALSO diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index 82dadbecc8..69d5cc9f21 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -18,12 +18,12 @@ SYNOPSIS [--quoted-cr=<action>] [--empty=(stop|drop|keep)] [(<mbox> | <Maildir>)...] -'git am' (--continue | --skip | --abort | --quit | --show-current-patch[=(diff|raw)] | --allow-empty) +'git am' (--continue | --skip | --abort | --quit | --retry | --show-current-patch[=(diff|raw)] | --allow-empty) DESCRIPTION ----------- -Splits mail messages in a mailbox into commit log message, -authorship information and patches, and applies them to the +Splits mail messages in a mailbox into commit log messages, +authorship information, and patches, and applies them to the current branch. You could think of it as a reverse operation of linkgit:git-format-patch[1] run on a branch with a straight history without merges. @@ -66,13 +66,19 @@ OPTIONS --quoted-cr=<action>:: This flag will be passed down to 'git mailinfo' (see linkgit:git-mailinfo[1]). ---empty=(stop|drop|keep):: - By default, or when the option is set to 'stop', the command - errors out on an input e-mail message lacking a patch - and stops into the middle of the current am session. When this - option is set to 'drop', skip such an e-mail message instead. - When this option is set to 'keep', create an empty commit, - recording the contents of the e-mail message as its log. +--empty=(drop|keep|stop):: + How to handle an e-mail message lacking a patch: ++ +-- +`drop`;; + The e-mail message will be skipped. +`keep`;; + An empty commit will be created, with the contents of the e-mail + message as its log. +`stop`;; + The command will fail, stopping in the middle of the current `am` + session. This is the default behavior. +-- -m:: --message-id:: @@ -94,7 +100,7 @@ OPTIONS Pass `-u` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]). The proposed commit log message taken from the e-mail is re-coded into UTF-8 encoding (configuration variable - `i18n.commitEncoding` can be used to specify project's + `i18n.commitEncoding` can be used to specify the project's preferred encoding if it is not UTF-8). + This was optional in prior versions of git, but now it is the @@ -128,13 +134,16 @@ include::rerere-options.txt[] These flags are passed to the 'git apply' (see linkgit:git-apply[1]) program that applies the patch. ++ +Valid <action> for the `--whitespace` option are: +`nowarn`, `warn`, `fix`, `error`, and `error-all`. --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. + stgit, stgit-series, and hg. -i:: --interactive:: @@ -192,13 +201,19 @@ include::rerere-options.txt[] --abort:: Restore the original branch and abort the patching operation. - Revert contents of files involved in the am operation to their + Revert the contents of files involved in the am operation to their pre-am state. --quit:: Abort the patching operation but keep HEAD and the index untouched. +--retry:: + Try to apply the last conflicting patch again. This is generally + only useful for passing extra options to the retry attempt + (e.g., `--3way`), since otherwise you'll just see the same + failure again. + --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 diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index 5e16e6db7e..dd4a61ef28 100644 --- a/Documentation/git-apply.txt +++ b/Documentation/git-apply.txt @@ -9,7 +9,8 @@ git-apply - Apply a patch to files and/or to the index SYNOPSIS -------- [verse] -'git apply' [--stat] [--numstat] [--summary] [--check] [--index | --intent-to-add] [--3way] +'git apply' [--stat] [--numstat] [--summary] [--check] + [--index | --intent-to-add] [--3way] [--ours | --theirs | --union] [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse] [--allow-binary-replacement | --binary] [--reject] [-z] [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached] @@ -23,8 +24,8 @@ 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. +With the `--index` option, the patch is also applied to the index, and +with the `--cached` option, the patch is only applied to the index. Without these options, the command applies the patch only to files, and does not require them to be in a Git repository. @@ -52,7 +53,7 @@ OPTIONS --summary:: Instead of applying the patch, output a condensed summary of information obtained from git diff extended - headers, such as creations, renames and mode changes. + headers, such as creations, renames, and mode changes. Turns off "apply". --check:: @@ -92,6 +93,12 @@ OPTIONS When used with the `--cached` option, any conflicts are left at higher stages in the cache. +--ours:: +--theirs:: +--union:: + Instead of leaving conflicts in the file, resolve conflicts favouring + our (or their or both) side of the lines. Requires --3way. + --build-fake-ancestor=<file>:: Newer 'git diff' output has embedded 'index information' for each blob to help identify the original version that @@ -140,7 +147,7 @@ linkgit:git-config[1]). applying a diff generated with `--unified=0`. To bypass these checks use `--unidiff-zero`. + -Note, for the reasons stated above usage of context-free patches is +Note, for the reasons stated above, the usage of context-free patches is discouraged. --apply:: @@ -159,9 +166,9 @@ discouraged. --allow-binary-replacement:: --binary:: - Historically we did not allow binary patch applied + Historically we did not allow binary patch application without an explicit permission from the user, and this - flag was the way to do so. Currently we always allow binary + flag was the way to do so. Currently, we always allow binary patch application, so this is a no-op. --exclude=<path-pattern>:: @@ -257,7 +264,7 @@ the `--unsafe-paths` option to override this safety check. This option has no effect when `--index` or `--cached` is in use. --allow-empty:: - Don't return error for patches containing no diff. This includes + Don't return an error for patches containing no diff. This includes empty patches and patches with commit text only. CONFIGURATION diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt index 6bab201d37..a0e3fe7996 100644 --- a/Documentation/git-archive.txt +++ b/Documentation/git-archive.txt @@ -21,14 +21,14 @@ structure for the named tree, and writes it out to the standard output. If <prefix> is specified it is prepended to the filenames in the archive. -'git archive' behaves differently when given a tree ID versus when -given a commit ID or tag ID. In the first case the current time is -used as the modification time of each file in the archive. In the latter -case the commit time as recorded in the referenced commit object is -used instead. Additionally the commit ID is stored in a global -extended pax header if the tar format is used; it can be extracted -using 'git get-tar-commit-id'. In ZIP files it is stored as a file -comment. +'git archive' behaves differently when given a tree ID as opposed to a +commit ID or tag ID. When a tree ID is provided, the current time is +used as the modification time of each file in the archive. On the +other hand, when a commit ID or tag ID is provided, the commit time as +recorded in the referenced commit object is used instead. +Additionally the commit ID is stored in a global extended pax header +if the tar format is used; it can be extracted using 'git +get-tar-commit-id'. In ZIP files it is stored as a file comment. OPTIONS ------- @@ -53,7 +53,7 @@ OPTIONS --prefix=<prefix>/:: Prepend <prefix>/ to paths in the archive. Can be repeated; its rightmost value is used for all tracked files. See below which - value gets used by `--add-file` and `--add-virtual-file`. + value gets used by `--add-file`. -o <file>:: --output=<file>:: @@ -67,9 +67,7 @@ OPTIONS --add-virtual-file=<path>:<content>:: Add the specified contents to the archive. Can be repeated to add - multiple files. The path of the file in the archive is built - by concatenating the value of the last `--prefix` option (if any) - before this `--add-virtual-file` and `<path>`. + multiple files. + The `<path>` argument can start and end with a literal double-quote character; the contained file name is interpreted as a C-style string, @@ -81,6 +79,10 @@ if the path begins or ends with a double-quote character. The file mode is limited to a regular file, and the option may be subject to platform-dependent command-line limits. For non-trivial cases, write an untracked file and use `--add-file` instead. ++ +Note that unlike `--add-file` the path created in the archive is not +affected by the `--prefix` option, as a full `<path>` can be given as +the value of the option. --worktree-attributes:: Look for attributes in .gitattributes files in the working tree diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index 7872dba3ae..82f944dc03 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -16,17 +16,17 @@ DESCRIPTION The command takes various subcommands, and different options depending on the subcommand: - git bisect start [--term-{new,bad}=<term> --term-{old,good}=<term>] - [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<paths>...] + git bisect start [--term-(bad|new)=<term-new> --term-(good|old)=<term-old>] + [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<pathspec>...] git bisect (bad|new|<term-new>) [<rev>] git bisect (good|old|<term-old>) [<rev>...] - git bisect terms [--term-good | --term-bad] + git bisect terms [--term-(good|old) | --term-(bad|new)] git bisect skip [(<rev>|<range>)...] git bisect reset [<commit>] git bisect (visualize|view) git bisect replay <logfile> git bisect log - git bisect run <cmd>... + git bisect run <cmd> [<arg>...] git bisect help This command uses a binary search algorithm to find which commit in @@ -165,8 +165,10 @@ 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`. +You can get just the old term with `git bisect terms --term-old` +or `git bisect terms --term-good`; `git bisect terms --term-new` +and `git bisect terms --term-bad` can be used to learn how to call +the commits more recent than the sought change. 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 @@ -299,7 +301,7 @@ Cutting down bisection by giving more parameters to bisect start You can further cut down the number of trials, if you know what part of the tree is involved in the problem you are tracking down, by specifying -path parameters when issuing the `bisect start` command: +pathspec parameters when issuing the `bisect start` command: ------------ $ git bisect start -- arch/i386 include/asm-i386 @@ -362,7 +364,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 the 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 diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index f69a871a96..b1d7fb539d 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -77,7 +77,7 @@ include::blame-options.txt[] -e:: --show-email:: - Show the author email instead of author name (Default: off). + Show the author email instead of the author name (Default: off). This can also be controlled via the `blame.showEmail` config option. @@ -100,7 +100,7 @@ When neither `--porcelain` nor `--incremental` option is specified, `git blame` will output annotation for each line with: - abbreviated object name for the commit the line came from; -- author ident (by default author name and date, unless `-s` or `-e` +- author ident (by default the author name and date, unless `-s` or `-e` is specified); and - line number @@ -128,7 +128,7 @@ at least once for each commit: - the filename in the commit that the line is attributed to. - the first line of the commit log message ("summary"). -The contents of the actual line is output after the above +The contents of the actual line are output after the above header, prefixed by a TAB. This is to allow adding more header elements later. @@ -170,7 +170,7 @@ which limits the annotation to the body of the `hello` subroutine. When you are not interested in changes older than version v2.6.18, or changes older than 3 weeks, you can use revision -range specifiers similar to 'git rev-list': +range specifiers similar to 'git rev-list': git blame v2.6.18.. -- foo git blame --since=3.weeks -- foo @@ -210,7 +210,7 @@ annotated. . Each blame entry always starts with a line of: - <40-byte hex sha1> <sourceline> <resultline> <num_lines> + <40-byte-hex-sha1> <sourceline> <resultline> <num-lines> + Line numbers count from 1. diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index d207da9101..0b08442932 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -312,7 +312,8 @@ superproject's "origin/main", but tracks the submodule's "origin/main". option is omitted, the current HEAD will be used instead. <oldbranch>:: - The name of an existing branch to rename. + The name of an existing branch. If this option is omitted, + the name of the current branch will be used instead. <newbranch>:: The new name for an existing branch. The same restrictions as for @@ -324,7 +325,7 @@ superproject's "origin/main", but tracks the submodule's "origin/main". 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 + `branch.sort` variable if it 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]. diff --git a/Documentation/git-bugreport.txt b/Documentation/git-bugreport.txt index eca726e579..112658b3c3 100644 --- a/Documentation/git-bugreport.txt +++ b/Documentation/git-bugreport.txt @@ -8,15 +8,17 @@ git-bugreport - Collect information for user to file a bug report SYNOPSIS -------- [verse] -'git bugreport' [(-o | --output-directory) <path>] [(-s | --suffix) <format>] +'git bugreport' [(-o | --output-directory) <path>] + [(-s | --suffix) <format> | --no-suffix] [--diagnose[=<mode>]] 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. +Collects information about the user's machine, Git client, and repository +state, in addition to a form requesting information about the behavior the +user observed, and stores it in 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: @@ -50,16 +52,19 @@ OPTIONS -s <format>:: --suffix <format>:: +--no-suffix:: Specify an alternate suffix for the bugreport name, to create a file - named 'git-bugreport-<formatted suffix>'. This should take the form of a + named 'git-bugreport-<formatted-suffix>'. This should take the form of a strftime(3) format string; the current local time will be used. + `--no-suffix` disables the suffix and the file is just named + `git-bugreport` without any disambiguation measure. --no-diagnose:: --diagnose[=<mode>]:: Create a zip archive of supplemental information about the user's machine, Git client, and repository state. The archive is written to the same output directory as the bug report and is named - 'git-diagnostics-<formatted suffix>'. + 'git-diagnostics-<formatted-suffix>'. + Without `mode` specified, the diagnostic archive will contain the default set of statistics reported by `git diagnose`. An optional `mode` value may be specified diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt index 3ab42a19ca..504b8a8143 100644 --- a/Documentation/git-bundle.txt +++ b/Documentation/git-bundle.txt @@ -23,8 +23,9 @@ the "offline" transfer of Git objects without an active "server" sitting on the other side of the network connection. They can be used to create both incremental and full backups of a -repository, and to relay the state of the references in one repository -to another. +repository (see the "full backup" example in "EXAMPLES"), and to relay +the state of the references in one repository to another (see the second +example). Git commands that fetch or otherwise "read" via protocols such as `ssh://` and `https://` can also operate on bundle files. It is @@ -34,8 +35,6 @@ contained within it with linkgit:git-ls-remote[1]. There's no corresponding "write" support, i.e.a 'git push' into a bundle is not supported. -See the "EXAMPLES" section below for examples of how to use bundles. - BUNDLE FORMAT ------------- @@ -132,7 +131,7 @@ SPECIFYING REFERENCES --------------------- Revisions must be accompanied by reference names to be packaged in a -bundle. +bundle. Alternatively `--all` can be used to package all refs. More than one reference may be packaged, and more than one set of prerequisite objects can be specified. The objects packaged are those not contained in the @@ -203,8 +202,6 @@ 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. -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>`. @@ -216,8 +213,34 @@ bundle. EXAMPLES -------- -Assume you want to transfer the history from a repository R1 on machine A -to another repository R2 on machine B. +We'll discuss two cases: + +1. Taking a full backup of a repository +2. Transferring the history of a repository to another machine when the + two machines have no direct connection + +First let's consider a full backup of the repository. The following +command will take a full backup of the repository in the sense that all +refs are included in the bundle: + +---------------- +$ git bundle create backup.bundle --all +---------------- + +But note again that this is only for the refs, i.e. you will only +include refs and commits reachable from those refs. You will not +include other local state, such as the contents of the index, working +tree, the stash, per-repository configuration, hooks, etc. + +You can later recover that repository by using for example +linkgit:git-clone[1]: + +---------------- +$ git clone backup.bundle <new directory> +---------------- + +For the next example, assume you want to transfer the history from a +repository R1 on machine A to another repository R2 on machine B. For whatever reason, direct connection between A and B is not allowed, but we can move data from A to B via some mechanism (CD, email, etc.). We want to update R2 with development made on the branch master in R1. @@ -321,6 +344,24 @@ You can also see what references it offers: $ git ls-remote mybundle ---------------- +DISCUSSION +---------- + +A naive way to make a full backup of a repository is to use something to +the effect of `cp -r <repo> <destination>`. This is discouraged since +the repository could be written to during the copy operation. In turn +some files at `<destination>` could be corrupted. + +This is why it is recommended to use Git tooling for making repository +backups, either with this command or with e.g. linkgit:git-clone[1]. +But keep in mind that these tools will not help you backup state other +than refs and commits. In other words they will not help you backup +contents of the index, working tree, the stash, per-repository +configuration, hooks, etc. + +See also linkgit:gitfaq[7], section "TRANSFERS" for a discussion of the +problems associated with file syncing across systems. + FILE FORMAT ----------- diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index bd95a6c10a..d5890ae368 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -270,9 +270,9 @@ BATCH OUTPUT ------------ If `--batch` or `--batch-check` is given, `cat-file` will read objects -from stdin, one per line, and print information about them. By default, -the whole line is considered as an object, as if it were fed to -linkgit:git-rev-parse[1]. +from stdin, one per line, and print information about them in the same +order as they have been read. By default, the whole line is +considered as an object, as if it were fed to linkgit:git-rev-parse[1]. When `--batch-command` is given, `cat-file` will read commands from stdin, one per line, and print information based on the command given. With diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt index 6e4f3aaf34..cb5a6c8f33 100644 --- a/Documentation/git-check-attr.txt +++ b/Documentation/git-check-attr.txt @@ -29,7 +29,7 @@ OPTIONS --stdin:: Read pathnames from the standard input, one per line, - instead of from the command-line. + instead of from the command line. -z:: The output format is modified to be machine-parsable. @@ -38,7 +38,7 @@ OPTIONS --source=<tree-ish>:: Check attributes against the specified tree-ish. It is common to - specify the source tree by naming a commit, branch or tag associated + specify the source tree by naming a commit, branch, or tag associated with it. \--:: @@ -60,7 +60,7 @@ unless `-z` is in effect, in which case NUL is used as delimiter: <path> is the path of a file being queried, <attribute> is an attribute -being queried and <info> can be either: +being queried, and <info> can be either: 'unspecified';; when the attribute is not defined for the path. 'unset';; when the attribute is defined as false. diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt index 2892799e32..3e3b4e3446 100644 --- a/Documentation/git-check-ignore.txt +++ b/Documentation/git-check-ignore.txt @@ -50,7 +50,7 @@ linkgit:gitignore[5]. with a NUL character instead of a linefeed character. -n, --non-matching:: - Show given paths which don't match any pattern. This only + Show given paths which don't match any pattern. This only makes sense when `--verbose` is enabled, otherwise it would not be possible to distinguish between paths which match a pattern and those which don't. diff --git a/Documentation/git-check-mailmap.txt b/Documentation/git-check-mailmap.txt index 02f4418323..966c91c46a 100644 --- a/Documentation/git-check-mailmap.txt +++ b/Documentation/git-check-mailmap.txt @@ -15,10 +15,10 @@ SYNOPSIS DESCRIPTION ----------- -For each ``Name $$<user@host>$$'' or ``$$<user@host>$$'' from the command-line -or standard input (when using `--stdin`), look up the person's canonical name -and email address (see "Mapping Authors" below). If found, print them; -otherwise print the input as-is. +For each ``Name $$<user@host>$$'', ``$$<user@host>$$'', or ``$$user@host$$'' +from the command-line or standard input (when using `--stdin`), look up the +person's canonical name and email address (see "Mapping Authors" below). If +found, print them; otherwise print the input as-is. OPTIONS @@ -27,6 +27,16 @@ OPTIONS Read contacts, one per line, from the standard input after exhausting contacts provided on the command-line. +--mailmap-file=<file>:: + In addition to any configured mailmap files, read the specified + mailmap file. Entries in this file take precedence over entries in + either the default mailmap file or any configured mailmap file. + +--mailmap-blob=<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 specified, entries in `--mailmap-file` will + take precedence. OUTPUT ------ diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index ee6a4144fb..2aacfd1808 100644 --- a/Documentation/git-check-ref-format.txt +++ b/Documentation/git-check-ref-format.txt @@ -48,7 +48,7 @@ Git imposes the following rules on how references are named: . They cannot begin or end with a slash `/` or contain multiple consecutive slashes (see the `--normalize` option below for an - exception to this rule) + exception to this rule). . They cannot end with a dot `.`. @@ -85,7 +85,7 @@ 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 +When run with the `--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. diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt index 01dbd5cbf5..faf8d6ca36 100644 --- a/Documentation/git-checkout-index.txt +++ b/Documentation/git-checkout-index.txt @@ -18,7 +18,7 @@ SYNOPSIS DESCRIPTION ----------- -Will copy all files listed from the index to the working directory +Copies all listed files from the index to the working directory (not overwriting existing files). OPTIONS @@ -53,11 +53,11 @@ OPTIONS --stage=<number>|all:: Instead of checking out unmerged entries, copy out the - files from named stage. <number> must be between 1 and 3. + files from the named stage. <number> must be between 1 and 3. Note: --stage=all automatically implies --temp. --temp:: - Instead of copying the files to the working directory + Instead of copying the files to the working directory, write the content to temporary files. The temporary name associations will be written to stdout. @@ -66,8 +66,8 @@ OPTIONS set. --stdin:: - Instead of taking list of paths from the command line, - read list of paths from the standard input. Paths are + Instead of taking a list of paths from the command line, + read the list of paths from the standard input. Paths are separated by LF (i.e. one path per line) by default. -z:: diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 4af0904f47..bf26655764 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -12,8 +12,10 @@ 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>] [--] <pathspec>... -'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul] +'git checkout' [-f] <tree-ish> [--] <pathspec>... +'git checkout' [-f] <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul] +'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>... +'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul] 'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...] DESCRIPTION @@ -41,7 +43,7 @@ $ git checkout -b <branch> --track <remote>/<branch> You could omit `<branch>`, in which case the command degenerates to "check out the current branch", which is a glorified no-op with rather expensive side-effects to show only the tracking information, -if exists, for the current branch. +if it exists, for the current branch. 'git checkout' -b|-B <new-branch> [<start-point>]:: @@ -61,7 +63,9 @@ $ git checkout <branch> ------------ + that is to say, the branch is not reset/created unless "git checkout" is -successful. +successful (e.g., when the branch is in use in another worktree, not +just the current branch stays the same, but the branch is not reset to +the start-point, either). 'git checkout' --detach [<branch>]:: 'git checkout' [--detach] <commit>:: @@ -213,7 +217,7 @@ variable. below for details. --orphan <new-branch>:: - Create a new 'orphan' branch, named `<new-branch>`, started from + Create a new unborn 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 @@ -260,7 +264,8 @@ and mark the resolved paths with `git add` (or `git rm` if the merge should result in deletion of the path). + When checking out paths from the index, this option lets you recreate -the conflicted merge in the specified paths. +the conflicted merge in the specified paths. This option cannot be +used when checking out paths from a tree-ish. + When switching branches with `--merge`, staged changes may be lost. @@ -285,10 +290,10 @@ 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. + `git checkout` refuses when the wanted branch is already checked + out or otherwise in use by another worktree. This option makes + it check the branch out anyway. In other words, the branch can + be in use by more than one worktree. --overwrite-ignore:: --no-overwrite-ignore:: diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index fdcad3d200..81ace900fc 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -131,20 +131,36 @@ effect to your index in a row. even without this option. Note also, that use of this option only keeps commits that were initially empty (i.e. the commit recorded the same tree as its parent). Commits which are made empty due to a - previous commit are dropped. To force the inclusion of those commits - use `--keep-redundant-commits`. + previous commit will cause the cherry-pick to fail. To force the + inclusion of those commits, use `--empty=keep`. --allow-empty-message:: By default, cherry-picking a commit with an empty message will fail. This option overrides that behavior, allowing commits with empty messages to be cherry picked. +--empty=(drop|keep|stop):: + How to handle commits being cherry-picked that are redundant with + changes already in the current history. ++ +-- +`drop`;; + The commit will be dropped. +`keep`;; + The commit will be kept. Implies `--allow-empty`. +`stop`;; + The cherry-pick will stop when the commit is applied, allowing + you to examine the commit. This is the default behavior. +-- ++ +Note that `--empty=drop` and `--empty=stop` only specify how to handle a +commit that was not initially empty, but rather became empty due to a previous +commit. Commits that were initially empty will still cause the cherry-pick to +fail unless one of `--empty=keep` or `--allow-empty` are specified. ++ + --keep-redundant-commits:: - If a commit being cherry picked duplicates a commit already in the - current history, it will become empty. By default these - redundant commits cause `cherry-pick` to stop so the user can - examine the commit. This option overrides that behavior and - creates an empty commit object. Implies `--allow-empty`. + Deprecated synonym for `--empty=keep`. --strategy=<strategy>:: Use the given merge strategy. Should only be used once. diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt index 5e1a3d5148..fd17165416 100644 --- a/Documentation/git-clean.txt +++ b/Documentation/git-clean.txt @@ -37,7 +37,7 @@ OPTIONS --force:: If the Git configuration variable clean.requireForce is not set to false, 'git clean' will refuse to delete files or directories - unless given -f or -i. Git will refuse to modify untracked + unless given -f. Git will refuse to modify untracked nested git repositories (directories with a .git subdirectory) unless a second -f is given. @@ -45,10 +45,14 @@ OPTIONS --interactive:: Show what would be done and clean files interactively. See ``Interactive mode'' for details. + Configuration variable `clean.requireForce` is ignored, as + this mode gives its own safety protection by going interactive. -n:: --dry-run:: Don't actually remove anything, just show what would be done. + Configuration variable `clean.requireForce` is ignored, as + nothing will be deleted anyway. -q:: --quiet:: @@ -103,7 +107,7 @@ filter by pattern:: This shows the files and directories to be deleted and issues an "Input ignore patterns>>" prompt. You can input space-separated patterns to exclude files and directories from deletion. - E.g. "*.c *.h" will excludes files end with ".c" and ".h" from + E.g. "*.c *.h" will exclude files ending with ".c" and ".h" from deletion. When you are satisfied with the filtered result, press ENTER (empty) back to the main menu. diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index c37c4a37f7..7acb4cb176 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -8,15 +8,15 @@ git-clone - Clone a repository into a new directory SYNOPSIS -------- -[verse] -'git clone' [--template=<template-directory>] +[synopsis] +git clone [--template=<template-directory>] [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] [--dissociate] [--separate-git-dir <git-dir>] [--depth <depth>] [--[no-]single-branch] [--no-tags] [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow] - [--filter=<filter> [--also-filter-submodules]] [--] <repository> + [--filter=<filter-spec>] [--also-filter-submodules]] [--] <repository> [<directory>] DESCRIPTION @@ -31,7 +31,7 @@ currently active branch. After the clone, a plain `git fetch` without arguments will update all the remote-tracking branches, and a `git pull` without arguments will in addition merge the remote master branch into the -current master branch, if any (this is untrue when "--single-branch" +current master branch, if any (this is untrue when `--single-branch` is given; see below). This default configuration is achieved by creating references to @@ -42,17 +42,17 @@ configuration variables. OPTIONS ------- --l:: ---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 - HEAD and everything under objects and refs directories. + `HEAD` and everything under objects and refs directories. The files under `.git/objects/` directory are hardlinked to save space when possible. + If the repository is specified as a local path (e.g., `/path/to/repo`), -this is the default, and --local is essentially a no-op. If the +this is the default, and `--local` is essentially a no-op. If the repository is specified as a URL, then this flag is ignored (and we never use the local optimizations). Specifying `--no-local` will override the default when `/path/to/repo` is given, using the regular @@ -64,17 +64,17 @@ prevent the unintentional copying of files by dereferencing the symbolic links. + *NOTE*: this operation can race with concurrent modification to the -source repository, similar to running `cp -r src dst` while modifying -`src`. +source repository, similar to running `cp -r <src> <dst>` while modifying +_<src>_. ---no-hardlinks:: +`--no-hardlinks`:: Force the cloning process from a repository on a local filesystem to copy the files under the `.git/objects` directory instead of using hardlinks. This may be desirable if you are trying to make a back-up of your repository. --s:: ---shared:: +`-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 @@ -101,10 +101,10 @@ If you want to break the dependency of a repository cloned with `--shared` on its source repository, you can simply run `git repack -a` to copy all objects from the source repository into a pack in the cloned repository. ---reference[-if-able] <repository>:: - If the reference repository is on the local machine, +`--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 + 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. @@ -115,7 +115,7 @@ objects from the source repository into a pack in the cloned repository. *NOTE*: see the NOTE for the `--shared` option, and also the `--dissociate` option. ---dissociate:: +`--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 @@ -126,43 +126,46 @@ objects from the source repository into a pack in the cloned repository. same repository, and this option can be used to stop the borrowing. --q:: ---quiet:: +`-q`:: +`--quiet`:: Operate quietly. Progress is not reported to the standard error stream. --v:: ---verbose:: +`-v`:: +`--verbose`:: Run verbosely. Does not affect the reporting of progress status to the standard error stream. ---progress:: +`--progress`:: Progress status is reported on the standard error stream by default when it is attached to a terminal, unless `--quiet` is specified. This flag forces progress status even if the standard error stream is not directed to a terminal. ---server-option=<option>:: +`--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. + When no ++--server-option=++__<option>__ is given from the command + line, the values of configuration variable `remote.<name>.serverOption` + are used instead. --n:: ---no-checkout:: - No checkout of HEAD is performed after the clone is complete. +`-n`:: +`--no-checkout`:: + No checkout of `HEAD` is performed after the clone is complete. ---[no-]reject-shallow:: +`--`[`no-`]`reject-shallow`:: Fail if the source repository is a shallow repository. - The 'clone.rejectShallow' configuration variable can be used to + The `clone.rejectShallow` configuration variable can be used to specify the default. ---bare:: +`--bare`:: Make a 'bare' Git repository. That is, instead of - creating `<directory>` and placing the administrative - files in `<directory>/.git`, make the `<directory>` + creating _<directory>_ and placing the administrative + files in `<directory>/.git`, make the _<directory>_ itself the `$GIT_DIR`. This obviously implies the `--no-checkout` because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly @@ -171,28 +174,28 @@ 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:: +`--sparse`:: Employ a sparse-checkout, with only files in the toplevel directory initially being present. The linkgit:git-sparse-checkout[1] command can be used to grow the working directory as needed. ---filter=<filter-spec>:: +`--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 + 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 + at least _<size>_. For more details on filter specifications, see the `--filter` option in linkgit:git-rev-list[1]. ---also-filter-submodules:: +`--also-filter-submodules`:: Also apply the partial clone filter to any submodules in the repository. Requires `--filter` and `--recurse-submodules`. This can be turned on by default by setting the `clone.filterSubmodules` config option. ---mirror:: +`--mirror`:: Set up a mirror of the source repository. This implies `--bare`. Compared to `--bare`, `--mirror` not only maps local branches of the source to local branches of the target, it maps all refs (including @@ -200,37 +203,37 @@ 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. --o <name>:: ---origin <name>:: +`-o` _<name>_:: +`--origin` _<name>_:: Instead of using the remote name `origin` to keep track of the upstream - repository, use `<name>`. Overrides `clone.defaultRemoteName` from the + repository, use _<name>_. Overrides `clone.defaultRemoteName` from the config. --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 +`-b` _<name>_:: +`--branch` _<name>_:: + Instead of pointing the newly created `HEAD` to the branch pointed + to by the cloned repository's `HEAD`, point to _<name>_ branch instead. In a non-bare repository, this is the branch that will be checked out. - `--branch` can also take tags and detaches the HEAD at that commit + `--branch` can also take tags and detaches the `HEAD` at that commit in the resulting repository. --u <upload-pack>:: ---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. ---template=<template-directory>:: +`--template=<template-directory>`:: Specify the directory from which templates will be used; (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) --c <key>=<value>:: ---config <key>=<value>:: +`-c` `<key>=<value>`:: +`--config` `<key>=<value>`:: Set a configuration variable in the newly-created repository; this takes effect immediately after the repository is initialized, but before the remote history is fetched or any - files checked out. The key is in the same format as expected by + files checked out. The _<key>_ is in the same format as expected by linkgit:git-config[1] (e.g., `core.eol=true`). If multiple values are given for the same key, each value will be written to the config file. This makes it safe, for example, to add @@ -242,32 +245,32 @@ 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>:: +`--depth <depth>`:: Create a 'shallow' clone with a history truncated to the specified number of commits. Implies `--single-branch` unless `--no-single-branch` is given to fetch the histories near the tips of all branches. If you want to clone submodules shallowly, also pass `--shallow-submodules`. ---shallow-since=<date>:: +`--shallow-since=<date>`:: Create a shallow clone with a history after the specified time. ---shallow-exclude=<revision>:: +`--shallow-exclude=<ref>`:: 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:: +`--[no-]single-branch`:: Clone only the history leading to the tip of a single branch, either specified by the `--branch` option or the primary branch remote's `HEAD` points at. Further fetches into the resulting repository will only update the remote-tracking branch for the branch this option was used for the - initial cloning. If the HEAD at the remote did not point at any + initial cloning. If the `HEAD` at the remote did not point at any branch when `--single-branch` clone was made, no remote-tracking branch is created. ---no-tags:: +`--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 @@ -279,13 +282,13 @@ 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>]:: +`--recurse-submodules[=<pathspec>]`:: After the clone is created, initialize and clone submodules - within based on the provided pathspec. If no pathspec is + 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 + the provided pathspec, or "`.`" (meaning all submodules) if no pathspec is provided. + Submodules are initialized and cloned using their default settings. This is @@ -295,42 +298,48 @@ 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:: +`--[no-]shallow-submodules`:: All submodules which are cloned will be shallow with a depth of 1. ---[no-]remote-submodules:: +`--[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>:: +`--separate-git-dir=<git-dir>`:: Instead of placing the cloned repository where it is supposed to be, place the cloned repository at the specified directory, then make a filesystem-agnostic Git symbolic link to there. The result is Git repository can be separated from working tree. --j <n>:: ---jobs <n>:: +`--ref-format=<ref-format>`:: + +Specify the given ref storage format for the repository. The valid values are: ++ +include::ref-storage-format.txt[] + +`-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 +_<repository>_:: + The (possibly remote) _<repository>_ to clone from. See the <<URLS,GIT URLS>> section below for more information on specifying repositories. -<directory>:: +_<directory>_:: The name of a new directory to clone into. The "humanish" - part of the source repository is used if no directory is + part of the source repository is used if no _<directory>_ is explicitly given (`repo` for `/path/to/repo.git` and `foo` for `host.xz:foo/.git`). Cloning into an existing directory is only allowed if the directory is empty. ---bundle-uri=<uri>:: +`--bundle-uri=<uri>`:: Before fetching from the remote, fetch a bundle from the given - `<uri>` and unbundle the data into the local repository. The refs + _<uri>_ and unbundle the data into the local repository. The refs in the bundle will be stored under the hidden `refs/bundle/*` namespace. This option is incompatible with `--depth`, `--shallow-since`, and `--shallow-exclude`. diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-commit-graph.txt index c8dbceba01..903b16830e 100644 --- a/Documentation/git-commit-graph.txt +++ b/Documentation/git-commit-graph.txt @@ -13,7 +13,7 @@ SYNOPSIS 'git commit-graph write' [--object-dir <dir>] [--append] [--split[=<strategy>]] [--reachable | --stdin-packs | --stdin-commits] [--changed-paths] [--[no-]max-new-filters <n>] [--[no-]progress] - <split options> + <split-options> DESCRIPTION diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 225c6c9f2e..c822113c11 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -9,7 +9,7 @@ SYNOPSIS -------- [verse] 'git commit' [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend] - [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>)] + [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>] [-F <file> | -m <msg>] [--reset-author] [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=<author>] [--date=<date>] [--cleanup=<mode>] [--[no-]status] @@ -347,6 +347,8 @@ The possible options are: - 'normal' - Shows untracked files and directories - 'all' - Also shows individual files in untracked directories. +All usual spellings for Boolean value `true` are taken as `normal` +and `false` as `no`. The default can be changed using the status.showUntrackedFiles configuration variable documented in linkgit:git-config[1]. -- @@ -541,7 +543,7 @@ DISCUSSION ---------- Though not required, it's a good idea to begin the commit message -with a single short (less than 50 character) line summarizing the +with a single short (no more than 50 characters) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index b1caac887a..3e420177c1 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -9,21 +9,14 @@ git-config - Get and set repository or global options SYNOPSIS -------- [verse] -'git config' [<file-option>] [--type=<type>] [--fixed-value] [--show-origin] [--show-scope] [-z|--null] <name> [<value> [<value-pattern>]] -'git config' [<file-option>] [--type=<type>] --add <name> <value> -'git config' [<file-option>] [--type=<type>] [--fixed-value] --replace-all <name> <value> [<value-pattern>] -'git config' [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get <name> [<value-pattern>] -'git config' [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get-all <name> [<value-pattern>] -'git config' [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] [--name-only] --get-regexp <name-regex> [<value-pattern>] -'git config' [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch <name> <URL> -'git config' [<file-option>] [--fixed-value] --unset <name> [<value-pattern>] -'git config' [<file-option>] [--fixed-value] --unset-all <name> [<value-pattern>] -'git config' [<file-option>] --rename-section <old-name> <new-name> -'git config' [<file-option>] --remove-section <name> -'git config' [<file-option>] [--show-origin] [--show-scope] [-z|--null] [--name-only] -l | --list -'git config' [<file-option>] --get-color <name> [<default>] +'git config list' [<file-option>] [<display-option>] [--includes] +'git config get' [<file-option>] [<display-option>] [--includes] [--all] [--regexp] [--value=<value>] [--fixed-value] [--default=<default>] <name> +'git config set' [<file-option>] [--type=<type>] [--all] [--value=<value>] [--fixed-value] <name> <value> +'git config unset' [<file-option>] [--all] [--value=<value>] [--fixed-value] <name> +'git config rename-section' [<file-option>] <old-name> <new-name> +'git config remove-section' [<file-option>] <name> +'git config edit' [<file-option>] 'git config' [<file-option>] --get-colorbool <name> [<stdout-is-tty>] -'git config' [<file-option>] -e | --edit DESCRIPTION ----------- @@ -31,7 +24,7 @@ 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 `--append` option. If you want to update or unset an option which can occur on multiple lines, a `value-pattern` (which is an extended regular expression, unless the `--fixed-value` option is given) needs to be given. Only the @@ -74,6 +67,42 @@ On success, the command returns the exit code 0. A list of all available configuration variables can be obtained using the `git help --config` command. +COMMANDS +-------- + +list:: + List all variables set in config file, along with their values. + +get:: + Emits the value of the specified key. If key is present multiple times + in the configuration, emits the last value. If `--all` is specified, + emits all values associated with key. Returns error code 1 if key is + not present. + +set:: + Set value for one or more config options. By default, this command + refuses to write multi-valued config options. Passing `--all` will + replace all multi-valued config options with the new value, whereas + `--value=` will replace all config options whose values match the given + pattern. + +unset:: + Unset value for one or more config options. By default, this command + refuses to unset multi-valued keys. Passing `--all` will unset all + multi-valued config options, whereas `--value` will unset all config + options whose values match the given pattern. + +rename-section:: + Rename the given section to a new name. + +remove-section:: + Remove the given section from the configuration file. + +edit:: + Opens an editor to modify the specified config file; either + `--system`, `--global`, `--local` (default), `--worktree`, or + `--file <config-file>`. + [[OPTIONS]] OPTIONS ------- @@ -82,32 +111,37 @@ OPTIONS Default behavior is to replace at most one line. This replaces all lines matching the key (and optionally the `value-pattern`). ---add:: +--append:: Adds a new line to the option without altering any existing - values. This is the same as providing '^$' as the `value-pattern` - in `--replace-all`. - ---get:: - Get the value for a given key (optionally filtered by a regex - matching the value). Returns error code 1 if the key was not - found and the last value if multiple key values were found. - ---get-all:: - Like get, but returns all values for a multi-valued key. - ---get-regexp:: - Like --get-all, but interprets the name as a regular expression and - writes out the key names. Regular expression matching is currently - case-sensitive and done against a canonicalized version of the key - in which section and variable names are lowercased, but subsection - names are not. - ---get-urlmatch <name> <URL>:: - When given a two-part name section.key, the value for - section.<URL>.key whose <URL> part matches the best to the + values. This is the same as providing '--value=^$' in `set`. + +--comment <message>:: + Append a comment at the end of new or modified lines. + + If _<message>_ begins with one or more whitespaces followed + by "#", it is used as-is. If it begins with "#", a space is + prepended before it is used. Otherwise, a string " # " (a + space followed by a hash followed by a space) is prepended + to it. And the resulting string is placed immediately after + the value defined for the variable. The _<message>_ must + not contain linefeed characters (no multi-line comments are + permitted). + +--all:: + With `get`, return all values for a multi-valued key. + +--regexp:: + With `get`, interpret the name as a regular expression. Regular + expression matching is currently case-sensitive and done against a + canonicalized version of the key in which section and variable names + are lowercased, but subsection names are not. + +--url=<URL>:: + When given a two-part <name> as <section>.<key>, the value for + <section>.<URL>.<key> whose <URL> part matches the best to the given URL is returned (if no such key exists, the value for - section.key is used as a fallback). When given just the - section as name, do so for all the keys in the section and + <section>.<key> is used as a fallback). When given just the + <section> as name, do so for all the keys in the section and list them. Returns error code 1 if no value is found. --global:: @@ -166,22 +200,6 @@ See also <<FILES>>. section in linkgit:gitrevisions[7] for a more complete list of ways to spell blob names. ---remove-section:: - Remove the given section from the configuration file. - ---rename-section:: - Rename the given section to a new name. - ---unset:: - Remove the line matching the key from config file. - ---unset-all:: - Remove all lines matching the key from config file. - --l:: ---list:: - List all variables set in config file, along with their values. - --fixed-value:: When used with the `value-pattern` argument, treat `value-pattern` as an exact string instead of a regular expression. This will restrict @@ -236,8 +254,8 @@ Valid `<type>`'s include: contain line breaks. --name-only:: - Output only the names of config variables for `--list` or - `--get-regexp`. + Output only the names of config variables for `list` or + `get`. --show-origin:: Augment the output of all queried config options with the @@ -261,22 +279,6 @@ Valid `<type>`'s include: When the color setting for `name` is undefined, the command uses `color.ui` as fallback. ---get-color <name> [<default>]:: - - Find the color configured for `name` (e.g. `color.diff.new`) and - output it as the ANSI color escape sequence to the standard - output. The optional `default` parameter is used instead, if - there is no color configured for `name`. -+ -`--type=color [--default=<default>]` is preferred over `--get-color` -(but note that `--get-color` will omit the trailing newline printed by -`--type=color`). - --e:: ---edit:: - Opens an editor to modify the specified config file; either - `--system`, `--global`, or repository (default). - --[no-]includes:: Respect `include.*` directives in config files when looking up values. Defaults to `off` when a specific file is given (e.g., @@ -284,14 +286,64 @@ Valid `<type>`'s include: 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. + When using `get`, and the requested variable is not found, behave as if + <value> were the value assigned to that variable. + +DEPRECATED MODES +---------------- + +The following modes have been deprecated in favor of subcommands. It is +recommended to migrate to the new syntax. + +'git config <name>':: + Replaced by `git config get <name>`. + +'git config <name> <value> [<value-pattern>]':: + Replaced by `git config set [--value=<pattern>] <name> <value>`. + +-l:: +--list:: + Replaced by `git config list`. + +--get <name> [<value-pattern>]:: + Replaced by `git config get [--value=<pattern>] <name>`. + +--get-all <name> [<value-pattern>]:: + Replaced by `git config get [--value=<pattern>] --all <name>`. + +--get-regexp <name-regexp>:: + Replaced by `git config get --all --show-names --regexp <name-regexp>`. + +--get-urlmatch <name> <URL>:: + Replaced by `git config get --all --show-names --url=<URL> <name>`. + +--get-color <name> [<default>]:: + Replaced by `git config get --type=color [--default=<default>] <name>`. + +--add <name> <value>:: + Replaced by `git config set --append <name> <value>`. + +--unset <name> [<value-pattern>]:: + Replaced by `git config unset [--value=<pattern>] <name>`. + +--unset-all <name> [<value-pattern>]:: + Replaced by `git config unset [--value=<pattern>] --all <name>`. + +--rename-section <old-name> <new-name>:: + Replaced by `git config rename-section <old-name> <new-name>`. + +--remove-section <name>:: + Replaced by `git config remove-section <name>`. + +-e:: +--edit:: + Replaced by `git config edit`. 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. +using `list` or `get` which may return multiple results. The default is to use +a pager. [[FILES]] FILES @@ -333,8 +385,8 @@ precedence over values read earlier. When multiple values are taken then all values of a key from all files will be used. By default, options are only written 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 `set` +and `unset`. *'git config' will only ever change one file at a time*. You can limit which configuration sources are read from or written to by specifying the path of a file with the `--file` option, or by specifying a @@ -469,7 +521,7 @@ Given a .git/config like this: you can set the filemode to true with ------------ -% git config core.filemode true +% git config set core.filemode true ------------ The hypothetical proxy command entries actually have a postfix to discern @@ -477,7 +529,7 @@ what URL they apply to. Here is how to change the entry for kernel.org to "ssh". ------------ -% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$' +% git config set --value='for kernel.org$' core.gitproxy '"ssh" for kernel.org' ------------ This makes sure that only the key/value pair for kernel.org is replaced. @@ -485,7 +537,7 @@ This makes sure that only the key/value pair for kernel.org is replaced. To delete the entry for renames, do ------------ -% git config --unset diff.renames +% git config unset diff.renames ------------ If you want to delete an entry for a multivar (like core.gitproxy above), @@ -494,51 +546,45 @@ you have to provide a regex matching the value of exactly one line. To query the value for a given key, do ------------ -% git config --get core.filemode ------------- - -or - ------------- -% git config core.filemode +% git config get core.filemode ------------ or, to query a multivar: ------------ -% git config --get core.gitproxy "for kernel.org$" +% git config get --value="for kernel.org$" core.gitproxy ------------ If you want to know all the values for a multivar, do: ------------ -% git config --get-all core.gitproxy +% git config get --all --show-names core.gitproxy ------------ If you like to live dangerously, you can replace *all* core.gitproxy by a new one with ------------ -% git config --replace-all core.gitproxy ssh +% git config set --all core.gitproxy ssh ------------ However, if you really only want to replace the line for the default proxy, i.e. the one without a "for ..." postfix, do something like this: ------------ -% git config core.gitproxy ssh '! for ' +% git config set --value='! for ' core.gitproxy ssh ------------ To actually match only values with an exclamation mark, you have to ------------ -% git config section.key value '[!]' +% git config set --value='[!]' section.key value ------------ To add a new proxy, without altering any of the existing ones, use ------------ -% git config --add core.gitproxy '"proxy-command" for example.com' +% git config set --append core.gitproxy '"proxy-command" for example.com' ------------ An example to use customized color from the configuration in your @@ -546,8 +592,8 @@ script: ------------ #!/bin/sh -WS=$(git config --get-color color.diff.whitespace "blue reverse") -RESET=$(git config --get-color "" "reset") +WS=$(git config get --type=color --default="blue reverse" color.diff.whitespace) +RESET=$(git config get --type=color --default="reset" "") echo "${WS}your whitespace color or blue reverse${RESET}" ------------ @@ -555,11 +601,11 @@ For URLs in `https://weak.example.com`, `http.sslVerify` is set to false, while it is set to `true` for all others: ------------ -% git config --type=bool --get-urlmatch http.sslverify https://good.example.com +% git config get --type=bool --url=https://good.example.com http.sslverify true -% git config --type=bool --get-urlmatch http.sslverify https://weak.example.com +% git config get --type=bool --url=https://weak.example.com http.sslverify false -% git config --get-urlmatch http https://weak.example.com +% git config get --url=https://weak.example.com http http.cookieFile /tmp/cookie.txt http.sslverify false ------------ diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt index cb9b4d2e46..97f9f12610 100644 --- a/Documentation/git-count-objects.txt +++ b/Documentation/git-count-objects.txt @@ -12,7 +12,7 @@ SYNOPSIS DESCRIPTION ----------- -This counts the number of unpacked object files and disk space consumed by +Counts the number of unpacked object files and disk space consumed by them, to help you decide when it is a good time to repack. @@ -20,7 +20,7 @@ OPTIONS ------- -v:: --verbose:: - Report in more detail: + Provide more detailed reports: + count: the number of loose objects + @@ -33,7 +33,7 @@ size-pack: disk space consumed by the packs, in KiB (unless -H is specified) prune-packable: the number of loose objects that are also present in the packs. These objects could be pruned using `git prune-packed`. + -garbage: the number of files in object database that are neither valid loose +garbage: the number of files in the object database that are neither valid loose objects nor valid packs + size-garbage: disk space consumed by garbage files, in KiB (unless -H is diff --git a/Documentation/git-credential-cache.txt b/Documentation/git-credential-cache.txt index f473994a86..487cc557a8 100644 --- a/Documentation/git-credential-cache.txt +++ b/Documentation/git-credential-cache.txt @@ -16,7 +16,7 @@ DESCRIPTION This command caches credentials for use by future Git programs. The stored credentials are kept in memory of the cache-daemon -process (instead of written to a file) and are forgotten after a +process (instead of being written to a file) and are forgotten after a configurable timeout. Credentials are forgotten sooner if the cache-daemon dies, for example if the system restarts. The cache is accessible over a Unix domain socket, restricted to the current diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt index 76b0798856..71864a8726 100644 --- a/Documentation/git-credential-store.txt +++ b/Documentation/git-credential-store.txt @@ -33,7 +33,7 @@ OPTIONS 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 + from reading it, but it will not be encrypted or otherwise protected. If not specified, credentials will be searched for from `~/.git-credentials` and `$XDG_CONFIG_HOME/git/credentials`, and credentials will be written to `~/.git-credentials` if it exists, or diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt index a220afed4f..e41493292f 100644 --- a/Documentation/git-credential.txt +++ b/Documentation/git-credential.txt @@ -8,7 +8,7 @@ git-credential - Retrieve and store user credentials SYNOPSIS -------- ------------------ -'git credential' (fill|approve|reject) +'git credential' (fill|approve|reject|capability) ------------------ DESCRIPTION @@ -41,6 +41,9 @@ If the action is `reject`, git-credential will send the description to any configured credential helpers, which may erase any stored credentials matching the description. +If the action is `capability`, git-credential will announce any capabilities +it supports to standard output. + If the action is `approve` or `reject`, no output should be emitted. TYPICAL USE OF GIT CREDENTIAL @@ -94,7 +97,7 @@ unlocked) before it returned `password=secr3t`. that `git credential` will ask for a new password in its next invocation. In either case, `git credential` should be fed with the credential description obtained from step (2) (which also - contain the ones provided in step (1)). + contains the fields provided in step (1)). [[IOFMT]] INPUT/OUTPUT FORMAT @@ -111,7 +114,9 @@ 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. +contain any bytes except newline or NUL. A line, including the trailing +newline, may not exceed 65535 bytes in order to allow implementations to +parse efficiently. Attributes with keys that end with C-style array brackets `[]` can have multiple values. Each instance of a multi-valued attribute forms an @@ -178,6 +183,61 @@ empty string. Components which are missing from the URL (e.g., there is no username in the example above) will be left unset. +`authtype`:: + This indicates that the authentication scheme in question should be used. + Common values for HTTP and HTTPS include `basic`, `bearer`, and `digest`, + although the latter is insecure and should not be used. If `credential` + is used, this may be set to an arbitrary string suitable for the protocol in + question (usually HTTP). ++ +This value should not be sent unless the appropriate capability (see below) is +provided on input. + +`credential`:: + The pre-encoded credential, suitable for the protocol in question (usually + HTTP). If this key is sent, `authtype` is mandatory, and `username` and + `password` are not used. For HTTP, Git concatenates the `authtype` value and + this value with a single space to determine the `Authorization` header. ++ +This value should not be sent unless the appropriate capability (see below) is +provided on input. + +`ephemeral`:: + This boolean value indicates, if true, that the value in the `credential` + field should not be saved by the credential helper because its usefulness is + limited in time. For example, an HTTP Digest `credential` value is computed + using a nonce and reusing it will not result in successful authentication. + This may also be used for situations with short duration (e.g., 24-hour) + credentials. The default value is false. ++ +The credential helper will still be invoked with `store` or `erase` so that it +can determine whether the operation was successful. ++ +This value should not be sent unless the appropriate capability (see below) is +provided on input. + +`state[]`:: + This value provides an opaque state that will be passed back to this helper + if it is called again. Each different credential helper may specify this + once. The value should include a prefix unique to the credential helper and + should ignore values that don't match its prefix. ++ +This value should not be sent unless the appropriate capability (see below) is +provided on input. + +`continue`:: + This is a boolean value, which, if enabled, indicates that this + authentication is a non-final part of a multistage authentication step. This + is common in protocols such as NTLM and Kerberos, where two rounds of client + authentication are required, and setting this flag allows the credential + helper to implement the multistage authentication step. This flag should + only be sent if a further stage is required; that is, if another round of + authentication is expected. ++ +This value should not be sent unless the appropriate capability (see below) is +provided on input. This attribute is 'one-way' from a credential helper to +pass information to Git (or other programs invoking `git credential`). + `wwwauth[]`:: When an HTTP response is received by Git that includes one or more @@ -189,7 +249,45 @@ attribute 'wwwauth[]', where the order of the attributes is the same as they appear in the HTTP response. This attribute is 'one-way' from Git to pass additional information to credential helpers. -Unrecognised attributes are silently discarded. +`capability[]`:: + This signals that Git, or the helper, as appropriate, supports the capability + in question. This can be used to provide better, more specific data as part + of the protocol. A `capability[]` directive must precede any value depending + on it and these directives _should_ be the first item announced in the + protocol. ++ +There are two currently supported capabilities. The first is `authtype`, which +indicates that the `authtype`, `credential`, and `ephemeral` values are +understood. The second is `state`, which indicates that the `state[]` and +`continue` values are understood. ++ +It is not obligatory to use the additional features just because the capability +is supported, but they should not be provided without the capability. + +Unrecognised attributes and capabilities are silently discarded. + +[[CAPA-IOFMT]] +CAPABILITY INPUT/OUTPUT FORMAT +------------------------------ + +For `git credential capability`, the format is slightly different. First, a +`version 0` announcement is made to indicate the current version of the +protocol, and then each capability is announced with a line like `capability +authtype`. Credential helpers may also implement this format, again with the +`capability` argument. Additional lines may be added in the future; callers +should ignore lines which they don't understand. + +Because this is a new part of the credential helper protocol, older versions of +Git, as well as some credential helpers, may not support it. If a non-zero +exit status is received, or if the first line doesn't start with the word +`version` and a space, callers should assume that no capabilities are supported. + +The intention of this format is to differentiate it from the credential output +in an unambiguous way. It is possible to use very simple credential helpers +(e.g., inline shell scripts) which always produce identical output. Using a +distinct format allows users to continue to use this syntax without having to +worry about correctly implementing capability advertisements or accidentally +confusing callers querying for capabilities. GIT --- diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index b3f27671a0..90fdc2551a 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -22,7 +22,7 @@ DESCRIPTION deprecated; it does not work with cvsps version 3 and later. If you are performing a one-shot import of a CVS repository consider using http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or -http://www.catb.org/esr/cvs-fast-export/[cvs-fast-export]. +https://gitlab.com/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. @@ -221,7 +221,7 @@ Problems related to tags: If you suspect that any of these issues may apply to the repository you want to import, consider using cvs2git: -* cvs2git (part of cvs2svn), `http://subversion.apache.org/` +* cvs2git (part of cvs2svn), `https://subversion.apache.org/` GIT --- diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt index cf4a5a283e..4c475efeab 100644 --- a/Documentation/git-cvsserver.txt +++ b/Documentation/git-cvsserver.txt @@ -197,7 +197,7 @@ allowing access over SSH. 5. Clients should now be able to check out the project. Use the CVS 'module' name to indicate what Git 'head' you want to check out. This also sets the name of your newly checked-out directory, unless you tell it otherwise with - `-d <dir_name>`. For example, this checks out 'master' branch to the + `-d <dir-name>`. For example, this checks out 'master' branch to the `project-master` directory: + ------ @@ -224,7 +224,7 @@ the database to work reliably (otherwise you need to make sure that the database is up to date any time 'git-cvsserver' is executed). By default it uses SQLite databases in the Git directory, named -`gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates +`gitcvs.<module-name>.sqlite`. Note that the SQLite backend creates temporary files in the same directory as the database file on write so it might not be enough to grant the users using 'git-cvsserver' write access to the database file without granting diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt index 236df516c7..ede7b935d6 100644 --- a/Documentation/git-daemon.txt +++ b/Documentation/git-daemon.txt @@ -18,7 +18,7 @@ SYNOPSIS [--allow-override=<service>] [--forbid-override=<service>] [--access-hook=<path>] [--[no-]informative-errors] [--inetd | - [--listen=<host_or_ipaddr>] [--port=<n>] + [--listen=<host-or-ipaddr>] [--port=<n>] [--user=<user> [--group=<group>]]] [--log-destination=(stderr|syslog|none)] [<directory>...] @@ -86,10 +86,10 @@ OPTIONS Incompatible with --detach, --port, --listen, --user and --group options. ---listen=<host_or_ipaddr>:: +--listen=<host-or-ipaddr>:: Listen on a specific IP address or hostname. IP addresses can be either an IPv4 address or an IPv6 address if supported. If IPv6 - is not supported, then --listen=hostname is also not supported and + 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. @@ -138,11 +138,11 @@ otherwise `stderr`. --user-path:: --user-path=<path>:: Allow {tilde}user notation to be used in requests. When - specified with no parameter, requests to + specified with no parameter, a request to git://host/{tilde}alice/foo is taken as a request to access 'foo' repository in the home directory of user `alice`. - If `--user-path=path` is specified, the same request is - taken as a request to access `path/foo` repository in + If `--user-path=<path>` is specified, the same request is + taken as a request to access `<path>/foo` repository in the home directory of user `alice`. --verbose:: diff --git a/Documentation/git-diagnose.txt b/Documentation/git-diagnose.txt index 3ec8cc7ad7..0711959e6f 100644 --- a/Documentation/git-diagnose.txt +++ b/Documentation/git-diagnose.txt @@ -45,7 +45,7 @@ OPTIONS -s <format>:: --suffix <format>:: Specify an alternate suffix for the diagnostics archive name, to create - a file named 'git-diagnostics-<formatted suffix>'. This should take the + a file named 'git-diagnostics-<formatted-suffix>'. This should take the form of a strftime(3) format string; the current local time will be used. diff --git a/Documentation/git-diff-files.txt b/Documentation/git-diff-files.txt index 591e3801b7..bf78e31431 100644 --- a/Documentation/git-diff-files.txt +++ b/Documentation/git-diff-files.txt @@ -26,7 +26,7 @@ include::diff-options.txt[] -2 --ours:: -3 --theirs:: -0:: - Diff against the "base" version, "our branch" or "their + Diff against the "base" version, "our branch", or "their branch" respectively. With these options, diffs for merged entries are not shown. + @@ -37,12 +37,12 @@ omit diff output for unmerged entries and just show "Unmerged". -c:: --cc:: This compares stage 2 (our branch), stage 3 (their - branch) and the working tree file and outputs a combined + branch), and the working tree file and outputs a combined diff, similar to the way 'diff-tree' shows a merge commit with these flags. -q:: - Remain silent even on nonexistent files + Remain silent even for nonexistent files include::diff-format.txt[] diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt index c30d8f0da8..4de1d4c8f1 100644 --- a/Documentation/git-diff-index.txt +++ b/Documentation/git-diff-index.txt @@ -13,10 +13,10 @@ SYNOPSIS DESCRIPTION ----------- -Compares the content and mode of the blobs found in a tree object +Compare the content and mode of the blobs found in a tree object with the corresponding tracked files in the working tree, or with the corresponding paths in the index. When <path> arguments are present, -compares only paths matching those patterns. Otherwise all tracked +compare only paths matching those patterns. Otherwise all tracked files are compared. OPTIONS diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt index 274d5eaba9..09286a85eb 100644 --- a/Documentation/git-diff-tree.txt +++ b/Documentation/git-diff-tree.txt @@ -15,7 +15,7 @@ SYNOPSIS DESCRIPTION ----------- -Compares the content and mode of the blobs found via two tree objects. +Compare the content and mode of blobs found via two tree objects. If there is only one <tree-ish> given, the commit is compared with its parents (see --stdin below). @@ -34,10 +34,10 @@ include::diff-options.txt[] matching one of the provided pathspecs. -r:: - recurse into sub-trees + Recurse into sub-trees. -t:: - show tree entry itself as well as subtrees. Implies -r. + Show tree entry itself as well as subtrees. Implies -r. --root:: When `--root` is specified the initial commit will be shown as a big @@ -78,7 +78,7 @@ commits (but not trees). 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. + only useful with the `-v` flag. -v:: This flag causes 'git diff-tree --stdin' to also show @@ -88,7 +88,7 @@ include::pretty-options.txt[] --no-commit-id:: 'git diff-tree' outputs a line with the commit ID when - applicable. This flag suppressed the commit ID output. + applicable. This flag suppresses the commit ID output. -c:: This flag changes the way a merge commit is displayed @@ -104,10 +104,10 @@ include::pretty-options.txt[] This flag changes the way a merge commit patch is displayed, in a similar way to the `-c` option. It implies the `-c` and `-p` options and further compresses the patch output - by omitting uninteresting hunks whose the contents in the parents + by omitting uninteresting hunks whose 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 + itself and the commit log message are not shown, just like in any other "empty diff" case. --combined-all-paths:: diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index 08087ffad5..c065f023ec 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -103,7 +103,7 @@ Just in case you are doing something exotic, it should be noted that all of the <commit> in the above description, except in the `--merge-base` case and in the last two forms that use `..` notations, can be any <tree>. A tree of interest is the one pointed to -by the special ref `AUTO_MERGE`, which is written by the 'ort' merge +by the ref named `AUTO_MERGE`, which is written by the 'ort' merge strategy upon hitting merge conflicts (see linkgit:git-merge[1]). Comparing the working tree with `AUTO_MERGE` shows changes you've made so far to resolve textual conflicts (see the examples below). diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt index ac0ac6fa02..a616f8b2e6 100644 --- a/Documentation/git-difftool.txt +++ b/Documentation/git-difftool.txt @@ -36,7 +36,7 @@ OPTIONS --rotate-to=<file>:: Start showing the diff for the given path, - the paths before it will move to end and output. + the paths before it will move to the end and output. --skip-to=<file>:: Start showing the diff for the given path, skipping all @@ -78,7 +78,7 @@ with custom merge tool commands and has the same value as `$MERGED`. Print a list of diff tools that may be used with `--tool`. --[no-]symlinks:: - 'git difftool''s default behavior is create symlinks to the + 'git difftool''s default behavior is to create symlinks to the working tree when run in `--dir-diff` mode and the right-hand side of the comparison yields the same content as the file in the working tree. @@ -90,7 +90,7 @@ instead. `--no-symlinks` is the default on Windows. --extcmd=<command>:: Specify a custom command for viewing diffs. 'git-difftool' ignores the configured defaults and runs - `$command $LOCAL $REMOTE` when this option is specified. + `<command> $LOCAL $REMOTE` when this option is specified. Additionally, `$BASE` is set in the environment. -g:: @@ -105,7 +105,6 @@ instead. `--no-symlinks` is the default on Windows. `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. diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt index 4643ddbe68..752e4b9b01 100644 --- a/Documentation/git-fast-export.txt +++ b/Documentation/git-fast-export.txt @@ -48,7 +48,7 @@ When asking to 'abort' (which is the default), this program will die when encountering such a tag. With 'drop' it will omit such tags from the output. With 'rewrite', if the tagged object is a commit, it will rewrite the tag to tag an ancestor commit (via parent rewriting; see -linkgit:git-rev-list[1]) +linkgit:git-rev-list[1]). -M:: -C:: diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 8b5dd6add0..3d435157a6 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -303,7 +303,7 @@ and some sanity checks on the numeric values may also be performed. with e.g. bogus timezone values. `rfc2822`:: - This is the standard email format as described by RFC 2822. + This is the standard date format as described by RFC 2822. + An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git parser is accurate, but a little on the lenient side. It is the @@ -622,7 +622,7 @@ in octal. Git only supports the following modes: * `100755` or `755`: A normal, but executable, file. * `120000`: A symlink, the content of the file will be the link target. * `160000`: A gitlink, SHA-1 of the object refers to a commit in - another repository. Git links can only be specified by SHA or through + another repository. Git links can only be specified either by SHA or through a commit mark. They are used to implement submodules. * `040000`: A subdirectory. Subdirectories can only be specified by SHA or through a tree mark set with `--import-marks`. @@ -630,18 +630,28 @@ in octal. Git only supports the following modes: In both formats `<path>` is the complete path of the file to be added (if not already existing) or modified (if already existing). -A `<path>` string must use UNIX-style directory separators (forward -slash `/`), may contain any byte other than `LF`, and must not -start with double quote (`"`). - -A path can use C-style string quoting; this is accepted in all cases -and mandatory if the filename starts with double quote or contains -`LF`. In C-style quoting, the complete name should be surrounded with -double quotes, and any `LF`, backslash, or double quote characters -must be escaped by preceding them with a backslash (e.g., -`"path/with\n, \\ and \" in it"`). - -The value of `<path>` must be in canonical form. That is it must not: +A `<path>` can be written as unquoted bytes or a C-style quoted string. + +When a `<path>` does not start with a double quote (`"`), it is an +unquoted string and is parsed as literal bytes without any escape +sequences. However, if the filename contains `LF` or starts with double +quote, it cannot be represented as an unquoted string and must be +quoted. Additionally, the source `<path>` in `filecopy` or `filerename` +must be quoted if it contains SP. + +When a `<path>` starts with a double quote (`"`), it is a C-style quoted +string, where the complete filename is enclosed in a pair of double +quotes and escape sequences are used. Certain characters must be escaped +by preceding them with a backslash: `LF` is written as `\n`, backslash +as `\\`, and double quote as `\"`. Some characters may optionally be +written with escape sequences: `\a` for bell, `\b` for backspace, `\f` +for form feed, `\n` for line feed, `\r` for carriage return, `\t` for +horizontal tab, and `\v` for vertical tab. Any byte can be written with +3-digit octal codes (e.g., `\033`). All filenames can be represented as +quoted strings. + +A `<path>` must use UNIX-style directory separators (forward slash `/`) +and its value must be in canonical form. That is it must not: * contain an empty directory component (e.g. `foo//bar` is invalid), * end with a directory separator (e.g. `foo/` is invalid), @@ -651,6 +661,7 @@ The value of `<path>` must be in canonical form. That is it must not: The root of the tree can be represented by an empty string as `<path>`. +`<path>` cannot contain NUL, either literally or escaped as `\000`. It is recommended that `<path>` always be encoded using UTF-8. `filedelete` @@ -745,11 +756,11 @@ paths for a commit are encouraged to do so. `notemodify` ^^^^^^^^^^^^ -Included in a `commit` `<notes_ref>` command to add a new note +Included in a `commit` `<notes-ref>` command to add a new note annotating a `<commit-ish>` or change this annotation contents. Internally it is similar to filemodify 100644 on `<commit-ish>` path (maybe split into subdirectories). It's not advised to -use any other commands to write to the `<notes_ref>` tree except +use any other commands to write to the `<notes-ref>` tree except `filedeleteall` to delete all existing notes in this tree. This command has two different means of specifying the content of the note. @@ -1353,7 +1364,7 @@ the marks back to the source repository, it is easy to verify the accuracy and completeness of the import by comparing each Git commit to the corresponding source revision. -Coming from a system such as Perforce or Subversion this should be +Coming from a system such as Perforce or Subversion, this should be quite simple, as the fast-import mark can also be the Perforce changeset number or the Subversion revision number. diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index 46747d5f42..b5223576a7 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -69,7 +69,7 @@ be in a separate packet, and the list must end with a flush packet. --upload-pack=<git-upload-pack>:: Use this to specify the path to 'git-upload-pack' on the - remote side, if is not found on your $PATH. + remote side, if it is not found on your $PATH. Installations of sshd ignores the user's environment setup scripts for login shells (e.g. .bash_profile) and your privately installed git may not be found on the system @@ -91,7 +91,7 @@ be in a separate packet, and the list must end with a flush packet. Deepen or shorten the history of a shallow repository to include all reachable commits after <date>. ---shallow-exclude=<revision>:: +--shallow-exclude=<ref>:: 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. diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index f123139c58..50900a50da 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -186,8 +186,8 @@ 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/*' +$ git fetch <url-of-origin> --prune --prune-tags +$ git fetch <url-of-origin> --prune 'refs/tags/*:refs/tags/*' ------------------------------------------------ OUTPUT diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 62e482a95e..5a4f853785 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -14,7 +14,7 @@ SYNOPSIS [--msg-filter <command>] [--commit-filter <command>] [--tag-name-filter <command>] [--prune-empty] [--original <namespace>] [-d <directory>] [-f | --force] - [--state-branch <branch>] [--] [<rev-list options>...] + [--state-branch <branch>] [--] [<rev-list-options>...] WARNING ------- @@ -32,7 +32,7 @@ listed there as reasonably possible. DESCRIPTION ----------- Lets you rewrite Git revision history by rewriting the branches mentioned -in the <rev-list options>, applying custom filters on each revision. +in the <rev-list-options>, applying custom filters on each revision. Those filters can modify each tree (e.g. removing a file or running a perl rewrite on all files) or information about each commit. Otherwise, all information (including original commit times or merge @@ -624,7 +624,7 @@ with: 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 + <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). diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 11b2bc3121..d3764401a2 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -10,7 +10,7 @@ SYNOPSIS [verse] 'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl] [(--sort=<key>)...] [--format=<format>] - [ --stdin | <pattern>... ] + [--include-root-refs] [ --stdin | <pattern>... ] [--points-at=<object>] [--merged[=<object>]] [--no-merged[=<object>]] [--contains[=<object>]] [--no-contains[=<object>]] @@ -51,17 +51,14 @@ OPTIONS key. --format=<format>:: - A string that interpolates `%(fieldname)` from a ref being shown - and the object it points at. If `fieldname` - is prefixed with an asterisk (`*`) and the ref points - at a tag object, use the value for the field in the object - which the tag object refers to (instead of the field in the tag object). - When unspecified, `<format>` defaults to - `%(objectname) SPC %(objecttype) TAB %(refname)`. - It also interpolates `%%` to `%`, and `%xx` where `xx` - are hex digits interpolates to character with hex code - `xx`; for example `%00` interpolates to `\0` (NUL), - `%09` to `\t` (TAB) and `%0a` to `\n` (LF). + A string that interpolates `%(fieldname)` from a ref being shown and + the object it points at. In addition, the string literal `%%` + renders as `%` and `%xx` - where `xx` are hex digits - renders as + the character with hex code `xx`. For example, `%00` interpolates to + `\0` (NUL), `%09` to `\t` (TAB), and `%0a` to `\n` (LF). ++ +When unspecified, `<format>` defaults to `%(objectname) SPC %(objecttype) +TAB %(refname)`. --color[=<when>]:: Respect any colors specified in the `--format` option. The @@ -108,6 +105,9 @@ OPTIONS any excluded pattern(s) are shown. Matching is done using the same rules as `<pattern>` above. +--include-root-refs:: + List root refs (HEAD and pseudorefs) apart from regular refs. + FIELD NAMES ----------- @@ -264,6 +264,48 @@ ahead-behind:<committish>:: commits ahead and behind, respectively, when comparing the output ref to the `<committish>` specified in the format. +is-base:<committish>:: + In at most one row, `(<committish>)` will appear to indicate the ref + that is most likely the ref used as a starting point for the branch + that produced `<committish>`. This choice is made using a heuristic: + choose the ref that minimizes the number of commits in the + first-parent history of `<committish>` and not in the first-parent + history of the ref. ++ +For example, consider the following figure of first-parent histories of +several refs: ++ +---- +*--*--*--*--*--* refs/heads/A +\ + \ + *--*--*--* refs/heads/B + \ \ + \ \ + * * refs/heads/C + \ + \ + *--* refs/heads/D +---- ++ +Here, if `A`, `B`, and `C` are the filtered references, and the format +string is `%(refname):%(is-base:D)`, then the output would be ++ +---- +refs/heads/A: +refs/heads/B:(D) +refs/heads/C: +---- ++ +This is because the first-parent history of `D` has its earliest +intersection with the first-parent histories of the filtered refs at a +common first-parent ancestor of `B` and `C` and ties are broken by the +earliest ref in the sorted order. ++ +Note that this token will not appear if the first-parent history of +`<committish>` does not intersect the first-parent histories of the +filtered refs. + describe[:options]:: A human-readable name, like linkgit:git-describe[1]; empty string for undescribable commits. The `describe` string may @@ -298,12 +340,20 @@ 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. +For tag objects, a `fieldname` prefixed with an asterisk (`*`) expands to +the `fieldname` value of the peeled object, rather than that of the tag +object itself. + 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. For email fields (`authoremail`, `committeremail` and `taggeremail`), `:trim` can be appended to get the email without angle brackets, and `:localpart` to get the part before the `@` symbol -out of the trimmed email. +out of the trimmed email. In addition to these, the `:mailmap` option and the +corresponding `:mailmap,trim` and `:mailmap,localpart` can be used (order does +not matter) to get values of the name and email according to the .mailmap file +or according to the file set in the mailmap.file or mailmap.blob configuration +variable (see linkgit:gitmailmap[5]). The raw data in an object is `raw`. @@ -354,9 +404,11 @@ In any case, a field name that refers to a field inapplicable to the object referred by the ref does not cause an error. It returns an empty string instead. -As a special case for the date-type fields, you may specify a format for -the date by adding `:` followed by date format name (see the -values the `--date` option to linkgit:git-rev-list[1] takes). +As a special case for the date-type fields, you may specify a format for the +date by adding `:` followed by date format name (see the values the `--date` +option to linkgit:git-rev-list[1] takes). If this formatting is provided in +a `--sort` key, references will be sorted according to the byte-value of the +formatted string rather than the numeric value of the underlying timestamp. Some atoms like %(align) and %(if) always require a matching %(end). We call them "opening atoms" and sometimes denote them as %($open). diff --git a/Documentation/git-for-each-repo.txt b/Documentation/git-for-each-repo.txt index 94bd19da26..abe3527aac 100644 --- a/Documentation/git-for-each-repo.txt +++ b/Documentation/git-for-each-repo.txt @@ -42,6 +42,15 @@ These config values are loaded from system, global, and local Git config, as available. If `git for-each-repo` is run in a directory that is not a Git repository, then only the system and global config is used. +--keep-going:: + Continue with the remaining repositories if the command failed + on a repository. The exit code will still indicate that the + overall operation was not successful. ++ +Note that the exact exit code of the failing command is not passed +through as the exit code of the `for-each-repo` command: If the command +failed in any of the specified repositories, the overall exit code will +be 1. SUBPROCESS BEHAVIOR ------------------- diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 373b46fc0d..5dc7bb4cfc 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -17,10 +17,10 @@ SYNOPSIS [--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] [--always] [--cover-from-description=<mode>] - [--rfc] [--subject-prefix=<subject prefix>] + [--rfc[=<rfc>]] [--subject-prefix=<subject-prefix>] [(--reroll-count|-v) <n>] [--to=<email>] [--cc=<email>] [--[no-]cover-letter] [--quiet] @@ -30,8 +30,8 @@ SYNOPSIS [--range-diff=<previous> [--creation-factor=<percent>]] [--filename-max-length=<n>] [--progress] - [<common diff options>] - [ <since> | <revision range> ] + [<common-diff-options>] + [ <since> | <revision-range> ] DESCRIPTION ----------- @@ -55,7 +55,7 @@ A "message" generated by the command consists of three parts: * The "patch", which is the "diff -p --stat" output (see linkgit:git-diff[1]) between the commit and its parent. -The log message and the patch is separated by a line with a +The log message and the patch are separated by a line with a three-dash line. There are two ways to specify which commits to operate on. @@ -64,7 +64,7 @@ There are two ways to specify which commits to operate on. to the tip of the current branch that are not in the history that leads to the <since> to be output. -2. Generic <revision range> expression (see "SPECIFYING +2. Generic <revision-range> expression (see "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7]) means the commits in the specified range. @@ -179,9 +179,9 @@ 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:: @@ -215,11 +215,21 @@ is greater than 100 bytes, then the mode will be `message`, otherwise If `<mode>` is `none`, both the cover letter subject and body will be populated with placeholder text. ---subject-prefix=<subject prefix>:: +--description-file=<file>:: + Use the contents of <file> instead of the branch's description + for generating the cover letter. + +--subject-prefix=<subject-prefix>:: Instead of the standard '[PATCH]' prefix in the subject - line, instead use '[<subject prefix>]'. This - allows for useful naming of a patch series, and can be - combined with the `--numbered` option. + line, instead use '[<subject-prefix>]'. This can be used + to name a patch series, and can be combined with the + `--numbered` option. ++ +The configuration variable `format.subjectPrefix` may also be used +to configure a subject prefix to apply to a given repository for +all patches. This is often useful on mailing lists which receive +patches for several repositories and can be used to disambiguate +the patches (with a value of e.g. "PATCH my-project"). --filename-max-length=<n>:: Instead of the standard 64 bytes, chomp the generated output @@ -228,10 +238,21 @@ populated with placeholder text. value of the `format.filenameMaxLength` configuration variable, or 64 if unconfigured. ---rfc:: - Alias for `--subject-prefix="RFC PATCH"`. RFC means "Request For - Comments"; use this when sending an experimental patch for - discussion rather than application. +--rfc[=<rfc>]:: + Prepends the string _<rfc>_ (defaults to "RFC") to + the subject prefix. As the subject prefix defaults to + "PATCH", you'll get "RFC PATCH" by default. ++ +RFC means "Request For Comments"; use this when sending +an experimental patch for discussion rather than application. +"--rfc=WIP" may also be a useful way to indicate that a patch +is not complete yet ("WIP" stands for "Work In Progress"). ++ +If the convention of the receiving community for a particular extra +string is to have it _after_ the subject prefix, the string _<rfc>_ +can be prefixed with a dash ("`-`") to signal that the rest of +the _<rfc>_ string should be appended to the subject prefix instead, +e.g., `--rfc='-(WIP)'` results in "PATCH (WIP)". -v <n>:: --reroll-count=<n>:: @@ -336,6 +357,11 @@ material (this may change in the future). between the previous and current series of patches by adjusting the creation/deletion cost fudge factor. See linkgit:git-range-diff[1]) for details. ++ +Defaults to 999 (the linkgit:git-range-diff[1] uses 60), as the use +case is to show comparison with an older iteration of the same +topic and the tool should find more correspondence between the two +sets of patches. --notes[=<ref>]:: --no-notes:: @@ -393,7 +419,7 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`. `format.useAutoBase` configuration. --root:: - Treat the revision argument as a <revision range>, even if it + Treat the revision argument as a <revision-range>, even if it is just a single commit (that would normally be treated as a <since>). Note that root commits included in the specified range are always formatted as creation patches, independently @@ -600,8 +626,8 @@ Approach #3 (external editor) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The following Thunderbird extensions are needed: -AboutConfig from http://aboutconfig.mozdev.org/ and -External Editor from http://globs.org/articles.php?lng=en&pg=8 +AboutConfig from https://mjg.github.io/AboutConfig/ and +External Editor from https://globs.org/articles.php?lng=en&pg=8 1. Prepare the patch as a text file using your method of choice. diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt index b6a0f8a085..5b82e4605c 100644 --- a/Documentation/git-fsck.txt +++ b/Documentation/git-fsck.txt @@ -24,7 +24,7 @@ OPTIONS An object to treat as the head of an unreachability trace. + If no objects are given, 'git fsck' defaults to using the -index file, all SHA-1 references in `refs` namespace, and all reflogs +index file, all SHA-1 references in the `refs` namespace, and all reflogs (unless --no-reflogs is given) as heads. --unreachable:: @@ -64,7 +64,7 @@ index file, all SHA-1 references in `refs` namespace, and all reflogs --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 + are 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 @@ -79,7 +79,7 @@ care about this output and want to speed it up further. recorded with g+w bit set, which was created by older versions of Git. Existing repositories, including the Linux kernel, Git itself, and sparse repository have old - objects that triggers this check, but it is recommended + objects that trigger this check, but it is recommended to check new projects with this flag. --verbose:: diff --git a/Documentation/git-fsmonitor--daemon.txt b/Documentation/git-fsmonitor--daemon.txt index 8238eadb0e..8585d19f4d 100644 --- a/Documentation/git-fsmonitor--daemon.txt +++ b/Documentation/git-fsmonitor--daemon.txt @@ -70,10 +70,10 @@ the change (as happening against the super repo). However, the client will properly ignore these extra events, so performance may be affected but it will not cause an incorrect result. -By default, the fsmonitor daemon refuses to work against network-mounted +By default, the fsmonitor daemon refuses to work with network-mounted repositories; this may be overridden by setting `fsmonitor.allowRemote` to `true`. Note, however, that the fsmonitor daemon is not guaranteed to work -correctly with all network-mounted repositories and such use is considered +correctly with all network-mounted repositories, so such use is considered experimental. On Mac OS, the inter-process communication (IPC) between various Git @@ -83,10 +83,10 @@ but not on network-mounted filesystems, NTFS, or FAT32. Other filesystems may or may not have the needed support; the fsmonitor daemon is not guaranteed to work with these filesystems and such use is considered experimental. -By default, the socket is created in the `.git` directory, however, if the -`.git` directory is on a network-mounted filesystem, it will be instead be +By default, the socket is created in the `.git` directory. However, if the +`.git` directory is on a network-mounted filesystem, it will instead be created at `$HOME/.git-fsmonitor-*` unless `$HOME` itself is on a -network-mounted filesystem in which case you must set the configuration +network-mounted filesystem, in which case you must set the configuration variable `fsmonitor.socketDir` to the path of a directory on a Mac OS native filesystem in which to create the socket file. diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index 90806fd26a..370e22faae 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -9,7 +9,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository SYNOPSIS -------- [verse] -'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack] +'git gc' [--aggressive] [--auto] [--[no-]detach] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack] DESCRIPTION ----------- @@ -53,12 +53,22 @@ configuration options such as `gc.auto` and `gc.autoPackLimit`, all other housekeeping tasks (e.g. rerere, working trees, reflog...) will be performed as well. +--[no-]detach:: + Run in the background if the system supports it. This option overrides + the `gc.autoDetach` config. --[no-]cruft:: When expiring unreachable objects, pack them separately into a cruft pack instead of storing them as loose objects. `--cruft` is on by default. +--max-cruft-size=<n>:: + When packing unreachable objects into a cruft pack, limit the + size of new cruft packs to be at most `<n>` bytes. Overrides any + value specified via the `gc.maxCruftSize` configuration. See + the `--max-cruft-size` option of linkgit:git-repack[1] for + more. + --prune=<date>:: Prune loose objects older than date (default is 2 weeks ago, overridable by the config variable `gc.pruneExpire`). diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt index ac44d85b0b..b537bb45b1 100644 --- a/Documentation/git-get-tar-commit-id.txt +++ b/Documentation/git-get-tar-commit-id.txt @@ -20,7 +20,7 @@ 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 +If no commit ID is found, 'git get-tar-commit-id' quietly exits with a return code of 1. This can happen if the archive had not been created using 'git archive' or if the first parameter of 'git archive' had been a tree ID instead of a commit ID or tag. diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index dabdbe8471..1e6d7b65c8 100644 --- a/Documentation/git-grep.txt +++ b/Documentation/git-grep.txt @@ -28,7 +28,7 @@ SYNOPSIS [-f <file>] [-e] <pattern> [--and|--or|--not|(|)|-e <pattern>...] [--recurse-submodules] [--parent-basename <basename>] - [ [--[no-]exclude-standard] [--cached | --no-index | --untracked] | <tree>...] + [ [--[no-]exclude-standard] [--cached | --untracked | --no-index] | <tree>...] [--] [<pathspec>...] DESCRIPTION @@ -45,13 +45,21 @@ OPTIONS Instead of searching tracked files in the working tree, search blobs registered in the index file. ---no-index:: - Search files in the current directory that is not managed by Git. - --untracked:: In addition to searching in the tracked files in the working tree, search also in untracked files. +--no-index:: + Search files in the current directory that is not managed by Git, + or by ignoring that the current directory is managed by Git. This + is rather similar to running the regular `grep(1)` utility with its + `-r` option specified, but with some additional benefits, such as + using pathspec patterns to limit paths; see the 'pathspec' entry + in linkgit:gitglossary[7] for more information. ++ +This option cannot be used together with `--cached` or `--untracked`. +See also `grep.fallbackToNoIndex` in 'CONFIGURATION' below. + --no-exclude-standard:: Also search in ignored files by not honoring the `.gitignore` mechanism. Only useful with `--untracked`. @@ -64,9 +72,9 @@ OPTIONS --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. + _<tree>_ option the prefix of all submodule output will be the name of + the parent project's _<tree>_ object. This option cannot be used together + with `--untracked`, and it has no effect if `--no-index` is specified. -a:: --text:: @@ -178,7 +186,7 @@ providing this option will cause it to die. 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 linkgit:git-config[1]). + variable `core.quotePath` (see linkgit:git-config[1]). -o:: --only-matching:: @@ -248,8 +256,8 @@ providing this option will cause it to die. a non-zero status. --threads <num>:: - Number of grep worker threads to use. - See `grep.threads` in 'CONFIGURATION' for more information. + Number of `grep` worker threads to use. See 'NOTES ON THREADS' + and `grep.threads` in 'CONFIGURATION' for more information. -f <file>:: Read patterns from <file>, one per line. @@ -332,13 +340,13 @@ EXAMPLES NOTES ON THREADS ---------------- -The `--threads` option (and the grep.threads configuration) will be ignored when +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`. +with multiple threads might perform slower than single-threaded if `--textconv` +is given and there are too many text conversions. Thus, if low performance is +experienced in this case, it might be desirable to use `--threads=1`. CONFIGURATION ------------- diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt index e8f3ccb433..f5b02ef114 100644 --- a/Documentation/git-gui.txt +++ b/Documentation/git-gui.txt @@ -114,7 +114,7 @@ of end users. The official repository of the 'git gui' project can be found at: - https://github.com/prati0100/git-gui.git/ + https://github.com/j6t/git-gui GIT --- diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt index 8577f7a7d4..ef4719ae41 100644 --- a/Documentation/git-hash-object.txt +++ b/Documentation/git-hash-object.txt @@ -39,10 +39,10 @@ OPTIONS of from the command-line. --path:: - Hash object as it were located at the given path. The location of - file does not directly influence on the hash value, but path is - used to determine what Git filters should be applied to the object - before it can be placed to the object database, and, as result of + Hash object as if it were located at the given path. The location of + the file does not directly influence the hash value, but the path is + used to determine which Git filters should be applied to the object + before it can be placed in the object database. As a result of applying filters, the actual blob put into the object database may differ from the given file. This option is mainly useful for hashing temporary files located outside of the working directory or files diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt index 2b0b5e390d..f0bedc1f96 100644 --- a/Documentation/git-help.txt +++ b/Documentation/git-help.txt @@ -42,13 +42,13 @@ former is internally converted into the latter. To display the linkgit:git[1] man page, use `git help git`. -This page can be displayed with 'git help help' or `git help --help` +This page can be displayed with 'git help help' or `git help --help`. OPTIONS ------- -a:: --all:: - Prints all the available commands on the standard output. + Print all the available commands on the standard output. --no-external-commands:: When used with `--all`, exclude the listing of external "git-*" @@ -59,7 +59,7 @@ OPTIONS aliases. --verbose:: - When used with `--all` print description for all recognized + When used with `--all`, print description for all recognized commands. This is the default. -c:: @@ -69,10 +69,10 @@ OPTIONS -g:: --guides:: - Prints a list of the Git concept guides on the standard output. + Print a list of the Git concept guides on the standard output. --user-interfaces:: - Prints a list of the repository, command and file interfaces + Print a list of the repository, command and file interfaces documentation on the standard output. + In-repository file interfaces such as `.git/info/exclude` are @@ -85,7 +85,7 @@ pseudo-configuration such as the file-based `.git/hooks/*` interface described in linkgit:githooks[5]. --developer-interfaces:: - Print list of file formats, protocols and other developer + Print a list of file formats, protocols and other developer interfaces documentation on the standard output. -i:: @@ -109,7 +109,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 neither 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. @@ -129,8 +129,8 @@ line option: * "info" corresponds to '-i|--info', * "web" or "html" correspond to '-w|--web'. -help.browser, web.browser and browser.<tool>.path -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +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 diff --git a/Documentation/git-hook.txt b/Documentation/git-hook.txt index 3407f3c2c0..f6cc72d2ca 100644 --- a/Documentation/git-hook.txt +++ b/Documentation/git-hook.txt @@ -13,7 +13,7 @@ SYNOPSIS DESCRIPTION ----------- -A command interface to running git hooks (see linkgit:githooks[5]), +A command interface for running git hooks (see linkgit:githooks[5]), for use by other scripted git commands. SUBCOMMANDS @@ -32,7 +32,7 @@ OPTIONS ------- --to-stdin:: - For "run"; Specify a file which will be streamed into the + For "run"; specify a file which will be streamed into the hook's stdin. The hook will receive the entire file from beginning to EOF. diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt index 0c5c0dde19..f37ddaded8 100644 --- a/Documentation/git-http-backend.txt +++ b/Documentation/git-http-backend.txt @@ -23,7 +23,7 @@ discussion of `GIT_PROTOCOL` in the ENVIRONMENT section below. 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` environment 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 @@ -42,12 +42,12 @@ http.getanyfile:: any file within the repository, including objects that are no longer reachable from a branch but are still present. It is enabled by default, but a repository can disable it - by setting this configuration item to `false`. + by setting this configuration value to `false`. http.uploadpack:: This serves 'git fetch-pack' and 'git ls-remote' clients. It is enabled by default, but a repository can disable it - by setting this configuration item to `false`. + by setting this configuration value to `false`. http.receivepack:: This serves 'git send-pack' clients, allowing push. It is @@ -265,12 +265,12 @@ 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` environment 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 +`http.maxRequestBuffer` config option) 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 diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt index 319062c021..4ec7c68d3b 100644 --- a/Documentation/git-http-fetch.txt +++ b/Documentation/git-http-fetch.txt @@ -31,7 +31,7 @@ commit-id:: Report what is downloaded. -w <filename>:: - Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on + Writes the commit-id into the specified filename under $GIT_DIR/refs/<filename> on the local end after the transfer is complete. --stdin:: diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt index 7c6a6dd7f6..ce0d808212 100644 --- a/Documentation/git-http-push.txt +++ b/Documentation/git-http-push.txt @@ -13,12 +13,12 @@ SYNOPSIS DESCRIPTION ----------- -Sends missing objects to remote repository, and updates the +Sends missing objects to the remote repository, and updates the remote branch. *NOTE*: This command is temporarily disabled if your libcurl is older than 7.16, as the combination has been reported -not to work and sometimes corrupts repository. +not to work and sometimes corrupts the repository. OPTIONS ------- @@ -44,7 +44,7 @@ OPTIONS -d:: -D:: Remove <ref> from remote repository. The specified branch - cannot be the remote HEAD. If -d is specified the following + cannot be the remote HEAD. If -d is specified, the following other conditions must also be met: - Remote HEAD must resolve to an object that exists locally @@ -83,8 +83,8 @@ and where it is pushed is determined by using the destination side. 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. +is performed to avoid accidentally overwriting the +remote ref and losing other peoples' commits from there. With `--force`, the fast-forward check is disabled for all refs. diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index f7b1851514..c8a89d7243 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -135,7 +135,7 @@ flames ridiculing you if you don't check this. Thunderbird in particular is known to be problematic. Thunderbird users may wish to visit this web page for more information: - http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email + https://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email SEE ALSO -------- diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt index 4e71c256ec..58dd5b5f0e 100644 --- a/Documentation/git-index-pack.txt +++ b/Documentation/git-index-pack.txt @@ -16,10 +16,10 @@ SYNOPSIS DESCRIPTION ----------- -Reads a packed archive (.pack) from the specified file, and -builds a pack index file (.idx) for it. Optionally writes a +Reads a packed archive (.pack) from the specified file, +builds a pack index file (.idx) for it, and optionally writes a reverse-index (.rev) for the specified pack. The packed -archive together with the pack index can then be placed in +archive, together with the pack index, can then be placed in the objects/pack/ directory of a Git repository. @@ -68,8 +68,8 @@ OPTIONS updated to use objects contained in the pack. --keep=<msg>:: - Like --keep create a .keep file before moving the index into - its final destination, but rather than creating an empty file + Like --keep, create a .keep file before moving the index into + its final destination. However, instead of creating an empty file place '<msg>' followed by an LF into the .keep file. The '<msg>' message can later be searched for within all .keep files to locate any which have outlived their usefulness. @@ -79,8 +79,13 @@ OPTIONS to force the version for the generated pack index, and to force 64-bit index entries on objects located above the given offset. ---strict:: - Die, if the pack contains broken objects or links. +--strict[=<msg-id>=<severity>...]:: + Die, if the pack contains broken objects or links. An optional + comma-separated list of `<msg-id>=<severity>` can be passed to change + the severity of some possible issues, e.g., + `--strict="missingEmail=ignore,badTagName=error"`. See the entry for the + `fsck.<msg-id>` configuration options in linkgit:git-fsck[1] for more + information on the possible values of `<msg-id>` and `<severity>`. --progress-title:: For internal use only. @@ -91,13 +96,18 @@ default and "Indexing objects" when `--stdin` is specified. --check-self-contained-and-connected:: Die if the pack contains broken links. For internal use only. ---fsck-objects:: - For internal use only. +--fsck-objects[=<msg-id>=<severity>...]:: + Die if the pack contains broken objects, but unlike `--strict`, don't + choke on broken links. If the pack contains a tree pointing to a + .gitmodules blob that does not exist, prints the hash of that blob + (for the caller to check) after the hash that goes into the name of the + pack/idx file (see "Notes"). + -Die if the pack contains broken objects. If the pack contains a tree -pointing to a .gitmodules blob that does not exist, prints the hash of -that blob (for the caller to check) after the hash that goes into the -name of the pack/idx file (see "Notes"). +An optional comma-separated list of `<msg-id>=<severity>` can be passed to +change the severity of some possible issues, e.g., +`--fsck-objects="missingEmail=ignore,badTagName=ignore"`. See the entry for the +`fsck.<msg-id>` configuration options in linkgit:git-fsck[1] for more +information on the possible values of `<msg-id>` and `<severity>`. --threads=<n>:: Specifies the number of threads to spawn when resolving @@ -129,6 +139,13 @@ include::object-format-disclaimer.txt[] written. If a `<message>` is provided, then that content will be written to the .promisor file for future reference. See link:technical/partial-clone.html[partial clone] for more information. ++ +Also, if there are objects in the given pack that references non-promisor +objects (in the repo), repacks those non-promisor objects into a promisor +pack. This avoids a situation in which a repo has non-promisor objects that are +accessible through promisor objects. ++ +Requires <pack-file> to not be specified. NOTES ----- diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 160dea1372..315f7f7530 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -8,11 +8,12 @@ git-init - Create an empty Git repository or reinitialize an existing one SYNOPSIS -------- -[verse] -'git init' [-q | --quiet] [--bare] [--template=<template-directory>] - [--separate-git-dir <git-dir>] [--object-format=<format>] - [-b <branch-name> | --initial-branch=<branch-name>] - [--shared[=<permissions>]] [<directory>] +[synopsis] +git init [-q | --quiet] [--bare] [--template=<template-directory>] + [--separate-git-dir <git-dir>] [--object-format=<format>] + [--ref-format=<format>] + [-b <branch-name> | --initial-branch=<branch-name>] + [--shared[=<permissions>]] [<directory>] DESCRIPTION @@ -24,99 +25,104 @@ directory with subdirectories for `objects`, `refs/heads`, commits will be created (see the `--initial-branch` option below for its name). -If the `$GIT_DIR` environment variable is set then it specifies a path +If the `GIT_DIR` environment variable is set then it specifies a path to use instead of `./.git` for the base of the repository. If the object storage directory is specified via the -`$GIT_OBJECT_DIRECTORY` environment variable then the sha1 directories -are created underneath - otherwise the default `$GIT_DIR/objects` +`GIT_OBJECT_DIRECTORY` environment variable then the sha1 directories +are created underneath; otherwise, the default `$GIT_DIR/objects` directory is used. -Running 'git init' in an existing repository is safe. It will not +Running `git init` in an existing repository is safe. It will not overwrite things that are already there. The primary reason for -rerunning 'git init' is to pick up newly added templates (or to move -the repository to another place if --separate-git-dir is given). +rerunning `git init` is to pick up newly added templates (or to move +the repository to another place if `--separate-git-dir` is given). OPTIONS ------- --q:: ---quiet:: +`-q`:: +`--quiet`:: Only print error and warning messages; all other output will be suppressed. ---bare:: +`--bare`:: 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. +`--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. + include::object-format-disclaimer.txt[] ---template=<template-directory>:: +`--ref-format=<format>`:: +Specify the given ref storage _<format>_ for the repository. The valid values are: ++ +include::ref-storage-format.txt[] +`--template=<template-directory>`:: Specify the directory from which templates will be used. (See the "TEMPLATE DIRECTORY" section below.) ---separate-git-dir=<git-dir>:: - +`--separate-git-dir=<git-dir>`:: Instead of initializing the repository as a directory to either `$GIT_DIR` or `./.git/`, create a text file there containing the path to the actual -repository. This file acts as filesystem-agnostic Git symbolic link to the +repository. This file acts as a filesystem-agnostic Git symbolic link to the repository. + -If this is reinitialization, the repository will be moved to the specified path. +If this is a 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 +`-b <branch-name>`:: +`--initial-branch=<branch-name>`:: +Use _<branch-name>_ for the initial branch in the newly created repository. If not specified, fall back to the default name (currently `master`, but this is subject to change in the future; the name can be customized via the `init.defaultBranch` configuration variable). ---shared[=(false|true|umask|group|all|world|everybody|<perm>)]:: +`--shared[=(false|true|umask|group|all|world|everybody|<perm>)]`:: Specify that the Git repository is to be shared amongst several users. This allows users belonging to the same group to push into that -repository. When specified, the config variable "core.sharedRepository" is +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). +by `umask`(2). + -The option can have the following values, defaulting to 'group' if no value +The option can have the following values, defaulting to `group` if no value is given: + -- -'umask' (or 'false'):: +`umask`:: +`false`:: -Use permissions reported by umask(2). The default, when `--shared` is not +Use permissions reported by `umask`(2). The default, when `--shared` is not specified. -'group' (or 'true'):: +`group`:: +`true`:: -Make the repository group-writable, (and g+sx, since the git group may be not +Make the repository group-writable, (and `g+sx`, since the git group may not be 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 +otherwise safe `umask`(2) value. Note that the umask still applies to the other +permission bits (e.g. if umask is `0022`, using `group` will not remove read +privileges from other (non-group) users). See `0xxx` for how to exactly specify the repository permissions. -'all' (or 'world' or 'everybody'):: +`all`:: +`world`:: +`everybody`:: -Same as 'group', but make the repository readable by all users. +Same as `group`, but make the repository readable by all users. -'<perm>':: +_<perm>_:: -'<perm>' is a 3-digit octal number prefixed with `0` and each file -will have mode '<perm>'. '<perm>' 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 +_<perm>_ is a 3-digit octal number prefixed with `0` and each file +will have mode _<perm>_. _<perm>_ will override users' `umask`(2) +value (and not only loosen permissions as `group` and `all` +do). `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 (directories and executable files get their `x` bit from the `r` bit for corresponding classes of users). @@ -126,7 +132,7 @@ 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 +If you provide a _<directory>_, the command is run inside it. If this directory does not exist, it will be created. TEMPLATE DIRECTORY @@ -165,7 +171,7 @@ $ git add . <2> $ git commit <3> ---------------- + -<1> Create a /path/to/my/codebase/.git directory. +<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. @@ -174,6 +180,8 @@ CONFIGURATION include::includes/cmd-config-section-all.txt[] +:git-init: + include::config/init.txt[] GIT diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt index 55d8961466..d9dfb75fef 100644 --- a/Documentation/git-interpret-trailers.txt +++ b/Documentation/git-interpret-trailers.txt @@ -9,7 +9,7 @@ SYNOPSIS -------- [verse] 'git interpret-trailers' [--in-place] [--trim-empty] - [(--trailer <token>[(=|:)<value>])...] + [(--trailer (<key>|<key-alias>)[(=|:)<value>])...] [--parse] [<file>...] DESCRIPTION @@ -31,10 +31,15 @@ the last two lines starting with "Signed-off-by" are trailers. This command reads 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 each input file. The result is emitted on the -standard output. +If `--parse` is specified, the output consists of the parsed trailers +coming from the input, without influencing them with any command line +options or configuration variables. + +Otherwise, this command applies `trailer.*` configuration variables +(which could potentially add new trailers, as well as reposition them), +as well as any command line arguments that can override configuration +variables (such as `--trailer=...` which could also add new trailers), +to each input file. The result is emitted on the standard output. This command can also operate on the output of linkgit:git-format-patch[1], which is more elaborate than a plain commit message. Namely, such output @@ -48,22 +53,32 @@ are applied to each input and the way any existing trailer in the input is changed. They also make it possible to automatically add some trailers. -By default, a '<token>=<value>' or '<token>:<value>' argument given +By default, a '<key>=<value>' or '<key>:<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 +the last trailer has a different (<key>, <value>) pair (or if there +is no existing trailer). The <key> and <value> parts will be trimmed to remove starting and trailing whitespace, and the resulting trimmed -<token> and <value> will appear in the output like this: +<key> and <value> will appear in the output like this: ------------------------------------------------ -token: value +key: value ------------------------------------------------ -This means that the trimmed <token> and <value> will be separated by -`': '` (one colon followed by one space). For convenience, the <token> can be a -shortened string key (e.g., "sign") instead of the full string which should -appear before the separator on the output (e.g., "Signed-off-by"). This can be -configured using the 'trailer.<token>.key' configuration variable. +This means that the trimmed <key> and <value> will be separated by +`': '` (one colon followed by one space). + +For convenience, a <key-alias> can be configured to make using `--trailer` +shorter to type on the command line. This can be configured using the +'trailer.<key-alias>.key' configuration variable. The <keyAlias> must be a prefix +of the full <key> string, although case sensitivity does not matter. For +example, if you have + +------------------------------------------------ +trailer.sign.key "Signed-off-by: " +------------------------------------------------ + +in your configuration, you only need to specify `--trailer="sign: foo"` +on the command line instead of `--trailer="Signed-off-by: foo"`. 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 @@ -80,14 +95,14 @@ non-whitespace lines before a line that starts with '---' (followed by a space or the end of the line). When reading trailers, there can be no whitespace before or inside the -<token>, but any number of regular space and tab characters are allowed -between the <token> and the separator. There can be whitespaces before, +<key>, but any number of regular space and tab characters are allowed +between the <key> and the separator. There can be whitespaces before, inside or after the <value>. The <value> may be split over multiple lines with each subsequent line starting with at least one whitespace, like the "folding" in RFC 822. Example: ------------------------------------------------ -token: This is a very long value, with spaces and +key: This is a very long value, with spaces and newlines in it. ------------------------------------------------ @@ -104,35 +119,44 @@ OPTIONS the whole trailer will be removed from the output. 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 <key>[(=|:)<value>]:: + Specify a (<key>, <value>) pair that should be applied as a trailer to the inputs. 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 + provided with '--where' overrides the `trailer.where` and any + applicable `trailer.<keyAlias>.where` 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`. + '--where' or '--no-where'. Upon encountering '--no-where', clear the + effect of any previous use of '--where', such that the relevant configuration + variables are no longer overridden. Possible placements 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 input. A setting - provided with '--if-exists' overrides all configuration variables + least one trailer with the same <key> in the input. A setting + provided with '--if-exists' overrides the `trailer.ifExists` and any + applicable `trailer.<keyAlias>.ifExists` configuration variables and applies to all '--trailer' options until the next occurrence of - '--if-exists' or '--no-if-exists'. Possible actions are `addIfDifferent`, + '--if-exists' or '--no-if-exists'. Upon encountering '--no-if-exists, clear the + effect of any previous use of '--if-exists, such that the relevant configuration + variables are no longer overridden. 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 input. A setting - provided with '--if-missing' overrides all configuration variables + trailer with the same <key> in the input. A setting + provided with '--if-missing' overrides the `trailer.ifMissing` and any + applicable `trailer.<keyAlias>.ifMissing` configuration variables and applies to all '--trailer' options until the next occurrence of - '--if-missing' or '--no-if-missing'. Possible actions are `doNothing` + '--if-missing' or '--no-if-missing'. Upon encountering '--no-if-missing, + clear the effect of any previous use of '--if-missing, such that the relevant + configuration variables are no longer overridden. Possible actions are `doNothing` or `add`. --only-trailers:: @@ -140,16 +164,19 @@ OPTIONS --only-input:: Output only trailers that exist in the input; do not add any - from the command-line or by following configured `trailer.*` - rules. + from the command-line or by applying `trailer.*` configuration + variables. --unfold:: - Remove any whitespace-continuation in trailers, so that each - trailer appears on a line by itself with its full content. + If a trailer has a value that runs over multiple lines (aka "folded"), + reformat the value into a single line. --parse:: A convenience alias for `--only-trailers --only-input - --unfold`. + --unfold`. This makes it easier to only see the trailers coming from the + input without influencing them with any command line options or + configuration variables, while also making the output machine-friendly with + --unfold. --no-divider:: Do not treat `---` as the end of the commit message. Use this @@ -170,11 +197,11 @@ 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 '%', '=' +using the format '<key><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). +'<key>% <value>' (one percent sign and one space will appear between +the key and the value). trailer.where:: This option tells where a new trailer will be added. @@ -188,41 +215,41 @@ 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>. +last trailer with the same <key>. + If it is `before`, then each new trailer will appear just before the -first trailer with the same <token>. +first trailer with the same <key>. 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 input. + same <key> in the input. + 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 +trailer with the same (<key>, <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 input. +with the same (<key>, <value>) pair is already in the input. + With `add`, a new trailer will be added, even if some trailers with -the same (<token>, <value>) pair are already in the input. +the same (<key>, <value>) pair are already in the input. + -With `replace`, an existing trailer with the same <token> will be +With `replace`, an existing trailer with the same <key> 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 +the closest one (with the same <key>) 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 input. +added if there is already one with the same <key> in the input. 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 input. + <key> in the input. + The valid values for this option are: `add` (this is the default) and `doNothing`. @@ -231,34 +258,40 @@ 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. +trailer.<keyAlias>.key:: + Defines a <keyAlias> for the <key>. The <keyAlias> must be a + prefix (case does not matter) of the <key>. For example, in `git + config trailer.ack.key "Acked-by"` the "Acked-by" is the <key> and + the "ack" is the <keyAlias>. This configuration allows the shorter + `--trailer "ack:..."` invocation on the command line using the "ack" + <keyAlias> instead of the longer `--trailer "Acked-by:..."`. ++ +At the end of the <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. +If there is a separator in the key, then it overrides the default +separator when adding the trailer. -trailer.<token>.where:: +trailer.<keyAlias>.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>. + that option for trailers with the specified <keyAlias>. -trailer.<token>.ifexists:: +trailer.<keyAlias>.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>. + that option for trailers with the specified <keyAlias>. -trailer.<token>.ifmissing:: +trailer.<keyAlias>.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>. + that option for trailers with the specified <keyAlias>. -trailer.<token>.command:: - Deprecated in favor of 'trailer.<token>.cmd'. - This option behaves in the same way as 'trailer.<token>.cmd', except +trailer.<keyAlias>.command:: + Deprecated in favor of 'trailer.<keyAlias>.cmd'. + This option behaves in the same way as 'trailer.<keyAlias>.cmd', except that it doesn't pass anything as argument to the specified command. Instead the first occurrence of substring $ARG is replaced by the <value> that would be passed as argument. @@ -266,29 +299,29 @@ trailer.<token>.command:: Note that $ARG in the user's command is only replaced once and that the original way of replacing $ARG is not safe. + -When both 'trailer.<token>.cmd' and 'trailer.<token>.command' are given -for the same <token>, 'trailer.<token>.cmd' is used and -'trailer.<token>.command' is ignored. +When both 'trailer.<keyAlias>.cmd' and 'trailer.<keyAlias>.command' are given +for the same <keyAlias>, 'trailer.<keyAlias>.cmd' is used and +'trailer.<keyAlias>.command' is ignored. -trailer.<token>.cmd:: +trailer.<keyAlias>.cmd:: This option can be used to specify a shell command that will be called - once to automatically add a trailer with the specified <token>, and then - called each time a '--trailer <token>=<value>' argument is specified to + once to automatically add a trailer with the specified <keyAlias>, and then + called each time a '--trailer <keyAlias>=<value>' argument is specified to modify the <value> of the trailer that this option would produce. + When the specified command is first called to add a trailer -with the specified <token>, the behavior is as if a special -'--trailer <token>=<value>' argument was added at the beginning +with the specified <keyAlias>, the behavior is as if a special +'--trailer <keyAlias>=<value>' argument was added at the beginning of the "git interpret-trailers" command, where <value> is taken to be the standard output of the command with any leading and trailing whitespace trimmed off. + -If some '--trailer <token>=<value>' arguments are also passed +If some '--trailer <keyAlias>=<value>' arguments are also passed on the command line, the command is called again once for each -of these arguments with the same <token>. And the <value> part +of these arguments with the same <keyAlias>. And the <value> part of these arguments, if any, will be passed to the command as its first argument. This way the command can produce a <value> computed -from the <value> passed in the '--trailer <token>=<value>' argument. +from the <value> passed in the '--trailer <keyAlias>=<value>' argument. EXAMPLES -------- diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 2a66cf8880..579682172f 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -120,11 +120,11 @@ By default, `git log` does not generate any diff output. The options below can be used to show the changes made by each commit. Note that unless one of `--diff-merges` variants (including short -`-m`, `-c`, and `--cc` options) is explicitly given, merge commits +`-m`, `-c`, `--cc`, and `--dd` options) is explicitly given, merge commits will not show a diff, even if a diff format like `--patch` is selected, nor will they match search options like `-S`. The exception is when `--first-parent` is in use, in which case `first-parent` is -the default format. +the default format for merge commits. :git-log: 1 :diff-merges-default: `off` diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt index 1bc0328bb7..58c529afbe 100644 --- a/Documentation/git-ls-files.txt +++ b/Documentation/git-ls-files.txt @@ -25,12 +25,12 @@ SYNOPSIS DESCRIPTION ----------- -This merges the file listing in the index with the actual working +This command merges the file listing in the index with the actual working directory list, and shows different combinations of the two. -One or more of the options below may be used to determine the files +Several flags can be used to determine which files are shown, and each file may be printed multiple times if there are -multiple entries in the index or multiple statuses are applicable for +multiple entries in the index or if multiple statuses are applicable for the relevant file selection options. OPTIONS @@ -62,7 +62,7 @@ OPTIONS matching an exclude pattern. When showing "other" files (i.e. when used with '-o'), show only those matched by an exclude pattern. Standard ignore rules are not automatically - activated, therefore at least one of the `--exclude*` options + activated; therefore, at least one of the `--exclude*` options is required. -s:: @@ -119,8 +119,10 @@ OPTIONS --exclude-per-directory=<file>:: Read additional exclude patterns that apply only to the - directory and its subdirectories in <file>. Deprecated; use - --exclude-standard instead. + directory and its subdirectories in <file>. If you are + trying to emulate the way Porcelain commands work, using + the `--exclude-standard` option instead is easier and more + thorough. --exclude-standard:: Add the standard Git exclusions: .git/info/exclude, .gitignore @@ -141,7 +143,7 @@ OPTIONS Show status tags together with filenames. Note that for scripting purposes, linkgit:git-status[1] `--porcelain` and linkgit:git-diff-files[1] `--name-status` are almost always - superior alternatives, and users should look at + superior alternatives; users should look at linkgit:git-status[1] `--short` or linkgit:git-diff[1] `--name-status` for more user-friendly alternatives. + @@ -217,9 +219,9 @@ followed by the ("attr/<eolattr>"). --format=<format>:: A string that interpolates `%(fieldname)` from the result being shown. - 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). + It also interpolates `%%` to `%`, and `%xXX` where `XX` are hex digits + interpolates to character with hex code `XX`; for example `%x00` + interpolates to `\0` (NUL), `%x09` to `\t` (TAB) and %x0a to `\n` (LF). --format cannot be combined with `-s`, `-o`, `-k`, `-t`, `--resolve-undo` and `--eol`. \--:: @@ -298,9 +300,8 @@ traversing the directory tree and finding files to show when the flags --others or --ignored are specified. linkgit:gitignore[5] specifies the format of exclude patterns. -Generally, you should just use --exclude-standard, but for historical -reasons the exclude patterns can be specified from the following -places, in order: +These exclude patterns can be specified from the following places, +in order: 1. The command-line flag --exclude=<pattern> specifies a single pattern. Patterns are ordered in the same order @@ -322,6 +323,18 @@ top of the directory tree. A pattern read from a file specified by --exclude-per-directory is relative to the directory that the pattern file appears in. +Generally, you should be able to use `--exclude-standard` when you +want the exclude rules applied the same way as what Porcelain +commands do. To emulate what `--exclude-standard` specifies, you +can give `--exclude-per-directory=.gitignore`, and then specify: + + 1. The file specified by the `core.excludesfile` configuration + variable, if exists, or the `$XDG_CONFIG_HOME/git/ignore` file. + + 2. The `$GIT_DIR/info/exclude` file. + +via the `--exclude-from=` option. + SEE ALSO -------- linkgit:git-read-tree[1], linkgit:gitignore[5] diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 1c4f696ab5..d71c4ab3e2 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -9,7 +9,7 @@ git-ls-remote - List references in a remote repository SYNOPSIS -------- [verse] -'git ls-remote' [--heads] [--tags] [--refs] [--upload-pack=<exec>] +'git ls-remote' [--branches] [--tags] [--refs] [--upload-pack=<exec>] [-q | --quiet] [--exit-code] [--get-url] [--sort=<key>] [--symref] [<repository> [<patterns>...]] @@ -21,14 +21,16 @@ commit IDs. OPTIONS ------- --h:: ---heads:: +-b:: +--branches:: -t:: --tags:: - Limit to only refs/heads and refs/tags, respectively. + Limit to only local branches and local tags, respectively. These options are _not_ mutually exclusive; when given both, references stored in refs/heads and refs/tags are - displayed. Note that `git ls-remote -h` used without + displayed. Note that `--heads` and `-h` are deprecated + synonyms for `--branches` and `-b` and may be removed in + the future. Also note that `git ls-remote -h` used without anything else on the command line gives help, consistent with other git subcommands. @@ -79,6 +81,9 @@ OPTIONS character. When multiple `--server-option=<option>` are given, they are all sent to the other side in the order listed on the command line. + When no `--server-option=<option>` is given from the command line, + the values of configuration variable `remote.<name>.serverOption` + are used instead. <repository>:: The "remote" repository to query. This parameter can be diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt index e3b2a88c4b..3f0a6662c8 100644 --- a/Documentation/git-mailsplit.txt +++ b/Documentation/git-mailsplit.txt @@ -34,7 +34,7 @@ OPTIONS -b:: If any file doesn't begin with a From line, assume it is a - single mail message instead of signaling error. + single mail message instead of signaling an error. -d<prec>:: Instead of the default 4 digits with leading zeros, diff --git a/Documentation/git-maintenance.txt b/Documentation/git-maintenance.txt index 805e5a2e3a..6e6651309d 100644 --- a/Documentation/git-maintenance.txt +++ b/Documentation/git-maintenance.txt @@ -102,11 +102,14 @@ prefetch:: requested refs within `refs/prefetch/`. Also, tags are not updated. + This is done to avoid disrupting the remote-tracking branches. The end users -expect these refs to stay unmoved unless they initiate a fetch. With prefetch -task, however, the objects necessary to complete a later real fetch would -already be obtained, so the real fetch would go faster. In the ideal case, +expect these refs to stay unmoved unless they initiate a fetch. However, +with the prefetch task, the objects necessary to complete a later real fetch +would already be obtained, making the real fetch faster. In the ideal case, it will just become an update to a bunch of remote-tracking branches without any object transfer. ++ +The `remote.<name>.skipFetchAll` configuration can be used to +exclude a particular remote from getting prefetched. gc:: Clean up unnecessary files and optimize the local repository. "GC" @@ -217,7 +220,9 @@ on an hourly basis. Each run executes the "hourly" tasks. At midnight, that process also executes the "daily" tasks. At midnight on the first day of the week, that process also executes the "weekly" tasks. A single process iterates over each registered repository, performing the scheduled -tasks for that frequency. Depending on the number of registered +tasks for that frequency. The processes are scheduled to a random minute of +the hour per client to spread out the load that multiple clients might +generate (e.g. from prefetching). Depending on the number of registered repositories and their sizes, this process may take longer than an hour. In this case, multiple `git maintenance run` commands may run on the same repository at the same time, colliding on the object database lock. This diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt index b01ba3d356..5ab957cfbc 100644 --- a/Documentation/git-merge-base.txt +++ b/Documentation/git-merge-base.txt @@ -18,7 +18,7 @@ SYNOPSIS DESCRIPTION ----------- -'git merge-base' finds best common ancestor(s) between two commits to use +'git merge-base' finds the best common ancestor(s) between two commits to use in a three-way merge. One common ancestor is 'better' than another common ancestor if the latter is an ancestor of the former. A common ancestor that does not have any better common ancestor is a 'best common @@ -28,7 +28,7 @@ merge base for a pair of commits. OPERATION MODES --------------- -As the most common special case, specifying only two commits on the +In the most common special case, specifying only two commits on the command line means computing the merge base between the given two commits. More generally, among the two commits to compute the merge base from, @@ -64,7 +64,7 @@ from linkgit:git-show-branch[1] when used with the `--merge-base` option. 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). + of this mode below). OPTIONS ------- @@ -88,7 +88,7 @@ For example, with this topology: the merge base between 'A' and 'B' is '1'. -Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the +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: @@ -130,7 +130,7 @@ When the history involves criss-cross merges, there can be more than one ---2---o---o---B .... -both '1' and '2' are merge-bases of A and B. Neither one is better than +both '1' and '2' are merge bases of A and B. Neither one is better than the other (both are 'best' merge bases). When the `--all` option is not given, it is unspecified which best one is output. @@ -204,7 +204,7 @@ 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 +will replay D0, D1, and D on top of B to create a new history of this shape: .... diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt index 7e9093fab6..71915a00fa 100644 --- a/Documentation/git-merge-file.txt +++ b/Documentation/git-merge-file.txt @@ -11,19 +11,20 @@ SYNOPSIS [verse] 'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]] [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>] - [--[no-]diff3] <current-file> <base-file> <other-file> + [--[no-]diff3] [--object-id] <current> <base> <other> DESCRIPTION ----------- -'git merge-file' incorporates all changes that lead from the `<base-file>` -to `<other-file>` into `<current-file>`. The result ordinarily goes into -`<current-file>`. 'git merge-file' is useful for combining separate changes -to an original. Suppose `<base-file>` is the original, and both -`<current-file>` and `<other-file>` are modifications of `<base-file>`, +Given three files `<current>`, `<base>` and `<other>`, +'git merge-file' incorporates all changes that lead from `<base>` +to `<other>` into `<current>`. The result ordinarily goes into +`<current>`. 'git merge-file' is useful for combining separate changes +to an original. Suppose `<base>` is the original, and both +`<current>` and `<other>` are modifications of `<base>`, then 'git merge-file' combines both changes. -A conflict occurs if both `<current-file>` and `<other-file>` have changes +A conflict occurs if both `<current>` and `<other>` have changes in a common segment of lines. If a conflict is found, 'git merge-file' normally outputs a warning and brackets the conflict with lines containing <<<<<<< and >>>>>>> markers. A typical conflict will look like this: @@ -36,10 +37,14 @@ normally outputs a warning and brackets the conflict with lines containing If there are conflicts, the user should edit the result and delete one of the alternatives. When `--ours`, `--theirs`, or `--union` option is in effect, -however, these conflicts are resolved favouring lines from `<current-file>`, -lines from `<other-file>`, or lines from both respectively. The length of the +however, these conflicts are resolved favouring lines from `<current>`, +lines from `<other>`, or lines from both respectively. The length of the conflict markers can be given with the `--marker-size` option. +If `--object-id` is specified, exactly the same behavior occurs, except that +instead of specifying what to merge as files, it is specified as a list of +object IDs referring to blobs. + The exit value of this program is negative on error, and the number of conflicts otherwise (truncated to 127 if there are more than that many conflicts). If the merge was clean, the exit value is 0. @@ -52,6 +57,14 @@ linkgit:git[1]. OPTIONS ------- +--object-id:: + Specify the contents to merge as blobs in the current repository instead of + files. In this case, the operation must take place within a valid repository. ++ +If the `-p` option is specified, the merged file (including conflicts, if any) +goes to standard output as normal; otherwise, the merged file is written to the +object store and the object ID of its blob is written to standard output. + -L <label>:: This option may be given up to three times, and specifies labels to be used in place of the @@ -62,7 +75,7 @@ OPTIONS -p:: Send results to standard output instead of overwriting - `<current-file>`. + `<current>`. -q:: Quiet; do not warn about conflicts. @@ -79,6 +92,12 @@ OPTIONS Instead of leaving conflicts in the file, resolve conflicts favouring our (or their or both) side of the lines. +--diff-algorithm={patience|minimal|histogram|myers}:: + Use a different diff algorithm while merging. The current default is "myers", + but selecting more recent algorithm such as "histogram" can help + avoid mismerges that occur due to unimportant matching lines + (such as braces from distinct functions). See also + linkgit:git-diff[1] `--diff-algorithm`. EXAMPLES -------- @@ -93,6 +112,11 @@ EXAMPLES merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels `a` and `c` instead of `tmp/a123` and `tmp/c345`. +`git merge-file -p --object-id abc1234 def567 890abcd`:: + + combines the changes of the blob abc1234 and 890abcd since def567, + tries to merge them and writes the result to standard output + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt index ffc4fbf7e8..0b6a8a19b1 100644 --- a/Documentation/git-merge-tree.txt +++ b/Documentation/git-merge-tree.txt @@ -19,12 +19,12 @@ DESCRIPTION This command has a modern `--write-tree` mode and a deprecated `--trivial-merge` mode. With the exception of the <<DEPMERGE,DEPRECATED DESCRIPTION>> section at the end, the rest of -this documentation describes modern `--write-tree` mode. +this documentation describes the modern `--write-tree` mode. Performs a merge, but does not make any new commits and does not read from or write to either the working tree or index. -The performed merge will use the same feature as the "real" +The performed merge will use the same features as the "real" linkgit:git-merge[1], including: * three way content merges of individual files @@ -64,10 +64,18 @@ OPTIONS share no common history. This flag can be given to override that check and make the merge proceed anyway. ---merge-base=<commit>:: +--merge-base=<tree-ish>:: Instead of finding the merge-bases for <branch1> and <branch2>, specify a merge-base for the merge, and specifying multiple bases is currently not supported. This option is incompatible with `--stdin`. ++ +As the merge-base is provided directly, <branch1> and <branch2> do not need +to specify commits; trees are enough. + +-X<option>:: +--strategy-option=<option>:: + Pass the merge strategy-specific option through to the merge strategy. + See linkgit:git-merge[1] for details. [[OUTPUT]] OUTPUT @@ -203,9 +211,15 @@ linkgit:git-commit-tree[1], linkgit:git-write-tree[1], linkgit:git-update-ref[1], and linkgit:git-mktag[1]. Thus, it can be used as a part of a series of steps such as: - NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2) - test $? -eq 0 || die "There were conflicts..." - NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2) + vi message.txt + BRANCH1=refs/heads/test + BRANCH2=main + NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2) || { + echo "There were conflicts..." 1>&2 + exit 1 + } + NEWCOMMIT=$(git commit-tree $NEWTREE -F message.txt \ + -p $BRANCH1 -p $BRANCH2) git update-ref $BRANCH1 $NEWCOMMIT Note that when the exit status is non-zero, `NEWTREE` in this sequence @@ -253,7 +267,7 @@ Do NOT attempt to guess or make the user guess the conflict types from the <<CFI,Conflicted file info>> list. The information there is insufficient to do so. For example: Rename/rename(1to2) conflicts (both sides renamed the same file differently) will result in three different -file having higher order stages (but each only has one higher order +files having higher order stages (but each only has one higher order stage), with no way (short of the <<IM,Informational messages>> section) to determine which three files are related. File/directory conflicts also result in a file with exactly one higher order stage. @@ -263,7 +277,7 @@ a file with exactly one higher order stage. In all cases, the <<IM,Informational messages>> section has the necessary info, though it is not designed to be machine parseable. -Do NOT assume that each paths from <<CFI,Conflicted file info>>, and +Do NOT assume that each path from <<CFI,Conflicted file info>>, and the logical conflicts in the <<IM,Informational messages>> have a one-to-one mapping, nor that there is a one-to-many mapping, nor a many-to-one mapping. Many-to-many mappings exist, meaning that each diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 8625c5cb0e..1ab69f61f5 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -20,12 +20,12 @@ DESCRIPTION ----------- Incorporates changes from the named commits (since the time their histories diverged from the current branch) into the current -branch. This command is used by 'git pull' to incorporate changes +branch. This command is used by `git pull` to incorporate changes from another repository and can be used by hand to merge changes from one branch into another. Assume the following history exists and the current branch is -"`master`": +`master`: ------------ A---B---C topic @@ -33,7 +33,7 @@ Assume the following history exists and the current branch is D---E---F---G master ------------ -Then "`git merge topic`" will replay the changes made on the +Then `git merge topic` will replay the changes made on the `topic` branch since it diverged from `master` (i.e., `E`) until its current commit (`C`) on top of `master`, and record the result in a new commit along with the names of the two parent commits and @@ -46,21 +46,21 @@ a log message from the user describing the changes. Before the operation, D---E---F---G---H master ------------ -The second syntax ("`git merge --abort`") can only be run after the -merge has resulted in conflicts. 'git merge --abort' will abort the -merge process and try to reconstruct the pre-merge state. However, -if there were uncommitted changes when the merge started (and -especially if those changes were further modified after the merge -was started), 'git merge --abort' will in some cases be unable to -reconstruct the original (pre-merge) changes. Therefore: +A merge stops if there's a conflict that cannot be resolved +automatically or if `--no-commit` was provided when initiating the +merge. At that point you can run `git merge --abort` or `git merge +--continue`. -*Warning*: Running 'git merge' with non-trivial uncommitted changes is +`git merge --abort` will abort the merge process and try to reconstruct +the pre-merge state. However, if there were uncommitted changes when the +merge started (and especially if those changes were further modified +after the merge was started), `git merge --abort` will in some cases be +unable to reconstruct the original (pre-merge) changes. Therefore: + +*Warning*: Running `git merge` with non-trivial uncommitted changes is discouraged: while possible, it may leave you in a state that is hard to back out of in the case of a conflict. -The third syntax ("`git merge --continue`") can only be run after the -merge has resulted in conflicts. - OPTIONS ------- :git-merge: 1 @@ -74,8 +74,8 @@ include::merge-options.txt[] If `--log` is specified, a shortlog of the commits being merged will be appended to the specified message. + -The 'git fmt-merge-msg' command can be -used to give a good default for automated 'git merge' +The `git fmt-merge-msg` command can be +used to give a good default for automated `git merge` invocations. The automated message can include the branch description. --into-name <branch>:: @@ -104,14 +104,14 @@ include::rerere-options.txt[] 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 +started, `git merge --abort` will in some cases be unable to reconstruct these changes. It is therefore recommended to always -commit or stash your changes before running 'git merge'. +commit or stash your changes before running `git merge`. + -'git merge --abort' is equivalent to 'git reset --merge' when +`git merge --abort` is equivalent to `git reset --merge` when `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 +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:: @@ -120,8 +120,8 @@ list. 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 + 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>...:: @@ -144,25 +144,25 @@ PRE-MERGE CHECKS Before applying outside changes, you should get your own work in good shape and committed locally, so it will not be clobbered if there are conflicts. See also linkgit:git-stash[1]. -'git pull' and 'git merge' will stop without doing anything when -local uncommitted changes overlap with files that 'git pull'/'git -merge' may need to update. +`git pull` and `git merge` will stop without doing anything when +local uncommitted changes overlap with files that `git pull`/`git +merge` may need to update. To avoid recording unrelated changes in the merge commit, -'git pull' and 'git merge' will also abort if there are any changes +`git pull` and `git merge` will also abort if there are any changes registered in the index relative to the `HEAD` commit. (Special narrow exceptions to this rule may exist depending on which merge strategy is in use, but generally, the index must match HEAD.) -If all named commits are already ancestors of `HEAD`, 'git merge' +If all named commits are already ancestors of `HEAD`, `git merge` will exit early with the message "Already up to date." FAST-FORWARD MERGE ------------------ Often the current branch head is an ancestor of the named commit. -This is the most common case especially when invoked from 'git -pull': you are tracking an upstream repository, you have committed +This is the most common case especially when invoked from `git +pull`: you are tracking an upstream repository, you have committed no local changes, and now you want to update to a newer upstream revision. In this case, a new commit is not needed to store the combined history; instead, the `HEAD` (along with the index) is @@ -196,7 +196,7 @@ happens: can inspect the stages with `git ls-files -u`). The working tree files contain the result of the merge operation; i.e. 3-way merge results with familiar conflict markers `<<<` `===` `>>>`. -5. A special ref `AUTO_MERGE` is written, pointing to a tree +5. A ref named `AUTO_MERGE` is written, pointing to a tree corresponding to the current content of the working tree (including conflict markers for textual conflicts). Note that this ref is only written when the 'ort' merge strategy is used (the default). @@ -269,7 +269,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 either "diff3" or "zdiff3". In "diff3" style, the above conflict may look like this: @@ -328,15 +328,15 @@ 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' or - 'git merge --continue' to seal the deal. The latter command + `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'. + before calling `git commit`. You can work through the conflict with a number of tools: * Use a mergetool. `git mergetool` to launch a graphical - mergetool which will work you through the merge. + mergetool which will work through the merge with you. * Look at the diffs. `git diff` will show a three-way diff, highlighting changes from both the `HEAD` and `MERGE_HEAD` @@ -392,7 +392,7 @@ CONFIGURATION 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 + supported options are the same as those of `git merge`, but option values containing whitespace characters are currently not supported. include::includes/cmd-config-section-rest.txt[] diff --git a/Documentation/git-mergetool--lib.txt b/Documentation/git-mergetool--lib.txt index 3e8f59ac0e..0726b560d4 100644 --- a/Documentation/git-mergetool--lib.txt +++ b/Documentation/git-mergetool--lib.txt @@ -28,22 +28,22 @@ to define the operation mode for the functions listed below. FUNCTIONS --------- get_merge_tool:: - returns a merge tool. the return code is 1 if we returned a guessed + 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. + Returns the custom command for a merge tool. get_merge_tool_path:: - returns the custom path for a merge tool. + Returns the custom path for a merge tool. initialize_merge_tool:: - bring merge tool specific functions into scope so they can be used or + Brings merge tool specific functions into scope so they can be used or overridden. run_merge_tool:: - launches a merge tool given the tool name and a true/false + Launches a merge tool given the tool name and a true/false flag to indicate whether a merge base is present. '$MERGED', '$LOCAL', '$REMOTE', and '$BASE' must be defined for use by the merge tool. diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt index 07535f6576..b9e20c5dcd 100644 --- a/Documentation/git-mergetool.txt +++ b/Documentation/git-mergetool.txt @@ -17,7 +17,7 @@ Use `git mergetool` to run one of several merge utilities to resolve merge conflicts. It is typically run after 'git merge'. If one or more <file> parameters are given, the merge tool program will -be run to resolve differences on each file (skipping those without +be run to resolve differences in each file (skipping those without conflicts). Specifying a directory will include all unresolved files in that path. If no <file> names are specified, 'git mergetool' will run the merge tool program on every file with merge conflicts. @@ -49,7 +49,7 @@ variable `mergetool.<tool>.cmd`. + When 'git mergetool' is invoked with this tool (either through the `-t` or `--tool` option or the `merge.tool` configuration -variable) the configured command line will be invoked with `$BASE` +variable), the configured command line will be invoked with `$BASE` set to the name of a temporary file containing the common base for the merge, if available; `$LOCAL` set to the name of a temporary file containing the contents of the file on the current branch; @@ -81,7 +81,7 @@ success of the resolution after the custom tool has exited. -g:: --gui:: - When 'git-mergetool' is invoked with the `-g` or `--gui` option + 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 @@ -115,7 +115,7 @@ These are safe to remove once a file has been merged and its `git mergetool` session has completed. Setting the `mergetool.keepBackup` configuration variable to `false` -causes `git mergetool` to automatically remove the backup as files +causes `git mergetool` to automatically remove the backup files as files are successfully merged. BACKEND SPECIFIC HINTS diff --git a/Documentation/git-mktag.txt b/Documentation/git-mktag.txt index b2a2e80d42..006d759962 100644 --- a/Documentation/git-mktag.txt +++ b/Documentation/git-mktag.txt @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION ----------- -Reads a tag contents on standard input and creates a tag object. The +Reads a tag's contents on standard input and creates a tag object. The output is the new tag's <object> identifier. This command is mostly equivalent to linkgit:git-hash-object[1] @@ -27,7 +27,7 @@ write a tag found in `my-tag`: The difference is that mktag will die before writing the tag if the tag doesn't pass a linkgit:git-fsck[1] check. -The "fsck" check done mktag is stricter than what linkgit:git-fsck[1] +The "fsck" check done by mktag is stricter than what linkgit:git-fsck[1] would run by default in that all `fsck.<msg-id>` messages are promoted from warnings to errors (so e.g. a missing "tagger" line is an error). @@ -56,7 +56,7 @@ has a very simple fixed format: four lines of tagger <tagger> followed by some 'optional' free-form message (some tags created -by older Git may not have `tagger` line). The message, when it +by older Git may not have a `tagger` line). The message, when it exists, is separated by a blank line from the header. The message part may contain a signature that Git itself doesn't care about, but that can be verified with gpg. diff --git a/Documentation/git-mktree.txt b/Documentation/git-mktree.txt index 76b44f4da1..383f09dd33 100644 --- a/Documentation/git-mktree.txt +++ b/Documentation/git-mktree.txt @@ -25,13 +25,13 @@ OPTIONS --missing:: Allow missing objects. The default behaviour (without this option) - is to verify that each tree entry's sha1 identifies an existing + is to verify that each tree entry's hash identifies an existing object. This option has no effect on the treatment of gitlink entries (aka "submodules") which are always allowed to be missing. --batch:: Allow building of more than one tree object before exiting. Each - tree is separated by a single blank line. The final new-line is + tree is separated by a single blank line. The final newline is optional. Note - if the `-z` option is used, lines are terminated with NUL. diff --git a/Documentation/git-multi-pack-index.txt b/Documentation/git-multi-pack-index.txt index 3696506eb3..631d5c7d15 100644 --- a/Documentation/git-multi-pack-index.txt +++ b/Documentation/git-multi-pack-index.txt @@ -64,6 +64,12 @@ The file given at `<path>` is expected to be readable, and can contain duplicates. (If a given OID is given more than once, it is marked as preferred if at least one instance of it begins with the special `+` marker). + + --incremental:: + Write an incremental MIDX file containing only objects + and packs not present in an existing MIDX layer. + Migrates non-incremental MIDXs to incremental ones when + necessary. Incompatible with `--bitmap`. -- verify:: @@ -74,6 +80,8 @@ expire:: have no objects referenced by the MIDX (with the exception of `.keep` packs and cruft packs). Rewrite the MIDX file afterward to remove all references to these pack-files. ++ +NOTE: this mode is incompatible with incremental MIDX files. repack:: Create a new pack-file containing objects in small pack-files @@ -95,7 +103,8 @@ repack:: + If `repack.packKeptObjects` is `false`, then any pack-files with an associated `.keep` file will not be selected for the batch to repack. - ++ +NOTE: this mode is incompatible with incremental MIDX files. EXAMPLES -------- diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt index fb0220fd18..dc1bf61534 100644 --- a/Documentation/git-mv.txt +++ b/Documentation/git-mv.txt @@ -13,10 +13,10 @@ SYNOPSIS DESCRIPTION ----------- -Move or rename a file, directory or symlink. +Move or rename a file, directory, or symlink. git mv [-v] [-f] [-n] [-k] <source> <destination> - git mv [-v] [-f] [-n] [-k] <source> ... <destination directory> + git mv [-v] [-f] [-n] [-k] <source> ... <destination-directory> In the first form, it renames <source>, which must exist and be either a file, symlink or directory, to <destination>. diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt index 5c56c87025..d4f1c4d594 100644 --- a/Documentation/git-name-rev.txt +++ b/Documentation/git-name-rev.txt @@ -26,7 +26,7 @@ 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. If + can be a branch name, a tag name, or a 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. diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index f8310e56a8..84022f99d7 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -9,9 +9,9 @@ SYNOPSIS -------- [verse] 'git notes' [list [<object>]] -'git notes' add [-f] [--allow-empty] [--[no-]separator | --separator=<paragraph-break>] [--[no-]stripspace] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] +'git notes' add [-f] [--allow-empty] [--[no-]separator | --separator=<paragraph-break>] [--[no-]stripspace] [-F <file> | -m <msg> | (-c | -C) <object>] [-e] [<object>] 'git notes' copy [-f] ( --stdin | <from-object> [<to-object>] ) -'git notes' append [--allow-empty] [--[no-]separator | --separator=<paragraph-break>] [--[no-]stripspace] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] +'git notes' append [--allow-empty] [--[no-]separator | --separator=<paragraph-break>] [--[no-]stripspace] [-F <file> | -m <msg> | (-c | -C) <object>] [-e] [<object>] 'git notes' edit [--allow-empty] [<object>] [--[no-]stripspace] 'git notes' show [<object>] 'git notes' merge [-v | -q] [-s <strategy> ] <notes-ref> @@ -56,7 +56,7 @@ SUBCOMMANDS list:: List the notes object for a given object. If no object is given, show a list of all note objects and the objects they - annotate (in the format "<note object> <annotated object>"). + annotate (in the format "<note-object> <annotated-object>"). This is the default subcommand if no subcommand is given. add:: @@ -67,7 +67,9 @@ add:: the existing notes will be opened in the editor (like the `edit` subcommand). If you specify multiple `-m` and `-F`, a blank line will be inserted between the messages. Use the `--separator` - option to insert other delimiters. + option to insert other delimiters. You can use `-e` to edit and + fine-tune the message(s) supplied from `-m` and `-F` options + interactively (using an editor) before adding the note. copy:: Copy the notes for the first object onto the second object (defaults to @@ -93,6 +95,8 @@ append:: an existing note, a blank line is added before each new message as an inter-paragraph separator. The separator can be customized with the `--separator` option. + Edit the notes to be appended given by `-m` and `-F` options with + `-e` interactively (using an editor) before appending the note. edit:: Edit the notes for a given object (defaults to HEAD). diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt index a9995a932c..e32404c6aa 100644 --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -116,9 +116,7 @@ unreachable object whose mtime is newer than the `--cruft-expiration`). + Incompatible with `--unpack-unreachable`, `--keep-unreachable`, `--pack-loose-unreachable`, `--stdin-packs`, as well as any other -options which imply `--revs`. Also incompatible with `--max-pack-size`; -when this option is set, the maximum pack size is not inferred from -`pack.packSizeLimit`. +options which imply `--revs`. --cruft-expiration=<approxidate>:: If specified, objects are eliminated from the cruft pack if they @@ -298,8 +296,8 @@ So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle. nevertheless. --filter=<filter-spec>:: - Requires `--stdout`. Omits certain objects (usually blobs) from - the resulting packfile. See linkgit:git-rev-list[1] for valid + Omits certain objects (usually blobs) from the resulting + packfile. See linkgit:git-rev-list[1] for valid `<filter-spec>` forms. --no-filter:: diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt index 284956acb3..2dcabaf74c 100644 --- a/Documentation/git-pack-refs.txt +++ b/Documentation/git-pack-refs.txt @@ -8,7 +8,7 @@ git-pack-refs - Pack heads and tags for efficient repository access SYNOPSIS -------- [verse] -'git pack-refs' [--all] [--no-prune] [--include <pattern>] [--exclude <pattern>] +'git pack-refs' [--all] [--no-prune] [--auto] [--include <pattern>] [--exclude <pattern>] DESCRIPTION ----------- @@ -60,6 +60,19 @@ with many branches of historical interests. The command usually removes loose refs under `$GIT_DIR/refs` hierarchy after packing them. This option tells it not to. +--auto:: + +Pack refs as needed depending on the current state of the ref database. The +behavior depends on the ref format used by the repository and may change in the +future. ++ + - "files": No special handling for `--auto` has been implemented. ++ + - "reftable": Tables are compacted such that they form a geometric + sequence. For two tables N and N+1, where N+1 is newer, this + maintains the property that N is at least twice as big as N+1. Only + tables that violate this property are compacted. + --include <pattern>:: Pack refs based on a `glob(7)` pattern. Repetitions of this option diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt index 844d6f808a..db742dcfee 100644 --- a/Documentation/git-prune-packed.txt +++ b/Documentation/git-prune-packed.txt @@ -15,7 +15,7 @@ SYNOPSIS DESCRIPTION ----------- This program searches the `$GIT_OBJECT_DIRECTORY` for all objects that currently -exist in a pack file as well as the independent object directories. +exist in a pack file as well as in the independent object directories. All such extra objects are removed. diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index 03552dd86f..9a45571b90 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -18,7 +18,7 @@ NOTE: In most cases, users should run 'git gc', which calls 'git prune'. See the section "NOTES", below. This runs 'git fsck --unreachable' using all the refs -available in `refs/`, optionally with additional set of +available in `refs/`, optionally with an additional set of objects specified on the command line, and prunes all unpacked objects unreachable from any of these head objects from the object database. In addition, it diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index 0e14f8b5b2..b2ae496e48 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -87,7 +87,7 @@ OPTIONS --verbose:: Pass --verbose to git-fetch and git-merge. ---[no-]recurse-submodules[=yes|on-demand|no]:: +--[no-]recurse-submodules[=(yes|on-demand|no)]:: 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 @@ -105,7 +105,7 @@ Options related to merging include::merge-options.txt[] -r:: ---rebase[=false|true|merges|interactive]:: +--rebase[=(false|true|merges|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 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 003bc7d9ce..9b7cfbc5c1 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -48,7 +48,7 @@ local one. OPTIONS[[OPTIONS]] ------------------ <repository>:: - The "remote" repository that is destination of a push + The "remote" repository that is the destination of a push operation. This parameter can be either a URL (see the section <<URLS,GIT URLS>> below) or the name of a remote (see the section <<REMOTES,REMOTES>> below). diff --git a/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt index 70562dc4c0..40e02d92eb 100644 --- a/Documentation/git-quiltimport.txt +++ b/Documentation/git-quiltimport.txt @@ -38,14 +38,14 @@ OPTIONS a patch. At the time of this writing only missing author information is warned about. ---author Author Name <Author Email>:: +--author 'Author Name <Author Email>':: The author name and email address to use when no author information can be found in the patch description. --patches <dir>:: The directory to find the quilt patches. + -The default for the patch directory is patches +The default for the patch directory is 'patches' or the value of the `$QUILT_PATCHES` environment variable. diff --git a/Documentation/git-range-diff.txt b/Documentation/git-range-diff.txt index 0b393715d7..fbdbe0befe 100644 --- a/Documentation/git-range-diff.txt +++ b/Documentation/git-range-diff.txt @@ -70,7 +70,7 @@ to revert to color all lines according to the outer diff markers 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 + See the ``Algorithm`` section below for an explanation of why this is needed. --left-only:: @@ -166,7 +166,7 @@ A typical output of `git range-diff` would look like this: 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. +commit message of the 2nd commit as well as 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 diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt index b09707474d..1c48c28996 100644 --- a/Documentation/git-read-tree.txt +++ b/Documentation/git-read-tree.txt @@ -25,15 +25,15 @@ fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m` flag. When used with `-m`, the `-u` flag causes it to also update the files in the work tree with the result of the merge. -Trivial merges are done by 'git read-tree' itself. Only conflicting paths -will be in unmerged state when 'git read-tree' returns. +Only trivial merges are done by 'git read-tree' itself. Only conflicting paths +will be in an unmerged state when 'git read-tree' returns. OPTIONS ------- -m:: Perform a merge, not just a read. The command will refuse to run if your index file has unmerged entries, - indicating that you have not finished previous merge you + indicating that you have not finished a previous merge you started. --reset:: diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index e7b39ad244..b18cdbc023 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -12,7 +12,7 @@ SYNOPSIS [--onto <newbase> | --keep-base] [<upstream> [<branch>]] 'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] --root [<branch>] -'git rebase' (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch) +'git rebase' (--continue|--skip|--abort|--quit|--edit-todo|--show-current-patch) DESCRIPTION ----------- @@ -289,17 +289,25 @@ See also INCOMPATIBLE OPTIONS below. + See also INCOMPATIBLE OPTIONS below. ---empty={drop,keep,ask}:: +--empty=(drop|keep|stop):: 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. + upstream changes): ++ +-- +`drop`;; + The commit will be dropped. This is the default behavior. +`keep`;; + The commit will be kept. This option is implied when `--exec` is + specified unless `-i`/`--interactive` is also specified. +`stop`;; +`ask`;; + The rebase will halt when the commit is applied, allowing you to + choose whether to drop it, edit files more, or just commit the empty + changes. This option is implied when `-i`/`--interactive` is + specified. `ask` is a deprecated synonym of `stop`. +-- + Note that commits which start empty are kept (unless `--no-keep-empty` is specified), and commits which are clean cherry-picks (as determined @@ -523,7 +531,7 @@ See also INCOMPATIBLE OPTIONS 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. +have the commit hash prepended to the format. + See also INCOMPATIBLE OPTIONS below. @@ -589,21 +597,27 @@ See also INCOMPATIBLE OPTIONS below. --autosquash:: --no-autosquash:: - When the commit log message begins with "squash! ..." or "fixup! ..." - or "amend! ...", 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` or `fixup -C` respectively. 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/amend/squash - commits is by using the `--fixup`, `--fixup=amend:` or `--fixup=reword:` - and `--squash` options respectively of linkgit:git-commit[1]. + Automatically squash commits with specially formatted messages into + previous commits being rebased. If a commit message starts with + "squash! ", "fixup! " or "amend! ", the remainder of the subject line + is taken as a commit specifier, which matches a previous commit if it + matches the subject line or the hash of that commit. If no commit + matches fully, matches of the specifier with the start of commit + subjects are considered. ++ +In the rebase todo list, the actions of squash, fixup and amend commits are +changed from `pick` to `squash`, `fixup` or `fixup -C`, respectively, and they +are moved right after the commit they modify. The `--interactive` option can +be used to review and edit the todo list before proceeding. + -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. +The recommended way to create commits with squash markers is by using the +`--squash`, `--fixup`, `--fixup=amend:` or `--fixup=reword:` options of +linkgit:git-commit[1], which take the target commit as an argument and +automatically fill in the subject line of the new commit from that. ++ +Setting configuration variable `rebase.autoSquash` to true enables +auto-squashing by default for interactive rebase. The `--no-autosquash` +option can be used to override that setting. + See also INCOMPATIBLE OPTIONS below. @@ -620,13 +634,16 @@ See also INCOMPATIBLE OPTIONS below. Automatically reschedule `exec` commands that failed. This only makes sense in interactive mode (or when an `--exec` option was provided). + -Even though this option applies once a rebase is started, it's set for -the whole rebase at the start based on either the -`rebase.rescheduleFailedExec` configuration (see linkgit:git-config[1] -or "CONFIGURATION" below) or whether this option is -provided. Otherwise an explicit `--no-reschedule-failed-exec` at the -start would be overridden by the presence of -`rebase.rescheduleFailedExec=true` configuration. +This option applies once a rebase is started. It is preserved for the whole +rebase based on, in order, the command line option provided to the initial `git +rebase`, the `rebase.rescheduleFailedExec` configuration (see +linkgit:git-config[1] or "CONFIGURATION" below), or it defaults to false. ++ +Recording this option for the whole rebase is a convenience feature. Otherwise +an explicit `--no-reschedule-failed-exec` at the start would be overridden by +the presence of a `rebase.rescheduleFailedExec=true` configuration when `git +rebase --continue` is invoked. Currently, you cannot pass +`--[no-]reschedule-failed-exec` to `git rebase --continue`. --update-refs:: --no-update-refs:: @@ -695,7 +712,7 @@ 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 +also has an `--empty=(drop|keep|stop)` option for changing the behavior of handling commits that become empty. Directory rename detection @@ -720,7 +737,7 @@ 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 +line numbers have to be taken with some offset, 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 @@ -957,10 +974,9 @@ The interactive rebase will stop when a command fails (i.e. exits with non-0 status) to give you an opportunity to fix the problem. You can continue with `git rebase --continue`. -The "exec" command launches the command in a shell (the one specified -in `$SHELL`, or the default shell if `$SHELL` is not set), so you can -use shell features (like "cd", ">", ";" ...). The command is run from -the root of the working tree. +The "exec" command launches the command in a shell (the default one, usually +/bin/sh), so you can use shell features (like "cd", ">", ";" ...). The command +is run from the root of the working tree. ---------------------------------- $ git rebase -i --exec "make test" diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt index 65ff518ccf..20aca92073 100644 --- a/Documentation/git-receive-pack.txt +++ b/Documentation/git-receive-pack.txt @@ -18,10 +18,10 @@ information fed from the remote end. This command is usually not invoked directly by the end user. The UI for the protocol is on the 'git send-pack' side, and the -program pair is meant to be used to push updates to remote +program pair is meant to be used to push updates to a remote repository. For pull operations, see linkgit:git-fetch-pack[1]. -The command allows for creation and fast-forwarding of sha1 refs +The command allows for the creation and fast-forwarding of sha1 refs (heads/tags) on the remote end (strictly speaking, it is the local end 'git-receive-pack' runs, but to the user who is sitting at the send-pack end, it is updating the remote. Confused?) diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt index ec64cbff4c..a929c52982 100644 --- a/Documentation/git-reflog.txt +++ b/Documentation/git-reflog.txt @@ -10,6 +10,7 @@ SYNOPSIS -------- [verse] 'git reflog' [show] [<log-options>] [<ref>] +'git reflog list' 'git reflog expire' [--expire=<time>] [--expire-unreachable=<time>] [--rewrite] [--updateref] [--stale-fix] [--dry-run | -n] [--verbose] [--all [--single-worktree] | <refs>...] @@ -39,6 +40,8 @@ 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 "list" subcommand lists all refs which have a corresponding reflog. + 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. diff --git a/Documentation/git-refs.txt b/Documentation/git-refs.txt new file mode 100644 index 0000000000..ce31f93061 --- /dev/null +++ b/Documentation/git-refs.txt @@ -0,0 +1,74 @@ +git-refs(1) +=========== + +NAME +---- +git-refs - Low-level access to refs + + +SYNOPSIS +-------- +[verse] +'git refs migrate' --ref-format=<format> [--dry-run] +'git refs verify' [--strict] [--verbose] + +DESCRIPTION +----------- + +This command provides low-level access to refs. + +COMMANDS +-------- + +migrate:: + Migrate ref store between different formats. + +verify:: + Verify reference database consistency. + +OPTIONS +------- + +The following options are specific to 'git refs migrate': + +--ref-format=<format>:: + The ref format to migrate the ref store to. Can be one of: ++ +include::ref-storage-format.txt[] + +--dry-run:: + Perform the migration, but do not modify the repository. The migrated + refs will be written into a separate directory that can be inspected + separately. The name of the directory will be reported on stdout. This + can be used to double check that the migration works as expected before + performing the actual migration. + +The following options are specific to 'git refs verify': + +--strict:: + Enable stricter error checking. This will cause warnings to be + reported as errors. See linkgit:git-fsck[1]. + +--verbose:: + When verifying the reference database consistency, be chatty. + +KNOWN LIMITATIONS +----------------- + +The ref format migration has several known limitations in its current form: + +* It is not possible to migrate repositories that have reflogs. + +* It is not possible to migrate repositories that have worktrees. + +* There is no way to block concurrent writes to the repository during an + ongoing migration. Concurrent writes can lead to an inconsistent migrated + state. Users are expected to block writes on a higher level. If your + repository is registered for scheduled maintenance, it is recommended to + unregister it first with git-maintenance(1). + +These limitations may eventually be lifted. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote-ext.txt b/Documentation/git-remote-ext.txt index 88ea7e1cc0..b33ee3c9e8 100644 --- a/Documentation/git-remote-ext.txt +++ b/Documentation/git-remote-ext.txt @@ -44,15 +44,15 @@ The following sequences have a special meaning: This argument will not be passed to '<command>'. Instead, it will cause the helper to start by sending git:// service requests to the remote side with the service field set to an appropriate value and - the repository field set to rest of the argument. Default is not to send + the repository field set to the rest of the argument. Default is not to send such a request. + -This is useful if remote side is git:// server accessed over +This is useful if the remote side is git:// server accessed over some tunnel. '%V' (must be first characters in argument):: This argument will not be passed to '<command>'. Instead it sets - the vhost field in the git:// service request (to rest of the argument). + the vhost field in the git:// service request (to the rest of the argument). Default is not to send vhost in such request (if sent). ENVIRONMENT VARIABLES @@ -82,12 +82,12 @@ begins with `ext::`. Examples: "ext::ssh -i /home/foo/.ssh/somekey user@host.example %S 'foo/repo'":: Like host.example:foo/repo, but use /home/foo/.ssh/somekey as - keypair and user as user on remote side. This avoids needing to + keypair and user as the user on the remote side. This avoids the need to edit .ssh/config. "ext::socat -t3600 - ABSTRACT-CONNECT:/git-server %G/somerepo":: Represents repository with path /somerepo accessible over - git protocol at abstract namespace address /git-server. + git protocol at the abstract namespace address /git-server. "ext::git-server-alias foo %G/repo":: Represents a repository with path /repo accessed using the diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt index 0451ceb8a2..1dd2648a79 100644 --- a/Documentation/git-remote-fd.txt +++ b/Documentation/git-remote-fd.txt @@ -13,19 +13,19 @@ DESCRIPTION ----------- This helper uses specified file descriptors to connect to a remote Git server. This is not meant for end users but for programs and scripts calling git -fetch, push or archive. +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 +to a remote Git server (git-upload-pack, git-receive-pack, or git-upload-archive). If both <infd> and <outfd> are given, they are assumed to be pipes connected to a remote Git server (<infd> being the inbound pipe -and <outfd> being the outbound pipe. +and <outfd> being the outbound pipe). It is assumed that any handshaking procedures have already been completed (such as sending service request for git://) before this helper is started. <anything> can be any string. It is ignored. It is meant for providing -information to user in the URL in case that URL is displayed in some +information to the user in the URL in case that URL is displayed in some context. ENVIRONMENT VARIABLES @@ -45,7 +45,7 @@ EXAMPLES `git push fd::7,8 master (as URL)`:: Push master, using file descriptor #7 to read data from git-receive-pack and file descriptor #8 to write data to - same service. + the same service. `git push fd::7,8/bar master`:: Same as above. diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 1dec314834..932a5c3ea4 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -35,7 +35,7 @@ OPTIONS -v:: --verbose:: Be a little more verbose and show remote url after name. - For promisor remotes, also show which filter (`blob:none` etc.) + For promisor remotes, also show which filters (`blob:none` etc.) are configured. NOTE: This must be placed between `remote` and subcommand. diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt index b63e8abc7d..c902512a9e 100644 --- a/Documentation/git-repack.txt +++ b/Documentation/git-repack.txt @@ -74,6 +74,17 @@ to the new separate pack will be written. immediately instead of waiting for the next `git gc` invocation. Only useful with `--cruft -d`. +--max-cruft-size=<n>:: + Repack cruft objects into packs as large as `<n>` bytes before + creating new packs. As long as there are enough cruft packs + smaller than `<n>`, repacking will cause a new cruft pack to + be created containing objects from any combined cruft packs, + along with any new unreachable objects. Cruft packs larger than + `<n>` will not be modified. When the new cruft pack is larger + than `<n>` bytes, it will be split into multiple packs, all of + which are guaranteed to be at most `<n>` bytes in size. Only + useful with `--cruft -d`. + --expire-to=<dir>:: Write a cruft pack containing pruned objects (if any) to the directory `<dir>`. This option is useful for keeping a copy of @@ -143,6 +154,29 @@ depth is 4095. a larger and slower repository; see the discussion in `pack.packSizeLimit`. +--filter=<filter-spec>:: + Remove objects matching the filter specification from the + resulting packfile and put them into a separate packfile. Note + that objects used in the working directory are not filtered + out. So for the split to fully work, it's best to perform it + in a bare repo and to use the `-a` and `-d` options along with + this option. Also `--no-write-bitmap-index` (or the + `repack.writebitmaps` config option set to `false`) should be + used otherwise writing bitmap index will fail, as it supposes + a single packfile containing all the objects. See + linkgit:git-rev-list[1] for valid `<filter-spec>` forms. + +--filter-to=<dir>:: + Write the pack containing filtered out objects to the + directory `<dir>`. Only useful with `--filter`. This can be + used for putting the pack on a separate object directory that + is accessed through the Git alternates mechanism. **WARNING:** + If the packfile containing the filtered out objects is not + accessible, the repo can become corrupt as it might not be + possible to access the objects in that packfile. See the + `objects` and `objects/info/alternates` sections of + linkgit:gitrepository-layout[5]. + -b:: --write-bitmap-index:: Write a reachability bitmap index as part of the repack. This @@ -165,7 +199,7 @@ depth is 4095. 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 + The option can be specified multiple times to keep multiple packs. --unpack-unreachable=<when>:: diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index f271d758c3..0a65460adb 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -35,7 +35,7 @@ Replacement references will be used by default by all Git commands except those doing reachability traversal (prune, pack transfer and fsck). -It is possible to disable use of replacement references for any +It is possible to disable the use of replacement references for any command using the `--no-replace-objects` option just after 'git'. For example if commit 'foo' has been replaced by commit 'bar': @@ -111,14 +111,14 @@ OPTIONS FORMATS ------- -The following format are available: +The following formats are available: * 'short': - <replaced sha1> + <replaced-sha1> * 'medium': - <replaced sha1> -> <replacement sha1> + <replaced-sha1> -> <replacement-sha1> * 'long': - <replaced sha1> (<replaced type>) -> <replacement sha1> (<replacement type>) + <replaced-sha1> (<replaced-type>) -> <replacement-sha1> (<replacement-type>) CREATING REPLACEMENT OBJECTS ---------------------------- diff --git a/Documentation/git-replay.txt b/Documentation/git-replay.txt new file mode 100644 index 0000000000..8f3300c683 --- /dev/null +++ b/Documentation/git-replay.txt @@ -0,0 +1,127 @@ +git-replay(1) +============= + +NAME +---- +git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos too + + +SYNOPSIS +-------- +[verse] +(EXPERIMENTAL!) 'git replay' ([--contained] --onto <newbase> | --advance <branch>) <revision-range>... + +DESCRIPTION +----------- + +Takes ranges of commits and replays them onto a new location. Leaves +the working tree and the index untouched, and updates no references. +The output of this command is meant to be used as input to +`git update-ref --stdin`, which would update the relevant branches +(see the OUTPUT section below). + +THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. + +OPTIONS +------- + +--onto <newbase>:: + Starting point at which to create the new commits. May be any + valid commit, and not just an existing branch name. ++ +When `--onto` is specified, the update-ref command(s) in the output will +update the branch(es) in the revision range to point at the new +commits, similar to the way how `git rebase --update-refs` updates +multiple branches in the affected range. + +--advance <branch>:: + Starting point at which to create the new commits; must be a + branch name. ++ +When `--advance` is specified, the update-ref command(s) in the output +will update the branch passed as an argument to `--advance` to point at +the new commits (in other words, this mimics a cherry-pick operation). + +<revision-range>:: + Range of commits to replay. More than one <revision-range> can + be passed, but in `--advance <branch>` mode, they should have + a single tip, so that it's clear where <branch> should point + to. See "Specifying Ranges" in linkgit:git-rev-parse[1] and the + "Commit Limiting" options below. + +include::rev-list-options.txt[] + +OUTPUT +------ + +When there are no conflicts, the output of this command is usable as +input to `git update-ref --stdin`. It is of the form: + + update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} + update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} + update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH} + +where the number of refs updated depends on the arguments passed and +the shape of the history being replayed. When using `--advance`, the +number of refs updated is always one, but for `--onto`, it can be one +or more (rebasing multiple branches simultaneously is supported). + +EXIT STATUS +----------- + +For a successful, non-conflicted replay, the exit status is 0. When +the replay has conflicts, the exit status is 1. If the replay is not +able to complete (or start) due to some kind of error, the exit status +is something other than 0 or 1. + +EXAMPLES +-------- + +To simply rebase `mybranch` onto `target`: + +------------ +$ git replay --onto target origin/main..mybranch +update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH} +------------ + +To cherry-pick the commits from mybranch onto target: + +------------ +$ git replay --advance target origin/main..mybranch +update refs/heads/target ${NEW_target_HASH} ${OLD_target_HASH} +------------ + +Note that the first two examples replay the exact same commits and on +top of the exact same new base, they only differ in that the first +provides instructions to make mybranch point at the new commits and +the second provides instructions to make target point at them. + +What if you have a stack of branches, one depending upon another, and +you'd really like to rebase the whole set? + +------------ +$ git replay --contained --onto origin/main origin/main..tipbranch +update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} +update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} +update refs/heads/tipbranch ${NEW_tipbranch_HASH} ${OLD_tipbranch_HASH} +------------ + +When calling `git replay`, one does not need to specify a range of +commits to replay using the syntax `A..B`; any range expression will +do: + +------------ +$ git replay --onto origin/main ^base branch1 branch2 branch3 +update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} +update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} +update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH} +------------ + +This will simultaneously rebase `branch1`, `branch2`, and `branch3`, +all commits they have since `base`, playing them on top of +`origin/main`. These three branches may have commits on top of `base` +that they have in common, but that does not need to be the case. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-request-pull.txt b/Documentation/git-request-pull.txt index fa5a426709..15dcbb6d91 100644 --- a/Documentation/git-request-pull.txt +++ b/Documentation/git-request-pull.txt @@ -16,7 +16,7 @@ DESCRIPTION Generate a request asking your upstream project to pull changes into their tree. The request, printed to the standard output, begins with the branch description, summarizes -the changes and indicates from where they can be pulled. +the 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 @@ -50,7 +50,7 @@ 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. +the `v1.0` release, and want it to be integrated into the project. First you push that change to your public repository for others to see: diff --git a/Documentation/git-restore.txt b/Documentation/git-restore.txt index 5964810caa..975825b44a 100644 --- a/Documentation/git-restore.txt +++ b/Documentation/git-restore.txt @@ -78,6 +78,8 @@ all modified paths. --theirs:: When restoring files in the working tree from the index, use stage #2 ('ours') or #3 ('theirs') for unmerged paths. + This option cannot be used when checking out paths from a + tree-ish (i.e. with the `--source` option). + Note that during `git rebase` and `git pull --rebase`, 'ours' and 'theirs' may appear swapped. See the explanation of the same options @@ -87,6 +89,8 @@ in linkgit:git-checkout[1] for details. --merge:: When restoring files on the working tree from the index, recreate the conflicted merge in the unmerged paths. + This option cannot be used when checking out paths from a + tree-ish (i.e. with the `--source` option). --conflict=<style>:: The same as `--merge` option above, but changes the way the @@ -101,7 +105,7 @@ in linkgit:git-checkout[1] for details. 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 + In sparse checkout mode, the 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 @@ -195,7 +199,7 @@ 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 +or you can restore both the index and the working tree (this is the same as using linkgit:git-checkout[1]) ------------ diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt index 51029a2271..2e05c4b510 100644 --- a/Documentation/git-rev-list.txt +++ b/Documentation/git-rev-list.txt @@ -17,9 +17,9 @@ DESCRIPTION :git-rev-list: 1 include::rev-list-description.txt[] -'rev-list' is a very essential Git command, since it +'rev-list' is an essential Git command, since it provides the ability to build and traverse commit ancestry graphs. For -this reason, it has a lot of different options that enables it to be +this reason, it has a lot of different options that enable it to be used by commands as different as 'git bisect' and 'git repack'. diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index f26a7591e3..dc12d38534 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -9,17 +9,24 @@ git-rev-parse - Pick out and massage parameters SYNOPSIS -------- [verse] -'git rev-parse' [<options>] <args>... +'git rev-parse' [<options>] <arg>... DESCRIPTION ----------- -Many Git porcelainish commands take mixture of flags +Many Git porcelainish commands take a mixture of flags (i.e. parameters that begin with a dash '-') and parameters meant for the underlying 'git rev-list' command they use internally and flags and parameters for the other commands they use -downstream of 'git rev-list'. This command is used to -distinguish between them. +downstream of 'git rev-list'. The primary purpose of this command +is to allow calling programs to distinguish between them. There are +a few other operation modes that have nothing to do with the above +"help parse command line options". + +Unless otherwise specified, most of the options and operation modes +require you to run this command inside a git repository or a working +tree that is under the control of a git repository, and will give you +a fatal error otherwise. OPTIONS @@ -32,11 +39,15 @@ Each of these options must appear first on the command line. --parseopt:: Use 'git rev-parse' in option parsing mode (see PARSEOPT section below). + The command in this mode can be used outside a repository or + a working tree controlled by a repository. --sq-quote:: Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE section below). In contrast to the `--sq` option below, this - mode does only quoting. Nothing else is done to command input. + mode only does quoting. Nothing else is done to command input. + The command in this mode can be used outside a repository or + a working tree controlled by a repository. Options for --parseopt ~~~~~~~~~~~~~~~~~~~~~~ @@ -130,7 +141,7 @@ for another option. 'git diff-{asterisk}'). In contrast to the `--sq-quote` option, the command input is still interpreted as usual. ---short[=length]:: +--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` @@ -156,18 +167,30 @@ for another option. are not refs (i.e. branch or tag names; or more explicitly disambiguating "heads/master" form, when you want to name the "master" branch when there is an - unfortunately named tag "master"), and show them as full + unfortunately named tag "master"), and shows them as full refnames (e.g. "refs/heads/master"). +--output-object-format=(sha1|sha256|storage):: + + Allow oids to be input from any object format that the current + repository supports. + + Specifying "sha1" translates if necessary and returns a sha1 oid. + + Specifying "sha256" translates if necessary and returns a sha256 oid. + + Specifying "storage" translates if necessary and returns an oid in + encoded in the storage hash algorithm. + Options for Objects ~~~~~~~~~~~~~~~~~~~ --all:: Show all refs found in `refs/`. ---branches[=pattern]:: ---tags[=pattern]:: ---remotes[=pattern]:: +--branches[=<pattern>]:: +--tags[=<pattern>]:: +--remotes[=<pattern>]:: Show all branches, tags, or remote-tracking branches, respectively (i.e., refs found in `refs/heads`, `refs/tags`, or `refs/remotes`, respectively). @@ -176,7 +199,7 @@ If a `pattern` is given, only refs matching the given shell glob are shown. If the pattern does not contain a globbing character (`?`, `*`, or `[`), it is turned into a prefix match by appending `/*`. ---glob=pattern:: +--glob=<pattern>:: Show all refs matching the shell glob pattern `pattern`. If the pattern does not start with `refs/`, this is automatically prepended. If the pattern does not contain a globbing @@ -197,7 +220,7 @@ respectively, and they must begin with `refs/` when applied to `--glob` or `--all`. If a trailing '/{asterisk}' is intended, it must be given explicitly. ---exclude-hidden=[fetch|receive|uploadpack]:: +--exclude-hidden=(fetch|receive|uploadpack):: Do not include refs that would be hidden by `git-fetch`, `git-receive-pack` or `git-upload-pack` by consulting the appropriate `fetch.hideRefs`, `receive.hideRefs` or `uploadpack.hideRefs` @@ -307,21 +330,24 @@ The following options are unaffected by `--path-format`: input, multiple algorithms may be printed, space-separated. If not specified, the default is "storage". +--show-ref-format:: + Show the reference storage format used for the repository. + Other Options ~~~~~~~~~~~~~ ---since=datestring:: ---after=datestring:: +--since=<datestring>:: +--after=<datestring>:: Parse the date string, and output the corresponding --max-age= parameter for 'git rev-list'. ---until=datestring:: ---before=datestring:: +--until=<datestring>:: +--before=<datestring>:: Parse the date string, and output the corresponding --min-age= parameter for 'git rev-list'. -<args>...:: +<arg>...:: Flags and parameters to be parsed. @@ -383,7 +409,7 @@ Each line of options has this format: 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. +as the help associated with the option. Blank lines are ignored, and lines that don't match this specification are used as option group headers (start the line with a space to create such @@ -398,7 +424,7 @@ some-command [<options>] <args>... some-command does foo and bar! -- -h,help show the help +h,help! show the help foo some nifty option --foo bar= some cool option --bar with an argument @@ -424,10 +450,10 @@ 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 + --[no-]foo some nifty option --foo + --[no-]bar ... some cool option --bar with an argument + --[no-]baz <arg> another cool option --baz with a named argument + --[no-]qux[=<path>] qux may take a path argument but has meaning by itself An option group Header -C[...] option C with an optional argument diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt index d2e10d3dce..568925db53 100644 --- a/Documentation/git-revert.txt +++ b/Documentation/git-revert.txt @@ -116,7 +116,7 @@ include::rerere-options.txt[] --reference:: Instead of starting the body of the log message with "This - reverts <full object name of the commit being reverted>.", + reverts <full-object-name-of-the-commit-being-reverted>.", refer to the commit using "--pretty=reference" format (cf. linkgit:git-log[1]). The `revert.reference` configuration variable can be used to enable this option by @@ -142,6 +142,16 @@ EXAMPLES changes. The revert only modifies the working tree and the index. +DISCUSSION +---------- + +While git creates a basic commit message automatically, it is +_strongly_ recommended to explain why the original commit is being +reverted. +In addition, repeatedly reverting reverts will result in increasingly +unwieldy subject lines, for example 'Reapply "Reapply "<original-subject>""'. +Please consider rewording these to be shorter and more unique. + CONFIGURATION ------------- diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt index 81bc23f3cd..363a26934f 100644 --- a/Documentation/git-rm.txt +++ b/Documentation/git-rm.txt @@ -163,7 +163,7 @@ will be staged (unless --cached or -n are used). A submodule is considered up to date when the HEAD is the same as recorded in the index, no tracked files are modified and no untracked -files that aren't ignored are present in the submodules work tree. +files that aren't ignored are present in the submodule's work tree. Ignored files are deemed expendable and won't stop a submodule's work tree from being removed. diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 492a82323d..bc3ef45acb 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -9,9 +9,10 @@ git-send-email - Send a collection of patches as emails SYNOPSIS -------- [verse] -'git send-email' [<options>] <file|directory>... -'git send-email' [<options>] <format-patch options> +'git send-email' [<options>] (<file>|<directory>)... +'git send-email' [<options>] <format-patch-options> 'git send-email' --dump-aliases +'git send-email' --translate-aliases DESCRIPTION @@ -68,11 +69,12 @@ This option may be specified multiple times. Invoke a text editor (see GIT_EDITOR in linkgit:git-var[1]) to edit an introductory message for the patch series. + -When `--compose` is used, git send-email will use the From, Subject, and -In-Reply-To headers specified in the message. If the body of the message -(what you type after the headers and a blank line) only contains blank -(or Git: prefixed) lines, the summary won't be sent, but From, Subject, -and In-Reply-To headers will be used unless they are removed. +When `--compose` is used, git send-email will use the From, To, Cc, Bcc, +Subject, Reply-To, 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 the headers mentioned above will be used unless they are +removed. + Missing From or In-Reply-To headers will be prompted for. + @@ -137,7 +139,7 @@ Note that no attempts whatsoever are made to validate the encoding. --compose-encoding=<encoding>:: Specify encoding of compose message. Default is the value of the - 'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed. + '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. @@ -173,7 +175,7 @@ Sending Specify a command to run to send the email. The command should be sendmail-like; specifically, it must support the `-i` option. The command will be executed in the shell if necessary. Default - is the value of `sendemail.sendmailcmd`. If unspecified, and if + is the value of `sendemail.sendmailCmd`. If unspecified, and if --smtp-server is also unspecified, git-send-email will search for `sendmail` in `/usr/sbin`, `/usr/lib` and $PATH. @@ -268,7 +270,7 @@ must be used for each option. 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 + `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). @@ -277,7 +279,7 @@ must be used for each option. if a username is not specified (with `--smtp-user` or `sendemail.smtpUser`), then authentication is not attempted. ---smtp-debug=0|1:: +--smtp-debug=(0|1):: Enable (1) or disable (0) debug output. If enabled, SMTP commands and replies will be printed. Useful to debug TLS connection and authentication problems. @@ -300,7 +302,9 @@ must be used for each option. Automating ~~~~~~~~~~ ---no-[to|cc|bcc]:: +--no-to:: +--no-cc:: +--no-bcc:: Clears any list of "To:", "Cc:", "Bcc:" addresses previously set via config. @@ -312,7 +316,7 @@ Automating Specify a command to execute once per patch file which should generate patch file specific "To:" entries. Output of this command must be single email address per line. - Default is the value of 'sendemail.tocmd' configuration value. + Default is the value of 'sendemail.toCmd' configuration value. --cc-cmd=<command>:: Specify a command to execute once per patch file which @@ -347,19 +351,19 @@ Automating --[no-]signed-off-by-cc:: If this is set, add emails found in the `Signed-off-by` trailer 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' + 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' + 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>:: @@ -383,7 +387,7 @@ Automating - '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. @@ -410,6 +414,12 @@ exists when 'git send-email' is asked to add it (especially note that Failure to do so may not produce the expected result in the recipient's MUA. +--[no-]mailmap:: + Use the mailmap file (see linkgit:gitmailmap[5]) to map all + addresses to their canonical real name and email address. Additional + mailmap data specific to git-send-email may be provided using the + `sendemail.mailmap.file` or `sendemail.mailmap.blob` configuration + values. Defaults to `sendemail.mailmap`. Administering ~~~~~~~~~~~~~ @@ -453,7 +463,7 @@ have been specified, in which case default to 'compose'. 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. + https://www.ietf.org/rfc/rfc5322.txt. -- + Default is the value of `sendemail.validate`; if this is not set, @@ -468,10 +478,16 @@ 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. - + the configured alias file(s), one per line in alphabetical order. Note + that this only includes the alias name and not its expanded email addresses. + See 'sendemail.aliasesFile' for more information about aliases. + +--translate-aliases:: + Instead of the normal operation, read from standard input and + interpret each line as an email alias. Translate it according to the + configured alias file(s). Output each translated name and email + address to standard output, one per line. See 'sendemail.aliasFile' + for more information about aliases. CONFIGURATION ------------- diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt index 595b002152..b9e73f2e77 100644 --- a/Documentation/git-send-pack.txt +++ b/Documentation/git-send-pack.txt @@ -55,7 +55,7 @@ be in a separate packet, and the list must end with a flush packet. --force:: Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. - This flag disables the check. What this means is that + This flag disables the check. This means that the remote repository can lose commits; use it with care. @@ -106,7 +106,7 @@ 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 the `--all` flag, all refs that exist locally are transferred to the remote side. You cannot specify any '<ref>' if you use this flag. @@ -115,9 +115,9 @@ both on the local side and on the remote side are updated. When one or more '<ref>' are specified explicitly (whether on the command line or via `--stdin`), it can be either a -single pattern, or a pair of such pattern separated by a colon +single pattern, or a pair of such patterns separated by a colon ":" (this means that a ref name cannot have a colon in it). A -single pattern '<name>' is just a shorthand for '<name>:<name>'. +single pattern '<name>' is just shorthand for '<name>:<name>'. Each pattern pair consists of the source side (before the colon) and the destination side (after the colon). The ref to be @@ -130,7 +130,7 @@ name. See linkgit:git-rev-parse[1]. - It is an error if <src> does not match exactly one of the local refs. - - It is an error if <dst> matches more than one remote refs. + - It is an error if <dst> matches more than one remote ref. - If <dst> does not match any remote ref, either @@ -143,9 +143,9 @@ name. See linkgit:git-rev-parse[1]. 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. +ancestor) of <src>. This check, known as the "fast-forward check", +is performed to avoid accidentally overwriting the +remote ref and losing other people's commits from there. With `--force`, the fast-forward check is disabled for all refs. diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt index 8632612c31..bdaf6e5fc4 100644 --- a/Documentation/git-sh-setup.txt +++ b/Documentation/git-sh-setup.txt @@ -22,7 +22,7 @@ The 'git sh-setup' scriptlet is designed to be sourced (using the normal Git directories and a few helper shell functions. Before sourcing it, your script should set up a few variables; -`USAGE` (and `LONG_USAGE`, if any) is used to define message +`USAGE` (and `LONG_USAGE`, if any) is used to define the message given by `usage()` shell function. `SUBDIRECTORY_OK` can be set if the script can run from a subdirectory of the working tree (some commands do not). diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt index 58cf6210cd..bc31d8b6d3 100644 --- a/Documentation/git-show-branch.txt +++ b/Documentation/git-show-branch.txt @@ -22,7 +22,7 @@ Shows the commit ancestry graph starting from the commits named with <rev>s or <glob>s (or all refs under refs/heads and/or refs/tags) semi-visually. -It cannot show more than 29 branches and commits at a time. +It cannot show more than 26 branches and commits at a time. It uses `showbranch.default` multi-valued configuration items if no <rev> or <glob> is given on the command line. @@ -50,7 +50,7 @@ OPTIONS --current:: With this option, the command includes the current - branch to the list of revs to be shown when it is not + branch in the list of revs to be shown when it is not given on the command line. --topo-order:: @@ -125,7 +125,7 @@ OPTIONS default to color output. Same as `--color=never`. -Note that --more, --list, --independent and --merge-base options +Note that --more, --list, --independent, and --merge-base options are mutually exclusive. @@ -137,14 +137,14 @@ their commit message. The branch head that is pointed at by $GIT_DIR/HEAD is prefixed with an asterisk `*` character while other heads are prefixed with a `!` character. -Following these N lines, one-line log for each commit is +Following these N lines, a one-line log for each commit is displayed, indented N places. If a commit is on the I-th branch, the I-th indentation character shows a `+` sign; otherwise it shows a space. Merge commits are denoted by a `-` sign. Each commit shows a short name that can be used as an extended SHA-1 to name that commit. -The following example shows three branches, "master", "fixes" +The following example shows three branches, "master", "fixes", and "mhf": ------------------------------------------------ @@ -154,7 +154,7 @@ $ git show-branch master fixes mhf ! [mhf] Allow "+remote:local" refspec to cause --force when fetching. --- + [mhf] Allow "+remote:local" refspec to cause --force when fetching. - + [mhf~1] Use git-octopus when pulling more than one heads. + + [mhf~1] Use git-octopus when pulling more than one head. + [fixes] Introduce "reset type" flag to "git reset" + [mhf~2] "git fetch --force". + [mhf~3] Use .git/remote/origin, not .git/branches/origin. @@ -197,7 +197,7 @@ $ git show-branch --reflog="10,1 hour ago" --list master shows 10 reflog entries going back from the tip as of 1 hour ago. Without `--list`, the output also shows how these tips are -topologically related with each other. +topologically related to each other. CONFIGURATION ------------- diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt index 2fe274b8fa..616d919655 100644 --- a/Documentation/git-show-ref.txt +++ b/Documentation/git-show-ref.txt @@ -8,10 +8,14 @@ git-show-ref - List references in a local repository SYNOPSIS -------- [verse] -'git show-ref' [-q | --quiet] [--verify] [--head] [-d | --dereference] - [-s | --hash[=<n>]] [--abbrev[=<n>]] [--tags] - [--heads] [--] [<pattern>...] +'git show-ref' [--head] [-d | --dereference] + [-s | --hash[=<n>]] [--abbrev[=<n>]] [--branches] [--tags] + [--] [<pattern>...] +'git show-ref' --verify [-q | --quiet] [-d | --dereference] + [-s | --hash[=<n>]] [--abbrev[=<n>]] + [--] [<ref>...] 'git show-ref' --exclude-existing[=<pattern>] +'git show-ref' --exists <ref> DESCRIPTION ----------- @@ -27,6 +31,10 @@ 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. +The `--exists` form can be used to check for the existence of a single +references. This form does not verify whether the reference resolves to an +actual object. + Use of this utility is encouraged in favor of directly accessing files under the `.git` directory. @@ -37,12 +45,14 @@ OPTIONS Show the HEAD reference, even if it would normally be filtered out. ---heads:: +--branches:: --tags:: - Limit to "refs/heads" and "refs/tags", respectively. These options + Limit to local branches and local tags, respectively. These options are not mutually exclusive; when given both, references stored in - "refs/heads" and "refs/tags" are displayed. + "refs/heads" and "refs/tags" are displayed. Note that `--heads` + is a deprecated synonym for `--branches` and may be removed + in the future. -d:: --dereference:: @@ -62,6 +72,12 @@ OPTIONS Aside from returning an error code of 1, it will also print an error message if `--quiet` was not specified. +--exists:: + + Check whether the given reference exists. Returns an exit code of 0 if + it does, 2 if it is missing, and 1 in case looking up the reference + failed with an error other than the reference being missing. + --abbrev[=<n>]:: Abbreviate the object name. When using `--hash`, you do @@ -70,8 +86,8 @@ OPTIONS -q:: --quiet:: - Do not print any results to stdout. When combined with `--verify`, this - can be used to silently check if a reference exists. + Do not print any results to stdout. Can be used with `--verify` to + silently check if a reference exists. --exclude-existing[=<pattern>]:: @@ -125,7 +141,7 @@ When using `--hash` (and not `--dereference`), the output is in the format: For example, ----------------------------------------------------------------------------- -$ git show-ref --heads --hash +$ git show-ref --branches --hash 2e3ba0114a1f52b47df29743d6915d056be13278 185008ae97960c8d551adcd9e23565194651b5d1 03adf42c988195b50e1a1935ba5fcbc39b2b029b @@ -144,7 +160,7 @@ use: ----------------------------------------------------------------------------- This will show "refs/heads/master" but also "refs/remote/other-repo/master", -if such references exists. +if such references exist. When using the `--verify` flag, the command requires an exact path: @@ -169,8 +185,8 @@ to check whether a particular branch exists or not (notice how we don't actually want to show any results, and we want to use the full refname for it in order to not trigger the problem with ambiguous partial matches). -To show only tags, or only proper branch heads, use `--tags` and/or `--heads` -respectively (using both means that it shows tags and heads, but not other +To show only tags, or only proper branch heads, use `--tags` and/or `--branches` +respectively (using both means that it shows tags and branches, but not other random references under the refs/ subdirectory). To do automatic tag object dereferencing, use the `-d` or `--dereference` diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt index 03c0634518..5eb67439af 100644 --- a/Documentation/git-show.txt +++ b/Documentation/git-show.txt @@ -61,7 +61,7 @@ EXAMPLES -------- `git show v1.0.0`:: - Shows the tag `v1.0.0`, along with the object the tags + Shows the tag `v1.0.0`, along with the object the tag points at. `git show v1.0.0^{tree}`:: diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index a051b1e8f3..9a376886a5 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -79,6 +79,8 @@ 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. +All usual spellings for Boolean value `true` are taken as `normal` +and `false` as `no`. The default can be changed using the status.showUntrackedFiles configuration variable documented in linkgit:git-config[1]. @@ -245,11 +247,12 @@ U U unmerged, both modified .... 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 + +* 'M' = the submodule has a different HEAD than recorded in the index +* 'm' = the submodule has modified content +* '?' = the submodule has untracked files + +This is 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 @@ -308,7 +311,7 @@ Line Notes ------------------------------------------------------------ # branch.oid <commit> | (initial) Current commit. # branch.head <branch> | (detached) Current branch. -# branch.upstream <upstream_branch> If upstream is set. +# branch.upstream <upstream-branch> If upstream is set. # branch.ab +<ahead> -<behind> If upstream is set and the commit is present. ------------------------------------------------------------ @@ -471,7 +474,7 @@ again, because your configuration may already be caching `git status` results, so it could be faster on subsequent runs. * The `--untracked-files=no` flag or the - `status.showUntrackedfiles=false` config (see above for both): + `status.showUntrackedFiles=no` config (see above for both): indicate that `git status` should not report untracked files. This is the fastest option. `git status` will not list the untracked files, so you need to be careful to remember if @@ -501,7 +504,7 @@ results, so it could be faster on subsequent runs. usually worth the additional size. * `core.untrackedCache=true` and `core.fsmonitor=true` or - `core.fsmonitor=<hook_command_pathname>` (see + `core.fsmonitor=<hook-command-pathname>` (see linkgit:git-update-index[1]): enable both the untracked cache and FSMonitor features and only search directories that have been modified since the previous `git status` command. This diff --git a/Documentation/git-stripspace.txt b/Documentation/git-stripspace.txt index 2438f76da0..a293327581 100644 --- a/Documentation/git-stripspace.txt +++ b/Documentation/git-stripspace.txt @@ -29,7 +29,7 @@ With no arguments, this will: In the case where the input consists entirely of whitespace characters, no output will be produced. -*NOTE*: This is intended for cleaning metadata, prefer the `--whitespace=fix` +*NOTE*: This is intended for cleaning metadata. Prefer the `--whitespace=fix` mode of linkgit:git-apply[1] for correcting whitespace of patches or files in the repository. @@ -37,11 +37,11 @@ OPTIONS ------- -s:: --strip-comments:: - Skip and remove all lines starting with comment character (default '#'). + Skip and remove all lines starting with a comment character (default '#'). -c:: --comment-lines:: - Prepend comment character and blank to each line. Lines will automatically + Prepend the comment character and a blank space to each line. Lines will automatically be terminated with a newline. On empty lines, only the comment character will be prepended. diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 695730609a..87d8e0f0c5 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -34,7 +34,7 @@ COMMANDS With no arguments, shows the status of existing submodules. Several subcommands are available to perform operations on the submodules. -add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]:: +add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--ref-format <format>] [--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". @@ -71,6 +71,9 @@ 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`. ++ +If `--ref-format <format>` is specified, the ref storage format of newly +cloned submodules will be set accordingly. status [--cached] [--recursive] [--] [<path>...]:: Show the status of the submodules. This will print the SHA-1 of the @@ -136,7 +139,7 @@ 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] [--filter <filter spec>] [--] [<path>...]:: +update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--ref-format <format>] [--depth <depth>] [--recursive] [--jobs <n>] [--[no-]single-branch] [--filter <filter-spec>] [--] [<path>...]:: + -- Update the registered submodules to match what the superproject @@ -185,7 +188,10 @@ submodule with the `--init` option. If `--recursive` is specified, this command will recurse into the registered submodules, and update any nested submodules within. -If `--filter <filter spec>` is specified, the given partial clone filter will be +If `--ref-format <format>` is specified, the ref storage format of newly +cloned submodules will be set accordingly. + +If `--filter <filter-spec>` is specified, the given partial clone filter will be applied to the submodule. See linkgit:git-rev-list[1] for details on filter specifications. -- diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 4e92308e85..bcf7d84a87 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -37,12 +37,12 @@ COMMANDS argument. Normally this command initializes the current directory. --T<trunk_subdir>;; ---trunk=<trunk_subdir>;; --t<tags_subdir>;; ---tags=<tags_subdir>;; --b<branches_subdir>;; ---branches=<branches_subdir>;; +-T<trunk-subdir>;; +--trunk=<trunk-subdir>;; +-t<tags-subdir>;; +--tags=<tags-subdir>;; +-b<branches-subdir>;; +--branches=<branches-subdir>;; -s;; --stdlayout;; These are optional command-line options for init. Each of @@ -431,14 +431,14 @@ Any other arguments are passed directly to 'git log' independently of 'git svn' functions. 'create-ignore':: - Recursively finds the svn:ignore property on directories and - creates matching .gitignore files. The resulting files are staged to - be committed, but are not committed. Use -r/--revision to refer to a - specific revision. + Recursively finds the svn:ignore and svn:global-ignores properties + on directories and creates matching .gitignore files. The resulting + files are staged to be committed, but are not committed. Use + -r/--revision to refer to a specific revision. 'show-ignore':: - Recursively finds and lists the svn:ignore property on - directories. The output is suitable for appending to + Recursively finds and lists the svn:ignore and svn:global-ignores + properties on directories. The output is suitable for appending to the $GIT_DIR/info/exclude file. 'mkdirs':: @@ -726,9 +726,9 @@ ADVANCED OPTIONS when tracking a single URL. The 'log' and 'dcommit' commands no longer require this switch as an argument. --R<remote name>:: ---svn-remote <remote name>:: - Specify the [svn-remote "<remote name>"] section to use, +-R<remote-name>:: +--svn-remote <remote-name>:: + Specify the [svn-remote "<remote-name>"] section to use, this allows SVN multiple repositories to be tracked. Default: "svn" @@ -871,7 +871,7 @@ Tracking and contributing to the trunk of a Subversion-managed project # Now commit your changes (that were committed previously using Git) to SVN, # as well as automatically updating your working HEAD: git svn dcommit -# Append svn:ignore settings to the default Git exclude file: +# Append svn:ignore and svn:global-ignores settings to the default Git exclude file: git svn show-ignore >> .git/info/exclude ------------------------------------------------------------------------ diff --git a/Documentation/git-switch.txt b/Documentation/git-switch.txt index c60fc9c138..f38e4c8afa 100644 --- a/Documentation/git-switch.txt +++ b/Documentation/git-switch.txt @@ -59,13 +59,18 @@ 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: + `<start-point>` before switching to the branch. This is the + transactional equivalent of + ------------ $ git branch <new-branch> $ git switch <new-branch> ------------ ++ +that is to say, the branch is not reset/created unless "git switch" is +successful (e.g., when the branch is in use in another worktree, not +just the current branch stays the same, but the branch is not reset to +the start-point, either). -C <new-branch>:: --force-create <new-branch>:: @@ -171,7 +176,7 @@ name, the guessing is aborted. You can explicitly give a name with `branch.autoSetupMerge` configuration variable is true. --orphan <new-branch>:: - Create a new 'orphan' branch, named `<new-branch>`. All + Create a new unborn branch, named `<new-branch>`. All tracked files are removed. --ignore-other-worktrees:: diff --git a/Documentation/git-symbolic-ref.txt b/Documentation/git-symbolic-ref.txt index 102c83eb19..33ca381fde 100644 --- a/Documentation/git-symbolic-ref.txt +++ b/Documentation/git-symbolic-ref.txt @@ -27,7 +27,7 @@ symbolic ref. A symbolic ref is a regular file that stores a string that begins with `ref: refs/`. For example, your `.git/HEAD` is -a regular file whose contents is `ref: refs/heads/master`. +a regular file whose content is `ref: refs/heads/master`. OPTIONS ------- @@ -73,6 +73,10 @@ default. symbolic ref were printed correctly, with status 1 if the requested name is not a symbolic ref, or 128 if another error occurs. +SEE ALSO +-------- +linkgit:git-update-ref[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index d42efb3112..4494729f5e 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -10,6 +10,7 @@ SYNOPSIS -------- [verse] 'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e] + [(--trailer <token>[(=|:)<value>])...] <tagname> [<commit> | <object>] 'git tag' -d <tagname>... 'git tag' [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>] @@ -31,8 +32,8 @@ 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>` -are absent, `-a` is implied. +If `-m <msg>` or `-F <file>` or `--trailer <token>[=<value>]` is given +and `-a`, `-s`, and `-u <key-id>` are absent, `-a` is implied. Otherwise, a tag reference that points directly at the given object (i.e., a lightweight tag) is created. @@ -178,6 +179,17 @@ This option is only applicable when listing tags without annotation lines. Implies `-a` if none of `-a`, `-s`, or `-u <key-id>` is given. +--trailer <token>[(=|:)<value>]:: + Specify a (<token>, <value>) pair that should be applied as a + trailer. (e.g. `git tag --trailer "Custom-Key: value"` + will add a "Custom-Key" trailer to the tag message.) + The `trailer.*` configuration variables + (linkgit:git-interpret-trailers[1]) can be used to define if + a duplicated trailer is omitted, where in the run of trailers + each trailer would appear, and other details. + The trailers can be extracted in `git tag --list`, using + `--format="%(trailers)"` placeholder. + -e:: --edit:: The message taken from file with `-F` and command line with @@ -224,7 +236,7 @@ it in the repository configuration as follows: ------------------------------------- [user] - signingKey = <gpg-key_id> + signingKey = <gpg-key-id> ------------------------------------- `pager.tag` is only respected when listing tags, i.e., when `-l` is diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index f4bb9c5daf..7128aed540 100644 --- a/Documentation/git-update-index.txt +++ b/Documentation/git-update-index.txt @@ -25,6 +25,7 @@ SYNOPSIS [--really-refresh] [--unresolve] [--again | -g] [--info-only] [--index-info] [-z] [--stdin] [--index-version <n>] + [--show-index-version] [--verbose] [--] [<file>...] @@ -49,7 +50,7 @@ OPTIONS --remove:: If a specified file is in the index but is missing then it's removed. - Default behavior is to ignore removed file. + Default behavior is to ignore removed files. --refresh:: Looks at the current index and checks to see if merges or @@ -95,7 +96,7 @@ OPTIONS 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 + filesystem that has a very slow lstat(2) system call (e.g. cifs). + Git will fail (gracefully) in case it needs to modify this file @@ -108,7 +109,7 @@ you will need to handle the situation manually. without regard to the "assume unchanged" setting. --[no-]skip-worktree:: - When one of these flags is specified, the object name recorded + When one of these flags is specified, the object names recorded for the paths are not updated. Instead, these options set and unset the "skip-worktree" bit for the paths. See section "Skip-worktree bit" below for more information. @@ -119,7 +120,7 @@ you will need to handle the situation manually. the `--remove` option was specified. --[no-]fsmonitor-valid:: - When one of these flags is specified, the object name recorded + When one of these flags is specified, the object names 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. @@ -127,7 +128,7 @@ you will need to handle the situation manually. -g:: --again:: Runs 'git update-index' itself on the paths whose index - entries are different from those from the `HEAD` commit. + entries are different from those of the `HEAD` commit. --unresolve:: Restores the 'unmerged' or 'needs updating' state of a @@ -151,24 +152,30 @@ you will need to handle the situation manually. automatically removed with warning messages. --stdin:: - Instead of taking list of paths from the command line, - read list of paths from the standard input. Paths are + Instead of taking a list of paths from the command line, + read a list of paths from the standard input. Paths are separated by LF (i.e. one path per line) by default. --verbose:: - Report what is being added and removed from index. + Report what is being added and removed from the index. --index-version <n>:: Write the resulting index out in the named on-disk format version. - Supported versions are 2, 3 and 4. The current default version is 2 + Supported versions are 2, 3, and 4. The current default version is 2 or 3, depending on whether extra features are used, such as - `git add -N`. + `git add -N`. With `--verbose`, also report the version the index + file uses before and after this command. + Version 4 performs a simple pathname compression that reduces index size by 30%-50% on large repositories, which results in faster load -time. Version 4 is relatively young (first released in 1.8.0 in -October 2012). Other Git implementations such as JGit and libgit2 -may not support it yet. +time. Git supports it since version 1.8.0, released in October 2012, +and support for it was added to libgit2 in 2016 and to JGit in 2020. +Older versions of this manual page called it "relatively young", but +it should be considered mature technology these days. + +--show-index-version:: + Report the index format version used by the on-disk index file. + See `--index-version` above. -z:: Only meaningful with `--stdin` or `--index-info`; paths are diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt index 48b6683071..8a4281cde9 100644 --- a/Documentation/git-update-ref.txt +++ b/Documentation/git-update-ref.txt @@ -8,63 +8,46 @@ git-update-ref - Update the object name stored in a ref safely SYNOPSIS -------- [verse] -'git update-ref' [-m <reason>] [--no-deref] (-d <ref> [<oldvalue>] | [--create-reflog] <ref> <newvalue> [<oldvalue>] | --stdin [-z]) +'git update-ref' [-m <reason>] [--no-deref] (-d <ref> [<old-oid>] | [--create-reflog] <ref> <new-oid> [<old-oid>] | --stdin [-z]) DESCRIPTION ----------- -Given two arguments, stores the <newvalue> in the <ref>, possibly +Given two arguments, stores the <new-oid> in the <ref>, possibly dereferencing the symbolic refs. E.g. `git update-ref HEAD -<newvalue>` updates the current branch head to the new object. +<new-oid>` updates the current branch head to the new object. -Given three arguments, stores the <newvalue> in the <ref>, +Given three arguments, stores the <new-oid> in the <ref>, possibly dereferencing the symbolic refs, after verifying that -the current value of the <ref> matches <oldvalue>. -E.g. `git update-ref refs/heads/master <newvalue> <oldvalue>` -updates the master branch head to <newvalue> only if its current -value is <oldvalue>. You can specify 40 "0" or an empty string -as <oldvalue> to make sure that the ref you are creating does +the current value of the <ref> matches <old-oid>. +E.g. `git update-ref refs/heads/master <new-oid> <old-oid>` +updates the master branch head to <new-oid> only if its current +value is <old-oid>. You can specify 40 "0" or an empty string +as <old-oid> to make sure that the ref you are creating does not exist. -It also allows a "ref" file to be a symbolic pointer to another -ref file by starting with the four-byte header sequence of -"ref:". - -More importantly, it allows the update of a ref file to follow -these symbolic pointers, whether they are symlinks or these -"regular file symbolic refs". It follows *real* symlinks only -if they start with "refs/": otherwise it will just try to read -them and update them as a regular file (i.e. it will allow the -filesystem to follow them, but will overwrite such a symlink to -somewhere else with a regular filename). +The final arguments are object names; this command without any options +does not support updating a symbolic ref to point to another ref (see +linkgit:git-symbolic-ref[1]). But `git update-ref --stdin` does have +the `symref-*` commands so that regular refs and symbolic refs can be +committed in the same transaction. If --no-deref is given, <ref> itself is overwritten, rather than the result of following the symbolic pointers. -In general, using - - git update-ref HEAD "$head" - -should be a _lot_ safer than doing - - echo "$head" > "$GIT_DIR/HEAD" - -both from a symlink following standpoint *and* an error checking -standpoint. The "refs/" rule for symlinks means that symlinks -that point to "outside" the tree are safe: they'll be followed -for reading but not for writing (so we'll never write through a -ref symlink to some other tree, if you have copied a whole -archive by creating a symlink tree). - -With `-d` flag, it deletes the named <ref> after verifying it -still contains <oldvalue>. +With `-d`, it deletes the named <ref> after verifying that it +still contains <old-oid>. With `--stdin`, update-ref reads instructions from standard input and performs all modifications together. Specify commands of the form: - update SP <ref> SP <newvalue> [SP <oldvalue>] LF - create SP <ref> SP <newvalue> LF - delete SP <ref> [SP <oldvalue>] LF - verify SP <ref> [SP <oldvalue>] LF + update SP <ref> SP <new-oid> [SP <old-oid>] LF + create SP <ref> SP <new-oid> LF + delete SP <ref> [SP <old-oid>] LF + verify SP <ref> [SP <old-oid>] LF + symref-update SP <ref> SP <new-target> [SP (ref SP <old-target> | oid SP <old-oid>)] LF + symref-create SP <ref> SP <new-target> LF + symref-delete SP <ref> [SP <old-target>] LF + symref-verify SP <ref> [SP <old-target>] LF option SP <opt> LF start LF prepare LF @@ -82,10 +65,14 @@ 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 + update SP <ref> NUL <new-oid> NUL [<old-oid>] NUL + create SP <ref> NUL <new-oid> NUL + delete SP <ref> NUL [<old-oid>] NUL + verify SP <ref> NUL [<old-oid>] NUL + symref-update SP <ref> NUL <new-target> [NUL (ref NUL <old-target> | oid NUL <old-oid>)] NUL + symref-create SP <ref> NUL <new-target> NUL + symref-delete SP <ref> [NUL <old-target>] NUL + symref-verify SP <ref> [NUL <old-target>] NUL option SP <opt> NUL start NUL prepare NUL @@ -100,25 +87,42 @@ recognizes as an object name. Commands in any other format or a repeated <ref> produce an error. Command meanings are: update:: - Set <ref> to <newvalue> after verifying <oldvalue>, if given. - Specify a zero <newvalue> to ensure the ref does not exist - after the update and/or a zero <oldvalue> to make sure the + Set <ref> to <new-oid> after verifying <old-oid>, if given. + Specify a zero <new-oid> to ensure the ref does not exist + after the update and/or a zero <old-oid> to make sure the ref does not exist before the update. create:: - Create <ref> with <newvalue> after verifying it does not - exist. The given <newvalue> may not be zero. + Create <ref> with <new-oid> after verifying it does not + exist. The given <new-oid> may not be zero. delete:: - Delete <ref> after verifying it exists with <oldvalue>, if - given. If given, <oldvalue> may not be zero. + Delete <ref> after verifying it exists with <old-oid>, if + given. If given, <old-oid> may not be zero. + +symref-update:: + Set <ref> to <new-target> after verifying <old-target> or <old-oid>, + if given. Specify a zero <old-oid> to ensure that the ref does not + exist before the update. verify:: - Verify <ref> against <oldvalue> but do not change it. If - <oldvalue> is zero or missing, the ref must not exist. + Verify <ref> against <old-oid> but do not change it. If + <old-oid> is zero or missing, the ref must not exist. + +symref-create: + Create symbolic ref <ref> with <new-target> after verifying + it does not exist. + +symref-delete:: + Delete <ref> after verifying it exists with <old-target>, if given. + +symref-verify:: + Verify symbolic <ref> against <old-target> but do not change it. + If <old-target> is missing, the ref must not exist. Can only be + used in `no-deref` mode. option:: - Modify behavior of the next command naming a <ref>. + Modify the behavior of the next command naming a <ref>. The only valid option is `no-deref` to avoid dereferencing a symbolic ref. @@ -141,7 +145,7 @@ 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 +If all <ref>s can be locked with matching <old-oid>s simultaneously, all modifications are performed. Otherwise, no modifications are performed. Note that while each individual <ref> is updated or deleted atomically, a concurrent reader may @@ -161,7 +165,7 @@ formatted as: 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 +<new-oid> and "committer" is the committer's name, email address and date in the standard Git committer ident format. Optionally with -m: @@ -175,6 +179,21 @@ An update will fail (without changing <ref>) if the current user is unable to create a new log file, append to the existing log file or does not have committer information available. +NOTES +----- + +Symbolic refs were initially implemented using symbolic links. This is +now deprecated since not all filesystems support symbolic links. + +This command follows *real* symlinks only if they start with "refs/": +otherwise it will just try to read them and update them as a regular +file (i.e. it will allow the filesystem to follow them, but will +overwrite such a symlink to somewhere else with a regular filename). + +SEE ALSO +-------- +linkgit:git-symbolic-ref[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt index 17e429dbd0..6bc9b50d89 100644 --- a/Documentation/git-update-server-info.txt +++ b/Documentation/git-update-server-info.txt @@ -23,13 +23,13 @@ OPTIONS ------- -f:: --force:: - update the info files from scratch. + Update the info files from scratch. OUTPUT ------ Currently the command updates the following files. Please see -linkgit:gitrepository-layout[5] for description of +linkgit:gitrepository-layout[5] for a description of what they are for: * objects/info/packs diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt index 1d30a4f6b4..516d1639d9 100644 --- a/Documentation/git-upload-pack.txt +++ b/Documentation/git-upload-pack.txt @@ -26,7 +26,7 @@ OPTIONS ------- --[no-]strict:: - Do not try <directory>/.git/ if <directory> is no Git directory. + Do not try <directory>/.git/ if <directory> is not a Git directory. --timeout=<n>:: Interrupt transfer after <n> seconds of inactivity. diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt index c38fb3968b..0680568dfd 100644 --- a/Documentation/git-var.txt +++ b/Documentation/git-var.txt @@ -19,7 +19,7 @@ no value. OPTIONS ------- -l:: - Cause the logical variables to be listed. In addition, all the + Display the logical variables. In addition, all the variables of the Git configuration file .git/config are listed as well. (However, the configuration variables listing functionality is deprecated in favor of `git config -l`.) diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt index b8720dce8a..d7e886918a 100644 --- a/Documentation/git-verify-pack.txt +++ b/Documentation/git-verify-pack.txt @@ -15,7 +15,7 @@ SYNOPSIS DESCRIPTION ----------- Reads given idx file for packed Git archive created with the -'git pack-objects' command and verifies idx file and the +'git pack-objects' command and verifies the idx file and the corresponding pack file. OPTIONS @@ -25,13 +25,13 @@ OPTIONS -v:: --verbose:: - After verifying the pack, show list of objects contained + After verifying the pack, show the list of objects contained in the pack and a histogram of delta chain length. -s:: --stat-only:: Do not verify the pack contents; only show the histogram of delta - chain length. With `--verbose`, list of objects is also shown. + chain length. With `--verbose`, the list of objects is also shown. \--:: Do not interpret any more arguments as options. diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt index 8b63ceb00e..8e55e0bb1e 100644 --- a/Documentation/git-whatchanged.txt +++ b/Documentation/git-whatchanged.txt @@ -3,7 +3,7 @@ git-whatchanged(1) NAME ---- -git-whatchanged - Show logs with difference each commit introduces +git-whatchanged - Show logs with differences each commit introduces SYNOPSIS @@ -18,11 +18,11 @@ Shows commit logs and diff output each commit introduces. New users are encouraged to use linkgit:git-log[1] instead. The `whatchanged` command is essentially the same as linkgit:git-log[1] -but defaults to show the raw format diff output and to skip merges. +but defaults to showing the raw format diff output and skipping merges. -The command is kept primarily for historical reasons; fingers of +The command is primarily kept for historical reasons; fingers of many people who learned Git long before `git log` was invented by -reading Linux kernel mailing list are trained to type it. +reading the Linux kernel mailing list are trained to type it. Examples diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt index 93d76f5d66..70437c815f 100644 --- a/Documentation/git-worktree.txt +++ b/Documentation/git-worktree.txt @@ -99,7 +99,7 @@ command will refuse to create the worktree (unless `--force` is used). If `<commit-ish>` is omitted, neither `--detach`, or `--orphan` is used, and there are no valid local branches (or remote branches if `--guess-remote` is specified) then, as a convenience, the new worktree is -associated with a new orphan branch named `<branch>` (after +associated with a new unborn branch named `<branch>` (after `$(basename <path>)` if neither `-b` or `-B` is used) as if `--orphan` was passed to the command. In the event the repository has a remote and `--guess-remote` is used, but no remote or local branches exist, then the @@ -157,7 +157,7 @@ will reestablish the connection. If multiple linked worktrees are moved, running `repair` from any worktree with each tree's new `<path>` as an argument, will reestablish the connection to all the specified paths. + -If both the main worktree and linked worktrees have been moved manually, +If both the main worktree and linked worktrees have been moved or copied manually, then running `repair` in the main worktree and specifying the new `<path>` of each linked worktree will reestablish all connections in both directions. @@ -234,7 +234,7 @@ This can also be set up as the default behaviour by using the --orphan:: With `add`, make the new worktree and index empty, associating - the worktree with a new orphan/unborn branch named `<new-branch>`. + the worktree with a new unborn branch named `<new-branch>`. --porcelain:: With `list`, output in an easy-to-parse format for scripts. diff --git a/Documentation/git.txt b/Documentation/git.txt index 14ed05116b..d15a869762 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -11,9 +11,10 @@ SYNOPSIS [verse] 'git' [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] - [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare] - [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] - [--config-env=<name>=<envvar>] <command> [<args>] + [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch] + [--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>] + [--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>] + <command> [<args>] DESCRIPTION ----------- @@ -96,9 +97,9 @@ foo.bar= ...`) sets `foo.bar` to the empty string which `git config to avoid ambiguity with `<name>` containing one. + This is useful for cases where you want to pass transitory -configuration options to git, but are doing so on OS's where -other processes might be able to read your cmdline -(e.g. `/proc/self/cmdline`), but not your environ +configuration options to git, but are doing so on operating systems +where other processes might be able to read your command line +(e.g. `/proc/self/cmdline`), but not your environment (e.g. `/proc/self/environ`). That behavior is the default on Linux, but may not be on your system. + @@ -174,8 +175,24 @@ If you just want to run git as if it was started in `<path>` then use directory. --no-replace-objects:: - Do not use replacement refs to replace Git objects. See - linkgit:git-replace[1] for more information. + Do not use replacement refs to replace Git objects. + This is equivalent to exporting the `GIT_NO_REPLACE_OBJECTS` + environment variable with any value. + See linkgit:git-replace[1] for more information. + +--no-lazy-fetch:: + Do not fetch missing objects from the promisor remote on + demand. Useful together with `git cat-file -e <object>` to + see if the object is locally available. + This is equivalent to setting the `GIT_NO_LAZY_FETCH` + 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`. + +--no-advice:: + Disable all advice hints from being printed. --literal-pathspecs:: Treat pathspecs literally (i.e. no globbing, no pathspec magic). @@ -198,11 +215,7 @@ If you just want to run git as if it was started in `<path>` then use 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-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 @@ -556,6 +569,11 @@ double-quotes and respecting backslash escapes. E.g., the value is always used. The default is "sha1". See `--object-format` in linkgit:git-init[1]. +`GIT_DEFAULT_REF_FORMAT`:: + If this variable is set, the default reference backend format for new + repositories will be set to this value. The default is "files". + See `--ref-format` in linkgit:git-init[1]. + Git Commits ~~~~~~~~~~~ `GIT_AUTHOR_NAME`:: @@ -626,6 +644,16 @@ 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_EXTERNAL_DIFF_TRUST_EXIT_CODE`:: + If this Boolean environment variable is set to true then the + `GIT_EXTERNAL_DIFF` command is expected to return exit code + 0 if it considers the input files to be equal or 1 if it + considers them to be different, like `diff(1)`. + If it is set to false, which is the default, then the command + is expected to return exit code 0 regardless of equality. + Any other exit code causes Git to report a fatal error. + + `GIT_DIFF_PATH_COUNTER`:: A 1-based counter incremented by one for every path. @@ -724,13 +752,12 @@ for further details. waiting for someone with sufficient permissions to fix it. `GIT_FLUSH`:: -// NEEDSWORK: make it into a usual Boolean environment variable - If this environment variable is set to "1", then commands such + If this Boolean environment variable is set to true, then commands such as 'git blame' (in incremental mode), 'git rev-list', 'git log', 'git check-attr' and 'git check-ignore' will force a flush of the output stream after each record have been flushed. If this - variable is set to "0", the output of these commands will be done + variable is set to false, the output of these commands will be done using completely buffered I/O. If this environment variable is not set, Git will choose buffered or record-oriented flushing based on whether stdout appears to be redirected to a file or not. @@ -838,7 +865,7 @@ 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 +`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`. + @@ -868,6 +895,10 @@ for full details. header and packfile URIs. Set this Boolean environment variable to false to prevent this redaction. +`GIT_NO_REPLACE_OBJECTS`:: + Setting and exporting this environment variable tells Git to + ignore replacement refs and do not replace Git objects. + `GIT_LITERAL_PATHSPECS`:: Setting this Boolean environment variable to true will cause Git to treat all pathspecs literally, rather than as glob patterns. For example, @@ -889,6 +920,11 @@ for full details. Setting this Boolean environment variable to true will cause Git to treat all pathspecs as case-insensitive. +`GIT_NO_LAZY_FETCH`:: + Setting this Boolean environment variable to true tells Git + not to lazily fetch missing objects from the promisor remote + on demand. + `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 @@ -911,6 +947,16 @@ for full details. should not normally need to set this to `0`, but it may be useful when trying to salvage data from a corrupted repository. +`GIT_COMMIT_GRAPH_PARANOIA`:: + When loading a commit object from the commit-graph, Git performs an + existence check on the object in the object database. This is done to + avoid issues with stale commit-graphs that contain references to + already-deleted commits, but comes with a performance penalty. ++ +The default is "false", which disables the aforementioned behavior. +Setting this to "true" enables the existence check so that stale commits +will never be returned from the commit-graph at the cost of performance. + `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 @@ -928,7 +974,7 @@ for full 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 + '<key>[=<value>]'. Presence of unknown keys and values must be ignored. + Note that servers may need to be configured to allow this variable to @@ -981,6 +1027,17 @@ standard output. adequate and support for it is likely to be removed in the foreseeable future (along with the variable). +`GIT_ADVICE`:: + If set to `0`, then disable all advice messages. These messages are + intended to provide hints to human users that may help them get out of + problematic situations or take advantage of new features. Users can + disable individual messages using the `advice.*` config keys. These + messages may be disruptive to tools that execute Git processes, so this + variable is available to disable the messages. (The `--no-advice` + global option is also available, but old Git versions may fail when + this option is not understood. The environment variable will be ignored + by Git versions that do not understand it.) + Discussion[[Discussion]] ------------------------ @@ -1015,10 +1072,11 @@ When first created, objects are stored in individual files, but for efficiency may later be compressed together into "pack files". Named pointers called refs mark interesting points in history. A ref -may contain the SHA-1 name of an object or the name of another ref. Refs -with names beginning `ref/head/` contain the SHA-1 name of the most +may contain the SHA-1 name of an object or the name of another ref (the +latter is called a "symbolic ref"). +Refs with names beginning `refs/head/` contain the SHA-1 name of the most recent commit (or "head") of a branch under development. SHA-1 names of -tags of interest are stored under `ref/tags/`. A special ref named +tags of interest are stored under `refs/tags/`. A symbolic ref named `HEAD` contains the name of the currently checked-out branch. The index file is initialized with a list of all paths and, for each @@ -1092,7 +1150,7 @@ Authors ------- Git was started by Linus Torvalds, and is currently maintained by Junio C Hamano. Numerous contributions have come from the Git mailing list -<git@vger.kernel.org>. http://www.openhub.net/p/git/contributors/summary +<git@vger.kernel.org>. https://openhub.net/p/git/contributors/summary gives you a more complete list of contributors. If you have a clone of git.git itself, the diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 6deb89a296..e6150595af 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -100,6 +100,21 @@ for a path to `Unspecified` state. This can be done by listing the name of the attribute prefixed with an exclamation point `!`. +RESERVED BUILTIN_* ATTRIBUTES +----------------------------- + +builtin_* is a reserved namespace for builtin attribute values. Any +user defined attributes under this namespace will be ignored and +trigger a warning. + +`builtin_objectmode` +~~~~~~~~~~~~~~~~~~~~ +This attribute is for filtering files by their file bit modes (40000, +120000, 160000, 100755, 100644). e.g. ':(attr:builtin_objectmode=160000)'. +You may also check these values with `git check-attr builtin_objectmode -- <file>`. +If the object is not in the index `git check-attr --cached` will return unspecified. + + EFFECTS ------- @@ -359,7 +374,7 @@ 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 +*.ps1 text working-tree-encoding=UTF-16LE eol=crlf ------------------------ You can get a list of all available encodings on your platform with the @@ -761,6 +776,11 @@ with the above configuration, i.e. `j-c-diff`, with 7 parameters, just like `GIT_EXTERNAL_DIFF` program is called. See linkgit:git[1] for details. +If the program is able to ignore certain changes (similar to +`git diff --ignore-space-change`), then also set the option +`trustExitCode` to true. It is then expected to return exit code 1 if +it finds significant changes and 0 if it doesn't. + Setting the internal diff algorithm ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -1122,11 +1142,11 @@ The `merge.*.name` variable gives the driver a human-readable name. The `merge.*.driver` variable's value is used to construct a -command to run to merge ancestor's version (`%O`), current +command to run to common ancestor's version (`%O`), current version (`%A`) and the other branches' version (`%B`). These three tokens are replaced with the names of temporary files that hold the contents of these versions when the command line is -built. Additionally, %L will be replaced with the conflict marker +built. Additionally, `%L` will be replaced with the conflict marker size (see below). The merge driver is expected to leave the result of the merge in @@ -1144,15 +1164,16 @@ 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`. - +will be stored via placeholder `%P`. The conflict labels to be used +for the common ancestor, local head and other head can be passed by +using '%S', '%X' and '%Y` respectively. `conflict-marker-size` ^^^^^^^^^^^^^^^^^^^^^^ This attribute controls the length of conflict markers left in -the work tree file during a conflicted merge. Only setting to -the value to a positive integer has any meaningful effect. +the work tree file during a conflicted merge. Only a positive +integer has a meaningful effect. For example, this line in `.gitattributes` can be used to tell the merge machinery to leave much longer (instead of the usual 7-character-long) diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index 1819a5a185..7c709324ba 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -23,10 +23,10 @@ arguments. Here are the rules: A subcommand may take dashed options (which may take their own arguments, e.g. "--max-parents 2") and arguments. You SHOULD give dashed options first and then arguments. Some commands may - accept dashed options after you have already gave non-option + accept dashed options after you have already given non-option arguments (which may make the command ambiguous), but you should not rely on it (because eventually we may find a way to fix - these ambiguity by enforcing the "options then args" rule). + these ambiguities by enforcing the "options then args" rule). * Revisions come first and then paths. E.g. in `git diff v1.0 v2.0 arch/x86 include/asm-x86`, @@ -37,12 +37,12 @@ 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 the difference between the HEAD commit and the work tree as a whole". You can say `git diff HEAD --` to ask for the latter. * Without disambiguating `--`, Git makes a reasonable guess, but errors - out and asking you to disambiguate when ambiguous. E.g. if you have a + out and asks you to disambiguate when ambiguous. E.g. if you have a file called HEAD in your work tree, `git diff HEAD` is ambiguous, and you have to say either `git diff HEAD --` or `git diff -- HEAD` to disambiguate. @@ -81,9 +81,6 @@ 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 - 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). diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index c0b95256cc..2122aeb976 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -1089,7 +1089,7 @@ the remote repository URL in the local repository's config file like this: ------------------------------------------------ -$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/ +$ git config remote.linus.url https://git.kernel.org/pub/scm/git/git.git/ ------------------------------------------------ and use the "linus" keyword with 'git pull' instead of the full URL. diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt index 0d57f86abc..642c51227b 100644 --- a/Documentation/gitdiffcore.txt +++ b/Documentation/gitdiffcore.txt @@ -173,7 +173,7 @@ Note that when rename detection is on but both copy and break detection are off, rename detection adds a preliminary step that first checks if files are moved across directories while keeping their filename the same. If there is a file added to a directory whose -contents is sufficiently similar to a file with the same name that got +contents are sufficiently similar to a file with the same name that got deleted from a different directory, it will mark them as renames and exclude them from the later quadratic step (the one that pairwise compares all unmatched files to find the "best" matches, determined by @@ -213,7 +213,7 @@ from the original, and does not count insertion. If you removed only 10 lines from a 100-line document, even if you added 910 new lines to make a new 1000-line document, you did not do a complete rewrite. diffcore-break breaks such a case in order to -help diffcore-rename to consider such filepairs as candidate of +help diffcore-rename to consider such filepairs as a candidate of rename/copy detection, but if filepairs broken that way were not matched with other filepairs to create rename/copy, then this transformation merges them back into the original @@ -230,13 +230,13 @@ like these: * -B/60 (the same as above, since diffcore-break defaults to 50%). -Note that earlier implementation left a broken pair as a separate -creation and deletion patches. This was an unnecessary hack and +Note that earlier implementation left a broken pair as separate +creation and deletion patches. This was an unnecessary hack, and the latest implementation always merges all the broken pairs back into modifications, but the resulting patch output is formatted differently for easier review in case of such -a complete rewrite by showing the entire contents of old version -prefixed with '-', followed by the entire contents of new +a complete rewrite by showing the entire contents of the old version +prefixed with '-', followed by the entire contents of the new version prefixed with '+'. @@ -245,25 +245,25 @@ diffcore-pickaxe: For Detecting Addition/Deletion of Specified String This transformation limits the set of filepairs to those that change specified strings between the preimage and the postimage in a certain -way. -S<block of text> and -G<regular expression> options are used to +way. -S<block-of-text> and -G<regular-expression> options are used to specify different ways these strings are sought. -"-S<block of text>" detects filepairs whose preimage and postimage +"-S<block-of-text>" detects filepairs whose preimage and postimage have different number of occurrences of the specified block of text. By definition, it will not detect in-file moves. Also, when a changeset moves a file wholesale without affecting the interesting string, diffcore-rename kicks in as usual, and `-S` omits the filepair (since the number of occurrences of that string didn't change in that rename-detected filepair). When used with `--pickaxe-regex`, treat -the <block of text> as an extended POSIX regular expression to match, +the <block-of-text> as an extended POSIX regular expression to match, instead of a literal string. -"-G<regular expression>" (mnemonic: grep) detects filepairs whose +"-G<regular-expression>" (mnemonic: grep) detects filepairs whose textual diff has an added or a deleted line that matches the given regular expression. This means that it will detect in-file (or what rename-detection considers the same file) moves, which is noise. The implementation runs diff twice and greps, and this can be quite -expensive. To speed things up binary files without textconv filters +expensive. To speed things up, binary files without textconv filters will be ignored. When `-S` or `-G` are used without `--pickaxe-all`, only filepairs diff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt index faba2ef088..6cfdd0e07b 100644 --- a/Documentation/giteveryday.txt +++ b/Documentation/giteveryday.txt @@ -14,7 +14,7 @@ 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. +describing here a small set of useful commands for everyday Git. * <<STANDALONE,Individual Developer (Standalone)>> commands are essential for anybody who makes a commit, even for somebody who works alone. @@ -229,7 +229,7 @@ without a formal "merging". Or longhand + git am -3 -k` An alternate participant submission mechanism is using the -`git request-pull` or pull-request mechanisms (e.g as used on +`git request-pull` or pull-request mechanisms (e.g. as used on GitHub (www.github.com) to notify your upstream of your contribution. diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt index 8c1f2d5675..f2917d142c 100644 --- a/Documentation/gitfaq.txt +++ b/Documentation/gitfaq.txt @@ -185,6 +185,58 @@ 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`). +Transfers +--------- + +[[sync-working-tree]] +How do I sync a working tree across systems?:: + First, decide whether you want to do this at all. Git works best when you + push or pull your work using the typical `git push` and `git fetch` commands + and isn't designed to share a working tree across systems. This is + potentially risky and in some cases can cause repository corruption or data + loss. ++ +Usually, doing so will cause `git status` to need to re-read every file in the +working tree. Additionally, Git's security model does not permit sharing a +working tree across untrusted users, so it is only safe to sync a working tree +if it will only be used by a single user across all machines. ++ +It is important not to use a cloud syncing service to sync any portion of a Git +repository, since this can cause corruption, such as missing objects, changed +or added files, broken refs, and a wide variety of other problems. These +services tend to sync file by file on a continuous basis and don't understand +the structure of a Git repository. This is especially bad if they sync the +repository in the middle of it being updated, since that is very likely to +cause incomplete or partial updates and therefore data loss. ++ +An example of the kind of corruption that can occur is conflicts over the state +of refs, such that both sides end up with different commits on a branch that +the other doesn't have. This can result in important objects becoming +unreferenced and possibly pruned by `git gc`, causing data loss. ++ +Therefore, it's better to push your work to either the other system or a central +server using the normal push and pull mechanism. However, this doesn't always +preserve important data, like stashes, so some people prefer to share a working +tree across systems. ++ +If you do this, the recommended approach is to use `rsync -a --delete-after` +(ideally with an encrypted connection such as with `ssh`) on the root of +repository. You should ensure several things when you do this: ++ +* If you have additional worktrees or a separate Git directory, they must be + synced at the same time as the main working tree and repository. +* You are comfortable with the destination directory being an exact copy of the + source directory, _deleting any data that is already there_. +* The repository (including all worktrees and the Git directory) is in a + quiescent state for the duration of the transfer (that is, no operations of + any sort are taking place on it, including background operations like `git + gc` and operations invoked by your editor). ++ +Be aware that even with these recommendations, syncing in this way has some risk +since it bypasses Git's normal integrity checking for repositories, so having +backups is advised. You may also wish to do a `git fsck` to verify the +integrity of your data on the destination system after syncing. + Common Issues ------------- @@ -241,6 +293,42 @@ How do I know if I want to do a fetch or a pull?:: ignore the upstream changes. A pull consists of a fetch followed immediately by either a merge or rebase. See linkgit:git-pull[1]. +[[proxy]] +Can I use a proxy with Git?:: + Yes, Git supports the use of proxies. Git honors the standard `http_proxy`, + `https_proxy`, and `no_proxy` environment variables commonly used on Unix, and + it also can be configured with `http.proxy` and similar options for HTTPS (see + linkgit:git-config[1]). The `http.proxy` and related options can be + customized on a per-URL pattern basis. In addition, Git can in theory + function normally with transparent proxies that exist on the network. ++ +For SSH, Git can support a proxy using OpenSSH's `ProxyCommand`. Commonly used +tools include `netcat` and `socat`. However, they must be configured not to +exit when seeing EOF on standard input, which usually means that `netcat` will +require `-q` and `socat` will require a timeout with something like `-t 10`. +This is required because the way the Git SSH server knows that no more requests +will be made is an EOF on standard input, but when that happens, the server may +not have yet processed the final request, so dropping the connection at that +point would interrupt that request. ++ +An example configuration entry in `~/.ssh/config` with an HTTP proxy might look +like this: ++ +---- +Host git.example.org + User git + ProxyCommand socat -t 10 - PROXY:proxy.example.org:%h:%p,proxyport=8080 +---- ++ +Note that in all cases, for Git to work properly, the proxy must be completely +transparent. The proxy cannot modify, tamper with, or buffer the connection in +any way, or Git will almost certainly fail to work. Note that many proxies, +including many TLS middleboxes, Windows antivirus and firewall programs other +than Windows Defender and Windows Firewall, and filtering proxies fail to meet +this standard, and as a result end up breaking Git. Because of the many +reports of problems and their poor security history, we recommend against the +use of these classes of software and devices. + Merging and Rebasing -------------------- @@ -357,8 +445,9 @@ I'm on Windows and git diff shows my files as having a `^M` at the end.:: + 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. +configuration option `core.eol` to `native` and see +<<recommended-storage-settings,the question on recommended storage settings>> +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. @@ -420,14 +509,26 @@ 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: +set the attribute `text=auto`. ++ +With text files, Git will generally ensure that LF endings are used in the +repository. The `core.autocrlf` and `core.eol` configuration variables specify +what line-ending convention is followed when any text file is checked out. You +can also use the `eol` attribute (e.g., `eol=crlf`) to override which files get +what line-ending treatment. ++ +For example, generally shell files must have LF endings and batch files must +have CRLF endings, so the following might be appropriate in some projects: + ---- # By default, guess. * text=auto # Mark all C files as text. *.c text +# Ensure all shell files have LF endings and all batch files have CRLF +# endings in the working tree and both have LF in the repo. +*.sh text eol=lf +*.bat text eol=crlf # Mark all JPEG files as binary. *.jpg binary ---- diff --git a/Documentation/gitformat-bundle.txt b/Documentation/gitformat-bundle.txt index 00e0a20e65..1b75cf71ce 100644 --- a/Documentation/gitformat-bundle.txt +++ b/Documentation/gitformat-bundle.txt @@ -67,7 +67,7 @@ A Git bundle consists of several parts. * "Capabilities", which are only in the v3 format, indicate functionality that the bundle requires to be read properly. -* "Prerequisites" lists the objects that are NOT included in the bundle and the +* "Prerequisites" list 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 @@ -86,10 +86,10 @@ 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 on shallow clones and Git bundles +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Note that the prerequisites does not represent a shallow-clone boundary. The +Note that the prerequisites do 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/gitformat-chunk.txt b/Documentation/gitformat-chunk.txt index 57202ede27..3315df6201 100644 --- a/Documentation/gitformat-chunk.txt +++ b/Documentation/gitformat-chunk.txt @@ -42,7 +42,7 @@ Each row consists of a 4-byte chunk identifier (ID) and an 8-byte offset. Each integer is stored in network-byte order. The chunk identifier `ID[i]` is a label for the data stored within this -fill from `OFFSET[i]` (inclusive) to `OFFSET[i+1]` (exclusive). Thus, the +file from `OFFSET[i]` (inclusive) to `OFFSET[i+1]` (exclusive). Thus, the size of the `i`th chunk is equal to the difference between `OFFSET[i+1]` and `OFFSET[i]`. This requires that the chunk data appears contiguously in the same order as the table of contents. @@ -67,7 +67,7 @@ caller is responsible for opening the `hashfile` and writing header information so the file format is identifiable before the chunk-based format begins. -Then, call `add_chunk()` for each chunk that is intended for write. This +Then, call `add_chunk()` for each chunk that is intended for writing. This populates the `chunkfile` with information about the order and size of each chunk to write. Provide a `chunk_write_fn` function pointer to perform the write of the chunk data upon request. diff --git a/Documentation/gitformat-commit-graph.txt b/Documentation/gitformat-commit-graph.txt index 31cad585e2..14d1631234 100644 --- a/Documentation/gitformat-commit-graph.txt +++ b/Documentation/gitformat-commit-graph.txt @@ -122,7 +122,7 @@ All multi-byte numbers are in network byte order. for commits with corrected commit date offsets that cannot be stored within 31 bits. * Generation Data Overflow chunk is present only when Generation Data - chunk is present and atleast one corrected commit date offset cannot + chunk is present and at least one corrected commit date offset cannot be stored within 31 bits. ==== Extra Edge List (ID: {'E', 'D', 'G', 'E'}) [Optional] @@ -142,13 +142,16 @@ All multi-byte numbers are in network byte order. ==== 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 + - Version of the hash algorithm being used. We currently support + value 2 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" + in Probabilistic Verification". Version 1 Bloom filters have a bug that appears + when char is signed and the repository has path names that have characters >= + 0x80; Git supports reading and writing them, but this ability will be removed + in a future version of Git. - 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 diff --git a/Documentation/gitformat-index.txt b/Documentation/gitformat-index.txt index 0773e5c380..145cace1fe 100644 --- a/Documentation/gitformat-index.txt +++ b/Documentation/gitformat-index.txt @@ -386,8 +386,8 @@ The remaining data of each directory block is grouped by type: long, "REUC" extension that is M-bytes long, followed by "EOIE", then the hash would be: - Hash("TREE" + <binary representation of N> + - "REUC" + <binary representation of M>) + Hash("TREE" + <binary-representation-of-N> + + "REUC" + <binary-representation-of-M>) == Index Entry Offset Table diff --git a/Documentation/gitformat-pack.txt b/Documentation/gitformat-pack.txt index 0c1be2dbe8..d6ae229be5 100644 --- a/Documentation/gitformat-pack.txt +++ b/Documentation/gitformat-pack.txt @@ -17,8 +17,8 @@ $GIT_DIR/objects/pack/multi-pack-index DESCRIPTION ----------- -The Git pack format is now Git stores most of its primary repository -data. Over the lietime af a repository loose objects (if any) and +The Git pack format is how Git stores most of its primary repository +data. Over the lifetime of a repository, loose objects (if any) and smaller packs are consolidated into larger pack(s). See linkgit:git-gc[1] and linkgit:git-pack-objects[1]. @@ -48,7 +48,7 @@ Similarly, in SHA-256 repositories, these values are computed using SHA-256. Observation: we cannot have more than 4G versions ;-) and more than 4G objects in a pack. - - The header is followed by number of object entries, each of + - The header is followed by a number of object entries, each of which looks like this: (undeltified representation) @@ -62,7 +62,7 @@ Similarly, in SHA-256 repositories, these values are computed using SHA-256. is an OBJ_OFS_DELTA object compressed delta data - Observation: length of each object is encoded in a variable + Observation: the length of each object is encoded in a variable length format and is not constrained to 32-bit or anything. - The trailer records a pack checksum of all of the above. @@ -117,7 +117,7 @@ the delta data is a sequence of instructions to reconstruct the 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 +supported instructions so far: one for copying a byte range from the source object and one for inserting new data embedded in the instruction itself. @@ -137,7 +137,7 @@ 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 +bits in the first octet determine 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. @@ -161,9 +161,9 @@ converted to 0x10000. | 0xxxxxxx | data | +----------+============+ -This is the instruction to construct target object without the base +This is the instruction to construct the 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 +seven bits of the first octet determine the size of data in bytes. The size must be non-zero. ==== Reserved instruction @@ -294,7 +294,7 @@ Pack file entry: <+ - The same trailer as a v1 pack file: - A copy of the pack checksum at the end of + A copy of the pack checksum at the end of the corresponding packfile. Index checksum of all of the above. @@ -390,10 +390,20 @@ CHUNK LOOKUP: 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. + Store the names of packfiles as a sequence of NUL-terminated + strings. There is no extra padding between the filenames, + and they are listed in lexicographic order. The chunk itself + is padded at the end with between 0 and 3 NUL bytes to make the + chunk size a multiple of 4 bytes. + + Bitmapped Packfiles (ID: {'B', 'T', 'M', 'P'}) + Stores a table of two 4-byte unsigned integers in network order. + Each table entry corresponds to a single pack (in the order that + they appear above in the `PNAM` chunk). The values for each table + entry are as follows: + - The first bit position (in pseudo-pack order, see below) to + contain an object from that pack. + - The number of bits whose objects are selected from that pack. OID Fanout (ID: {'O', 'I', 'D', 'F'}) The ith entry, F[i], stores the number of OIDs with first @@ -508,6 +518,73 @@ packs arranged in MIDX order (with the preferred pack coming first). The MIDX's reverse index is stored in the optional 'RIDX' chunk within the MIDX itself. +=== `BTMP` chunk + +The Bitmapped Packfiles (`BTMP`) chunk encodes additional information +about the objects in the multi-pack index's reachability bitmap. Recall +that objects from the MIDX are arranged in "pseudo-pack" order (see +above) for reachability bitmaps. + +From the example above, suppose we have packs "a", "b", and "c", with +10, 15, and 20 objects, respectively. In pseudo-pack order, those would +be arranged as follows: + + |a,0|a,1|...|a,9|b,0|b,1|...|b,14|c,0|c,1|...|c,19| + +When working with single-pack bitmaps (or, equivalently, multi-pack +reachability bitmaps with a preferred pack), linkgit:git-pack-objects[1] +performs ``verbatim'' reuse, attempting to reuse chunks of the bitmapped +or preferred packfile instead of adding objects to the packing list. + +When a chunk of bytes is reused from an existing pack, any objects +contained therein do not need to be added to the packing list, saving +memory and CPU time. But a chunk from an existing packfile can only be +reused when the following conditions are met: + + - The chunk contains only objects which were requested by the caller + (i.e. does not contain any objects which the caller didn't ask for + explicitly or implicitly). + + - All objects stored in non-thin packs as offset- or reference-deltas + also include their base object in the resulting pack. + +The `BTMP` chunk encodes the necessary information in order to implement +multi-pack reuse over a set of packfiles as described above. +Specifically, the `BTMP` chunk encodes three pieces of information (all +32-bit unsigned integers in network byte-order) for each packfile `p` +that is stored in the MIDX, as follows: + +`bitmap_pos`:: The first bit position (in pseudo-pack order) in the + multi-pack index's reachability bitmap occupied by an object from `p`. + +`bitmap_nr`:: The number of bit positions (including the one at + `bitmap_pos`) that encode objects from that pack `p`. + +For example, the `BTMP` chunk corresponding to the above example (with +packs ``a'', ``b'', and ``c'') would look like: + +[cols="1,2,2"] +|=== +| |`bitmap_pos` |`bitmap_nr` + +|packfile ``a'' +|`0` +|`10` + +|packfile ``b'' +|`10` +|`15` + +|packfile ``c'' +|`25` +|`20` +|=== + +With this information in place, we can treat each packfile as +individually reusable in the same fashion as verbatim pack reuse is +performed on individual packs prior to the implementation of the `BTMP` +chunk. + == cruft packs The cruft packs feature offer an alternative to Git's traditional mechanism of @@ -588,51 +665,17 @@ later on. It is linkgit:git-gc[1] that is typically responsible for removing expired unreachable objects. -=== Caution for mixed-version environments - -Repositories that have cruft packs in them will continue to work with any older -version of Git. Note, however, that previous versions of Git which do not -understand the `.mtimes` file will use the cruft pack's mtime as the mtime for -all of the objects in it. In other words, do not expect older (pre-cruft pack) -versions of Git to interpret or even read the contents of the `.mtimes` file. - -Note that having mixed versions of Git GC-ing the same repository can lead to -unreachable objects never being completely pruned. This can happen under the -following circumstances: - - - An older version of Git running GC explodes the contents of an existing - cruft pack loose, using the cruft pack's mtime. - - A newer version running GC collects those loose objects into a cruft pack, - where the .mtime file reflects the loose object's actual mtimes, but the - cruft pack mtime is "now". - -Repeating this process will lead to unreachable objects not getting pruned as a -result of repeatedly resetting the objects' mtimes to the present time. - -If you are GC-ing repositories in a mixed version environment, consider omitting -the `--cruft` option when using linkgit:git-repack[1] and linkgit:git-gc[1], and -setting the `gc.cruftPacks` configuration to "false" until all writers -understand cruft packs. - === Alternatives Notable alternatives to this design include: - - The location of the per-object mtime data, and - - Storing unreachable objects in multiple cruft packs. + - The location of the per-object mtime data. On the location of mtime data, a new auxiliary file tied to the pack was chosen to avoid complicating the `.idx` format. If the `.idx` format were ever to gain support for optional chunks of data, it may make sense to consolidate the `.mtimes` format into the `.idx` itself. -Storing unreachable objects among multiple cruft packs (e.g., creating a new -cruft pack during each repacking operation including only unreachable objects -which aren't already stored in an earlier cruft pack) is significantly more -complicated to construct, and so aren't pursued here. The obvious drawback to -the current implementation is that the entire cruft pack must be re-written from -scratch. - GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index 86f804720a..0397dec64d 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -80,7 +80,7 @@ If it exits with non-zero status, then the working tree will not be committed after applying the patch. It can be used to inspect the current working tree and refuse to -make a commit if it does not pass certain test. +make a commit if it does not pass certain tests. The default 'pre-applypatch' hook, when enabled, runs the 'pre-commit' hook, if the latter is enabled. @@ -157,7 +157,7 @@ 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. +be used as a replacement for the pre-commit hook. The sample `prepare-commit-msg` hook that comes with Git removes the help message found in the commented portion of the commit template. @@ -243,7 +243,7 @@ named remote is not being used both values will be the same. Information about what is to be pushed is provided on the hook's standard input with lines of the form: - <local ref> SP <local object name> SP <remote ref> SP <remote object name> LF + <local-ref> SP <local-object-name> SP <remote-ref> SP <remote-object-name> LF For instance, if the command +git push origin master:foreign+ were run the hook would receive a line like the following: @@ -251,9 +251,9 @@ hook would receive a line like the following: refs/heads/master 67890 refs/heads/foreign 12345 although the full object name would be supplied. If the foreign ref does not -yet exist the `<remote object name>` will be the all-zeroes object name. If a -ref is to be deleted, the `<local ref>` will be supplied as `(delete)` and the -`<local object name>` will be the all-zeroes object name. If the local commit +yet exist the `<remote-object-name>` will be the all-zeroes object name. If a +ref is to be deleted, the `<local-ref>` will be supplied as `(delete)` and the +`<local-object-name>` will be the all-zeroes object name. If the local commit was specified by something other than a name which could be expanded (such as `HEAD~`, or an object name) it will be supplied as it was originally given. @@ -275,12 +275,12 @@ This hook executes once for the receive operation. It takes no arguments, but for each ref to be updated it receives on standard input a line of the format: - <old-value> SP <new-value> SP <ref-name> LF + <old-oid> SP <new-oid> SP <ref-name> LF -where `<old-value>` is the old object name stored in the ref, -`<new-value>` is the new object name to be stored in the ref and +where `<old-oid>` is the old object name stored in the ref, +`<new-oid>` is the new object name to be stored in the ref and `<ref-name>` is the full name of the ref. -When creating a new ref, `<old-value>` is the all-zeroes object name. +When creating a new ref, `<old-oid>` is the all-zeroes object name. If the hook exits with non-zero status, none of the refs will be updated. If the hook exits with zero, updating of individual refs can @@ -345,7 +345,7 @@ for the user. The default 'update' hook, when enabled--and with `hooks.allowunannotated` config option unset or set to false--prevents -unannotated tags to be pushed. +unannotated tags from being pushed. [[proc-receive]] proc-receive @@ -379,12 +379,12 @@ following example for the protocol, the letter 'S' stands for S: ... ... S: flush-pkt - # Receive result from the hook. + # Receive results from the hook. # OK, run this command successfully. H: PKT-LINE(ok <ref>) # NO, I reject it. H: PKT-LINE(ng <ref> <reason>) - # Fall through, let 'receive-pack' to execute it. + # Fall through, let 'receive-pack' execute it. H: PKT-LINE(ok <ref>) H: PKT-LINE(option fall-through) # OK, but has an alternate reference. The alternate reference name @@ -415,13 +415,13 @@ post-receive This hook is invoked by linkgit:git-receive-pack[1] when it reacts to `git push` and updates reference(s) in its repository. -It executes on the remote repository once after all the refs have -been updated. +The hook executes on the remote repository once after all the proposed +ref updates are processed and if at least one ref is updated as the +result. -This hook executes once for the receive operation. It takes no -arguments, but gets the same information as the -<<pre-receive,'pre-receive'>> -hook does on its standard input. +The hook takes no arguments. It receives one line on standard input for +each ref that is successfully updated following the same format as the +<<pre-receive,'pre-receive'>> hook. This hook does not affect the outcome of `git receive-pack`, as it is called after the real work is done. @@ -448,6 +448,9 @@ 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 "post-receive" section in linkgit:git-receive-pack[1] for +additional details. + [[post-update]] post-update ~~~~~~~~~~~ @@ -486,7 +489,7 @@ 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 -does not cover symbolic references (but that may change in the future). +also supports symbolic reference updates. The hook takes exactly one argument, which is the current state the given reference transaction is in: @@ -513,6 +516,10 @@ to be created anew, `<old-value>` is the all-zeroes object name. To distinguish these cases, you can inspect the current value of `<ref-name>` via `git rev-parse`. +For symbolic reference updates the `<old_value>` and `<new-value>` +fields could denote references instead of objects. A reference will be +denoted with a 'ref:' prefix, like `ref:<ref-target>`. + 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 diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index d50e9ed10e..35b3996029 100644 --- a/Documentation/gitk.txt +++ b/Documentation/gitk.txt @@ -8,7 +8,7 @@ gitk - The Git repository browser SYNOPSIS -------- [verse] -'gitk' [<options>] [<revision range>] [--] [<path>...] +'gitk' [<options>] [<revision-range>] [--] [<path>...] DESCRIPTION ----------- @@ -26,7 +26,7 @@ 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 +'stuck' form (see linkgit:gitcli[7]) due to limitations in the command-line parser. rev-list options and arguments @@ -124,7 +124,7 @@ gitk-specific options 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 + '<revision-range>' if the set of commits to show may vary between refreshes. --select-commit=<ref>:: diff --git a/Documentation/gitpacking.txt b/Documentation/gitpacking.txt new file mode 100644 index 0000000000..321154d4e6 --- /dev/null +++ b/Documentation/gitpacking.txt @@ -0,0 +1,195 @@ +gitpacking(7) +============= + +NAME +---- +gitpacking - Advanced concepts related to packing in Git + +SYNOPSIS +-------- +gitpacking + +DESCRIPTION +----------- + +This document aims to describe some advanced concepts related to packing +in Git. + +Many concepts are currently described scattered between manual pages of +various Git commands, including linkgit:git-pack-objects[1], +linkgit:git-repack[1], and others, as well as linkgit:gitformat-pack[5], +and parts of the `Documentation/technical` tree. + +There are many aspects of packing in Git that are not covered in this +document that instead live in the aforementioned areas. Over time, those +scattered bits may coalesce into this document. + +== Pseudo-merge bitmaps + +NOTE: Pseudo-merge bitmaps are considered an experimental feature, so +the configuration and many of the ideas are subject to change. + +=== Background + +Reachability bitmaps are most efficient when we have on-disk stored +bitmaps for one or more of the starting points of a traversal. For this +reason, Git prefers storing bitmaps for commits at the tips of refs, +because traversals tend to start with those points. + +But if you have a large number of refs, it's not feasible to store a +bitmap for _every_ ref tip. It takes up space, and just OR-ing all of +those bitmaps together is expensive. + +One way we can deal with that is to create bitmaps that represent +_groups_ of refs. When a traversal asks about the entire group, then we +can use this single bitmap instead of considering each ref individually. +Because these bitmaps represent the set of objects which would be +reachable in a hypothetical merge of all of the commits, we call them +pseudo-merge bitmaps. + +=== Overview + +A "pseudo-merge bitmap" is used to refer to a pair of bitmaps, as +follows: + +Commit bitmap:: + + A bitmap whose set bits describe the set of commits included in the + pseudo-merge's "merge" bitmap (as below). + +Merge bitmap:: + + A bitmap whose set bits describe the reachability closure over the set + of commits in the pseudo-merge's "commits" bitmap (as above). An + identical bitmap would be generated for an octopus merge with the same + set of parents as described in the commits bitmap. + +Pseudo-merge bitmaps can accelerate bitmap traversals when all commits +for a given pseudo-merge are listed on either side of the traversal, +either directly (by explicitly asking for them as part of the `HAVES` +or `WANTS`) or indirectly (by encountering them during a fill-in +traversal). + +=== Use-cases + +For example, suppose there exists a pseudo-merge bitmap with a large +number of commits, all of which are listed in the `WANTS` section of +some bitmap traversal query. When pseudo-merge bitmaps are enabled, the +bitmap machinery can quickly determine there is a pseudo-merge which +satisfies some subset of the wanted objects on either side of the query. +Then, we can inflate the EWAH-compressed bitmap, and `OR` it in to the +resulting bitmap. By contrast, without pseudo-merge bitmaps, we would +have to repeat the decompression and `OR`-ing step over a potentially +large number of individual bitmaps, which can take proportionally more +time. + +Another benefit of pseudo-merges arises when there is some combination +of (a) a large number of references, with (b) poor bitmap coverage, and +(c) deep, nested trees, making fill-in traversal relatively expensive. +For example, suppose that there are a large enough number of tags where +bitmapping each of the tags individually is infeasible. Without +pseudo-merge bitmaps, computing the result of, say, `git rev-list +--use-bitmap-index --count --objects --tags` would likely require a +large amount of fill-in traversal. But when a large quantity of those +tags are stored together in a pseudo-merge bitmap, the bitmap machinery +can take advantage of the fact that we only care about the union of +objects reachable from all of those tags, and answer the query much +faster. + +=== Configuration + +Reference tips are grouped into different pseudo-merge groups according +to two criteria. A reference name matches one or more of the defined +pseudo-merge patterns, and optionally one or more capture groups within +that pattern which further partition the group. + +Within a group, commits may be considered "stable", or "unstable" +depending on their age. These are adjusted by setting the +`bitmapPseudoMerge.<name>.stableThreshold` and +`bitmapPseudoMerge.<name>.threshold` configuration values, respectively. + +All stable commits are grouped into pseudo-merges of equal size +(`bitmapPseudoMerge.<name>.stableSize`). If the `stableSize` +configuration is set to, say, 100, then the first 100 commits (ordered +by committer date) which are older than the `stableThreshold` value will +form one group, the next 100 commits will form another group, and so on. + +Among unstable commits, the pseudo-merge machinery will attempt to +combine older commits into large groups as opposed to newer commits +which will appear in smaller groups. This is based on the heuristic that +references whose tip commit is older are less likely to be modified to +point at a different commit than a reference whose tip commit is newer. + +The size of groups is determined by a power-law decay function, and the +decay parameter roughly corresponds to "k" in `f(n) = C*n^(-k/100)`, +where `f(n)` describes the size of the `n`-th pseudo-merge group. The +sample rate controls what percentage of eligible commits are considered +as candidates. The threshold parameter indicates the minimum age (so as +to avoid including too-recent commits in a pseudo-merge group, making it +less likely to be valid). The "maxMerges" parameter sets an upper-bound +on the number of pseudo-merge commits an individual group + +The "stable"-related parameters control "stable" pseudo-merge groups, +comprised of a fixed number of commits which are older than the +configured "stable threshold" value and may be grouped together in +chunks of "stableSize" in order of age. + +The exact configuration for pseudo-merges is as follows: + +include::config/bitmap-pseudo-merge.txt[] + +=== Examples + +Suppose that you have a repository with a large number of references, +and you want a bare-bones configuration of pseudo-merge bitmaps that +will enhance bitmap coverage of the `refs/` namespace. You may start +with a configuration like so: + +---- +[bitmapPseudoMerge "all"] + pattern = "refs/" + threshold = now + stableThreshold = never + sampleRate = 100 + maxMerges = 64 +---- + +This will create pseudo-merge bitmaps for all references, regardless of +their age, and group them into 64 pseudo-merge commits. + +If you wanted to separate tags from branches when generating +pseudo-merge commits, you would instead define the pattern with a +capture group, like so: + +---- +[bitmapPseudoMerge "all"] + pattern = "refs/(heads/tags)/" +---- + +Suppose instead that you are working in a fork-network repository, with +each fork specified by some numeric ID, and whose refs reside in +`refs/virtual/NNN/` (where `NNN` is the numeric ID corresponding to some +fork) in the network. In this instance, you may instead write something +like: + +---- +[bitmapPseudoMerge "all"] + pattern = "refs/virtual/([0-9]+)/(heads|tags)/" + threshold = now + stableThreshold = never + sampleRate = 100 + maxMerges = 64 +---- + +Which would generate pseudo-merge group identifiers like "1234-heads", +and "5678-tags" (for branches in fork "1234", and tags in remote "5678", +respectively). + +SEE ALSO +-------- +linkgit:git-pack-objects[1] +linkgit:git-repack[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitprotocol-capabilities.txt b/Documentation/gitprotocol-capabilities.txt index 0fb5ea0c1c..2cf7735be4 100644 --- a/Documentation/gitprotocol-capabilities.txt +++ b/Documentation/gitprotocol-capabilities.txt @@ -30,7 +30,7 @@ to be in effect. The client MUST NOT ask for capabilities the server did not say it supports. Server MUST diagnose and abort if capabilities it does not understand -was sent. Server MUST NOT ignore capabilities that client requested +were 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. @@ -61,8 +61,8 @@ complete cut across the DAG, or the client has said "done". Without multi_ack, a client sends have lines in --date-order until the server has found a common base. That means the client will send have lines that are already known by the server to be common, because -they overlap in time with another branch that the server hasn't found -a common base on yet. +they overlap in time with another branch on which the server hasn't found +a common base yet. For example suppose the client has commits in caps that the server doesn't and the server has commits in lower case that the client @@ -88,7 +88,7 @@ interleaved with S-R-Q. multi_ack_detailed ------------------ -This is an extension of multi_ack that permits client to better +This is an extension of multi_ack that permits the client to better understand the server's in-memory state. See linkgit:gitprotocol-pack[5], section "Packfile Negotiation" for more information. @@ -135,7 +135,7 @@ to disable the feature in a backwards-compatible manner. side-band, side-band-64k ------------------------ -This capability means that server can send, and client understand multiplexed +This capability means that the server can send, and the client can understand, multiplexed progress reports and error info interleaved with the packfile itself. These two options are mutually exclusive. A modern client always @@ -163,14 +163,14 @@ Further, with side-band and its up to 1000-byte messages, it's actually same deal, you have up to 65519 bytes of data and 1 byte for the stream code. -The client MUST send only maximum of one of "side-band" and "side- -band-64k". Server MUST diagnose it as an error if client requests +The client MUST send only one of "side-band" and "side- +band-64k". The server MUST diagnose it as an error if client requests both. ofs-delta --------- -Server can send, and client understand PACKv2 with delta referring to +The server can send, and the client can understand, PACKv2 with delta referring to its base by position in pack rather than by an obj-id. That is, they can send/read OBJ_OFS_DELTA (aka type 6) in a packfile. @@ -252,7 +252,7 @@ the current shallow boundary, instead of the depth from remote refs. no-progress ----------- -The client was started with "git clone -q" or something, and doesn't +The client was started with "git clone -q" or something similar, and doesn't want that side band 2. Basically the client just says "I do not wish to receive stream 2 on sideband, so do not send it to me, and if you did, I will drop it on the floor anyway". However, the sideband @@ -273,7 +273,7 @@ request include-tag only has to do with the client's desires for tag data, whether or not a server had advertised objects in the refs/tags/* namespace. -Servers MUST pack the tags if their referrant is packed and the client +Servers MUST pack the tags if their referent is packed and the client has requested include-tags. Clients MUST be prepared for the case where a server has ignored @@ -378,7 +378,7 @@ 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. -session-id=<session id> +session-id=<session-id> ----------------------- The server may advertise a session ID that can be used to identify this process diff --git a/Documentation/gitprotocol-common.txt b/Documentation/gitprotocol-common.txt index 1486651bd1..cdc9d6e707 100644 --- a/Documentation/gitprotocol-common.txt +++ b/Documentation/gitprotocol-common.txt @@ -13,7 +13,7 @@ SYNOPSIS DESCRIPTION ----------- -This document sets defines things common to various over-the-wire +This document defines things common to various over-the-wire protocols and file formats used in Git. ABNF Notation diff --git a/Documentation/gitprotocol-http.txt b/Documentation/gitprotocol-http.txt index ccc13f0a40..ec40a550cc 100644 --- a/Documentation/gitprotocol-http.txt +++ b/Documentation/gitprotocol-http.txt @@ -42,7 +42,7 @@ both the "smart" and "dumb" HTTP protocols used by Git operate by appending additional path components onto the end of the user supplied `$GIT_URL` string. -An example of a dumb client requesting for a loose object: +An example of a dumb client requesting a loose object: $GIT_URL: http://example.com:8080/git/repo.git URL request: http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355 @@ -379,7 +379,7 @@ 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 +C: Build a set, `want`, of the objects from `advertised` that the client wants to fetch, based on what it saw during ref discovery. C: Start a queue, `c_pending`, ordered by commit time (popping newest @@ -391,14 +391,14 @@ C: Start a queue, `c_pending`, ordered by commit time (popping newest C: Send one `$GIT_URL/git-upload-pack` request: - C: 0032want <want #1>............................... - C: 0032want <want #2>............................... + 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 @@ -423,7 +423,7 @@ multiple commands. Object names MUST be given using the object format negotiated through the `object-format` capability (default SHA-1). The `have` list is created by popping the first 32 commits -from `c_pending`. Less can be supplied if `c_pending` empties. +from `c_pending`. Fewer 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 @@ -512,7 +512,7 @@ Within the command portion of the request body clients SHOULD send the id obtained through ref discovery as old_id. update_request = command_list - "PACK" <binary data> + "PACK" <binary-data> command_list = PKT-LINE(command NUL cap_list LF) *(command_pkt) @@ -529,8 +529,8 @@ TODO: Document this further. REFERENCES ---------- -http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)] -http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1] +https://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)] +https://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1] SEE ALSO -------- diff --git a/Documentation/gitprotocol-pack.txt b/Documentation/gitprotocol-pack.txt index dd4108b7a3..837b691c89 100644 --- a/Documentation/gitprotocol-pack.txt +++ b/Documentation/gitprotocol-pack.txt @@ -30,7 +30,7 @@ pkt-line Format --------------- The descriptions below build on the pkt-line format described in -linkgit:gitprotocol-common[5]. When the grammar indicate `PKT-LINE(...)`, unless +linkgit:gitprotocol-common[5]. When the grammar indicates `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. @@ -137,7 +137,7 @@ an absolute path in the remote filesystem. v ssh user@example.com "git-upload-pack '/project.git'" -In a "user@host:path" format URI, its relative to the user's home +In a "user@host:path" format URI, it's relative to the user's home directory, because the Git client will run: git clone user@example.com:project.git @@ -325,7 +325,7 @@ a positive depth, this step is skipped. If the client has requested a positive depth, the server will compute the set of commits which are no deeper than the desired depth. The set -of commits start at the client's wants. +of commits starts at the client's wants. The server writes 'shallow' lines for each commit whose parents will not be sent as a result. The server writes diff --git a/Documentation/gitprotocol-v2.txt b/Documentation/gitprotocol-v2.txt index acb97ad0c2..1652fef3ae 100644 --- a/Documentation/gitprotocol-v2.txt +++ b/Documentation/gitprotocol-v2.txt @@ -29,7 +29,7 @@ protocol. Protocol v2 will improve upon v1 in the following ways: 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 +server a list of capabilities will be 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. @@ -199,7 +199,7 @@ 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>" +of a space separated list of features: "<command>=<feature-1> <feature-2>" ls-refs takes in the following arguments: @@ -245,7 +245,7 @@ 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>" +of a space separated list of features: "<command>=<feature-1> <feature-2>" A `fetch` request can take the following arguments: @@ -346,7 +346,8 @@ 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. + server. It is a protocol error to send want-ref for the + same ref more than once. If the 'sideband-all' feature is advertised, the following argument can be included in the client's request: @@ -361,9 +362,10 @@ included in the client's request: 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. +explained below. Note that at most one `packfile-uris` line can be sent +to the server. - packfile-uris <comma-separated list of protocols> + 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 @@ -525,8 +527,8 @@ a request. The provided options must not contain a NUL or LF character. - object-format -~~~~~~~~~~~~~~~ +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 @@ -534,7 +536,7 @@ 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. -session-id=<session id> +session-id=<session-id> ~~~~~~~~~~~~~~~~~~~~~~~ The server may advertise a session ID that can be used to identify this process @@ -774,7 +776,7 @@ This would allow for optimizing the common case of servers who'd like to provide one "big bundle" containing only their "main" branch, and/or incremental updates thereof. + -A client receiving such a a response MAY assume that they can skip +A client receiving such a response MAY assume that they can skip retrieving the header from a bundle at the indicated URI, and thus save themselves and the server(s) the request(s) needed to inspect the headers of that bundle or bundles. diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt index ed8da428c9..d0be008e5e 100644 --- a/Documentation/gitremote-helpers.txt +++ b/Documentation/gitremote-helpers.txt @@ -479,14 +479,14 @@ set by Git if the remote helper has the 'option' capability. 'option depth' <depth>:: Deepens the history of a shallow repository. -'option deepen-since <timestamp>:: +'option deepen-since' <timestamp>:: Deepens the history of a shallow repository based on time. -'option deepen-not <ref>:: +'option deepen-not' <ref>:: Deepens the history of a shallow repository excluding ref. Multiple options add up. -'option deepen-relative {'true'|'false'}:: +'option deepen-relative' {'true'|'false'}:: Deepens the history of a shallow repository relative to current boundary. Only valid when used with "option depth". @@ -526,7 +526,7 @@ set by Git if the remote helper has the 'option' capability. 'option pushcert' {'true'|'false'}:: GPG sign pushes. -'option push-option <string>:: +'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. @@ -542,13 +542,10 @@ set by Git if the remote helper has the 'option' capability. 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 +'option object-format 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 -------- diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index 1a2ef4c150..fa8b51daf0 100644 --- a/Documentation/gitrepository-layout.txt +++ b/Documentation/gitrepository-layout.txt @@ -23,7 +23,9 @@ A Git repository comes in two different flavours: *Note*: Also you can have a plain text file `.git` at the root of your working tree, containing `gitdir: <path>` to point at the real -directory that has the repository. This mechanism is often used for +directory that has the repository. +This mechanism is called a 'gitfile' and is usually managed via the +`git submodule` and `git worktree` commands. It is often used for a working tree of a submodule checkout, to allow you in the containing superproject to `git checkout` a branch that does not have the submodule. The `checkout` has to remove the entire @@ -296,6 +298,7 @@ SEE ALSO -------- linkgit:git-init[1], linkgit:git-clone[1], +linkgit:git-config[1], linkgit:git-fetch[1], linkgit:git-pack-refs[1], linkgit:git-gc[1], diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt index 941858a6ec..f7b5a25a0c 100644 --- a/Documentation/gitsubmodules.txt +++ b/Documentation/gitsubmodules.txt @@ -78,7 +78,7 @@ Submodule operations can be configured using the following mechanisms * 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. + `--recurse-submodules` which specifies 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. @@ -151,7 +151,7 @@ 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 +`git rm <submodule-path> && git commit`. This can be undone using `git revert`. + The deletion removes the superproject's tracking data, which are @@ -192,7 +192,7 @@ For example: [submodule "baz"] url = https://example.org/baz -In the above config only the submodule 'bar' and 'baz' are active, +In the above config only the submodules 'bar' and 'baz' are active, 'bar' due to (1) and 'baz' due to (3). 'foo' is inactive because (1) takes precedence over (3) @@ -229,7 +229,7 @@ Workflow for a third party library git submodule add <URL> <path> # Occasionally update the submodule to a new version: - git -C <path> checkout <new version> + git -C <path> checkout <new-version> git add <path> git commit -m "update submodule to new version" @@ -274,7 +274,7 @@ 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 +`checkout` recurse into submodules (note that `submodule.recurse` also affects other Git commands, see linkgit:git-config[1] for a complete list). diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index c7cadd8aaf..f89ad30cf6 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -137,10 +137,10 @@ which will automatically notice any modified (but not new) files, add them to the index, and commit, all in one step. A note on commit messages: Though not required, it's a good idea to -begin the commit message with a single short (less than 50 character) -line summarizing the change, followed by a blank line and then a more -thorough description. The text up to the first blank line in a commit -message is treated as the commit title, and that title is used +begin the commit message with a single short (no more than 50 +characters) line summarizing the change, followed by a blank line and +then a more thorough description. The text up to the first blank line in +a commit message is treated as the commit title, and that title is used throughout Git. For example, linkgit:git-format-patch[1] turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body. @@ -360,7 +360,7 @@ $ gitk HEAD...FETCH_HEAD This means "show everything that is reachable from either one, but exclude anything that is reachable from both of them". -Please note that these range notation can be used with both `gitk` +Please note that these range notations can be used with both `gitk` and `git log`. After inspecting what Bob did, if there is nothing urgent, Alice may diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt index 34b1d6e224..85983587fc 100644 --- a/Documentation/gitweb.conf.txt +++ b/Documentation/gitweb.conf.txt @@ -53,7 +53,7 @@ following order: `/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 + in the same directory as the installed gitweb), or if it does not exist then fallback system-wide configuration file (defaults to `/etc/gitweb.conf`). Values obtained in later configuration files override values obtained earlier @@ -242,7 +242,7 @@ $mimetypes_file:: $highlight_bin:: Path to the highlight executable to use (it must be the one from - http://www.andre-simon.de[] due to assumptions about parameters and output). + http://andre-simon.de/zip/download.php[] due to assumptions about parameters and output). By default set to 'highlight'; set it to full path to highlight executable if it is not installed on your web server's PATH. Note that 'highlight' feature must be set for gitweb to actually @@ -343,7 +343,7 @@ $home_link_str:: Label for the "home link" at the top of all pages, leading to `$home_link` (usually the main gitweb page, which contains the projects list). It is used as the first component of gitweb's "breadcrumb trail": - `<home link> / <project> / <action>`. Can be set at build time using + `<home-link> / <project> / <action>`. Can be set at build time using the `GITWEB_HOME_LINK_STR` variable. By default it is set to "projects", as this link leads to the list of projects. Another popular choice is to set it to the name of site. Note that it is treated as raw HTML so it @@ -604,9 +604,9 @@ Many gitweb features can be enabled (or disabled) and configured using the Each `%feature` hash element is a hash reference and has the following structure: ---------------------------------------------------------------------- -"<feature_name>" => { - "sub" => <feature-sub (subroutine)>, - "override" => <allow-override (boolean)>, +"<feature-name>" => { + "sub" => <feature-sub-(subroutine)>, + "override" => <allow-override-(boolean)>, "default" => [ <options>... ] }, ---------------------------------------------------------------------- @@ -614,7 +614,7 @@ Some features cannot be overridden per project. For those features the structure of appropriate `%feature` hash element has a simpler form: ---------------------------------------------------------------------- -"<feature_name>" => { +"<feature-name>" => { "override" => 0, "default" => [ <options>... ] }, @@ -820,7 +820,7 @@ filesystem (i.e. "$projectroot/$project"), `%h` to the current hash (\'h' gitweb parameter) and `%b` to the current hash base (\'hb' gitweb parameter); `%%` expands to \'%'. + -For example, at the time this page was written, the http://repo.or.cz[] +For example, at the time this page was written, the https://repo.or.cz[] Git hosting site set it to the following to enable graphical log (using the third party tool *git-browser*): + diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt index af6bf3c45e..5e2b491ec2 100644 --- a/Documentation/gitweb.txt +++ b/Documentation/gitweb.txt @@ -8,7 +8,7 @@ gitweb - Git web interface (web frontend to Git repositories) SYNOPSIS -------- To get started with gitweb, run linkgit:git-instaweb[1] from a Git repository. -This would configure and start your web server, and run web browser pointing to +This will configure and start your web server, and run a web browser pointing to gitweb. @@ -20,15 +20,15 @@ Gitweb provides a web interface to Git repositories. Its features include: * Browsing every revision of the repository. * Viewing the contents of files in the repository at any revision. * Viewing the revision log of branches, history of files and directories, - see what was changed when, by who. + seeing what was changed, when, and by whom. * Viewing the blame/annotation details of any file (if enabled). * Generating RSS and Atom feeds of commits, for any branch. The feeds are auto-discoverable in modern web browsers. -* Viewing everything that was changed in a revision, and step through +* Viewing everything that was changed in a revision, and stepping through revisions one at a time, viewing the history of the repository. -* Finding commits which commit messages matches given search term. +* Finding commits whose commit messages match a given search term. -See http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code, +See https://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code, browsed using gitweb itself. @@ -41,9 +41,9 @@ for details. Repositories ~~~~~~~~~~~~ Gitweb can show information from one or more Git repositories. These -repositories have to be all on local filesystem, and have to share common +repositories have to be all on local filesystem, and have to share a common repository root, i.e. be all under a single parent repository (but see also -"Advanced web server setup" section, "Webserver configuration with multiple +the "Advanced web server setup" section, "Webserver configuration with multiple projects' root" subsection). ----------------------------------------------------------------------- @@ -51,7 +51,7 @@ our $projectroot = '/path/to/parent/directory'; ----------------------------------------------------------------------- The default value for `$projectroot` is `/pub/git`. You can change it during -building gitweb via `GITWEB_PROJECTROOT` build configuration variable. +building gitweb via the `GITWEB_PROJECTROOT` build configuration variable. By default all Git repositories under `$projectroot` are visible and available to gitweb. The list of projects is generated by default by scanning the @@ -66,7 +66,7 @@ found at "$projectroot/$repo". Projects list file format ~~~~~~~~~~~~~~~~~~~~~~~~~ -Instead of having gitweb find repositories by scanning filesystem +Instead of having gitweb find repositories by scanning the filesystem starting from $projectroot, you can provide a pre-generated list of visible projects by setting `$projects_list` to point to a plain text file with a list of projects (with some additional info). @@ -234,7 +234,7 @@ from the template during repository creation, usually installed in configuration variable, but the file takes precedence. category (or `gitweb.category`):: - Singe line category of a project, used to group projects if + Single line category of a project, used to group projects if `$projects_list_group_categories` is enabled. By default (file and configuration variable absent), uncategorized projects are put in the `$project_list_default_category` category. You can use the @@ -305,7 +305,7 @@ pathnames. In most general form such path_info (component) based gitweb URL looks like this: ----------------------------------------------------------------------- -.../gitweb.cgi/<repo>/<action>/<revision_from>:/<path_from>..<revision_to>:/<path_to>?<arguments> +.../gitweb.cgi/<repo>/<action>/<revision-from>:/<path-from>..<revision-to>:/<path-to>?<arguments> ----------------------------------------------------------------------- diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 5a537268e2..575c18f776 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -98,9 +98,8 @@ to point at the new commit. revision. [[def_commit-ish]]commit-ish (also committish):: - A <<def_commit_object,commit object>> or an - <<def_object,object>> that can be recursively dereferenced to - a commit object. + A <<def_commit_object,commit object>> or an <<def_object,object>> that + can be recursively <<def_dereference,dereferenced>> to a commit object. The following are all commit-ishes: a commit object, a <<def_tag_object,tag object>> that points to a commit @@ -125,6 +124,25 @@ to point at the new commit. dangling object has no references to it from any reference or <<def_object,object>> in the <<def_repository,repository>>. +[[def_dereference]]dereference:: + Referring to a <<def_symref,symbolic ref>>: the action of accessing the + <<def_ref,reference>> pointed at by a symbolic ref. Recursive + dereferencing involves repeating the aforementioned process on the + resulting ref until a non-symbolic reference is found. ++ +Referring to a <<def_tag_object,tag object>>: the action of accessing the +<<def_object,object>> a tag points at. Tags are recursively dereferenced by +repeating the operation on the result object until the result has either a +specified <<def_object_type,object type>> (where applicable) or any non-"tag" +object type. A synonym for "recursive dereference" in the context of tags is +"<<def_peel,peel>>". ++ +Referring to a <<def_commit_object,commit object>>: the action of accessing +the commit's tree object. Commits cannot be dereferenced recursively. ++ +Unless otherwise specified, "dereferencing" as it used in the context of Git +commands or protocols is implicitly recursive. + [[def_detached_HEAD]]detached HEAD:: Normally the <<def_HEAD,HEAD>> stores the name of a <<def_branch,branch>>, and commands that operate on the @@ -184,9 +202,11 @@ current branch integrates with) obviously do not work, as there is no [[def_gitfile]]gitfile:: A plain file `.git` at the root of a working tree that points at the directory that is the real repository. + For proper use see linkgit:git-worktree[1] or linkgit:git-submodule[1]. + For syntax see linkgit:gitrepository-layout[5]. [[def_grafts]]grafts:: - Grafts enables two otherwise different lines of development to be joined + Grafts enable two otherwise different lines of development to be joined together by recording fake ancestry information for commits. This way you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has is different from what was recorded when the commit was @@ -294,6 +314,12 @@ This commit is referred to as a "merge commit", or sometimes just a [[def_octopus]]octopus:: To <<def_merge,merge>> more than two <<def_branch,branches>>. +[[def_orphan]]orphan:: + The act of getting on a <<def_branch,branch>> that does not + exist yet (i.e., an <<def_unborn,unborn>> branch). After + such an operation, the commit first created becomes a commit + without a parent, starting a new history. + [[def_origin]]origin:: The default upstream <<def_repository,repository>>. Most projects have at least one upstream project which they track. By default @@ -444,6 +470,10 @@ exclude;; of the logical predecessor(s) in the line of development, i.e. its parents. +[[def_peel]]peel:: + The action of recursively <<def_dereference,dereferencing>> a + <<def_tag_object,tag object>>. + [[def_pickaxe]]pickaxe:: The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore routines that help select changes that add or delete a given text @@ -467,20 +497,18 @@ exclude;; 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. + A ref that has different semantics than normal refs. These refs can be + read via normal Git commands, but cannot be written to by commands like + linkgit:git-update-ref[1]. ++ +The following pseudorefs are known to Git: + + - `FETCH_HEAD` is written by linkgit:git-fetch[1] or linkgit:git-pull[1]. It + may refer to multiple object IDs. Each object ID is annotated with metadata + indicating where it was fetched from and its fetch status. + + - `MERGE_HEAD` is written by linkgit:git-merge[1] when resolving merge + conflicts. It contains all commit IDs which are being merged. [[def_pull]]pull:: Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and @@ -522,20 +550,38 @@ exclude;; to the result. [[def_ref]]ref:: - A name that begins with `refs/` (e.g. `refs/heads/master`) - that points to an <<def_object_name,object name>> or another - ref (the latter is called a <<def_symref,symbolic ref>>). + A name that points to an <<def_object_name,object name>> or + another ref (the latter is called a <<def_symref,symbolic ref>>). For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see linkgit:gitrevisions[7] for details. Refs are stored in the <<def_repository,repository>>. + The ref namespace is hierarchical. -Different subhierarchies are used for different purposes (e.g. the -`refs/heads/` hierarchy is used to represent local branches). +Ref names must either start with `refs/` or be located in the root of +the hierarchy. For the latter, their name must follow these rules: ++ + - The name consists of only upper-case characters or underscores. + + - The name ends with "`_HEAD`" or is equal to "`HEAD`". ++ +There are some irregular refs in the root of the hierarchy that do not +match these rules. The following list is exhaustive and shall not be +extended in the future: ++ + - `AUTO_MERGE` + + - `BISECT_EXPECTED_REV` + + - `NOTES_MERGE_PARTIAL` + + - `NOTES_MERGE_REF` + + - `MERGE_AUTOSTASH` + -There are a few special-purpose refs that do not begin with `refs/`. -The most notable example is `HEAD`. +Different subhierarchies are used for different purposes. For example, +the `refs/heads/` hierarchy is used to represent local branches whereas +the `refs/tags/` hierarchy is used to represent local tags.. [[def_reflog]]reflog:: A reflog shows the local "history" of a ref. In other words, @@ -546,7 +592,8 @@ The most notable example is `HEAD`. [[def_refspec]]refspec:: A "refspec" is used by <<def_fetch,fetch>> and <<def_push,push>> to describe the mapping between remote - <<def_ref,ref>> and local ref. + <<def_ref,ref>> and local ref. See linkgit:git-fetch[1] or + linkgit:git-push[1] for details. [[def_remote]]remote repository:: A <<def_repository,repository>> which is used to track the same @@ -620,12 +667,11 @@ The most notable example is `HEAD`. copies of) commit objects of the contained submodules. [[def_symref]]symref:: - Symbolic reference: instead of containing the <<def_SHA1,SHA-1>> - id itself, it is of the format 'ref: refs/some/thing' and when - referenced, it recursively dereferences to this reference. - '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic - references are manipulated with the linkgit:git-symbolic-ref[1] - command. + Symbolic reference: instead of containing the <<def_SHA1,SHA-1>> id + itself, it is of the format 'ref: refs/some/thing' and when referenced, + it recursively <<def_dereference,dereferences>> to this reference. + '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic references + are manipulated with the linkgit:git-symbolic-ref[1] command. [[def_tag]]tag:: A <<def_ref,ref>> under `refs/tags/` namespace that points to an @@ -650,6 +696,11 @@ The most notable example is `HEAD`. that each contain very well defined concepts or small incremental yet related changes. +[[def_trailer]]trailer:: + Key-value metadata. Trailers are optionally found at the end of + a commit message. Might be called "footers" or "tags" in other + communities. See linkgit:git-interpret-trailers[1]. + [[def_tree]]tree:: Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree object>> together with the dependent <<def_blob_object,blob>> and tree objects @@ -661,11 +712,11 @@ The most notable example is `HEAD`. <<def_tree,tree>> is equivalent to a <<def_directory,directory>>. [[def_tree-ish]]tree-ish (also treeish):: - A <<def_tree_object,tree object>> or an <<def_object,object>> - that can be recursively dereferenced to a tree object. - Dereferencing a <<def_commit_object,commit object>> yields the - tree object corresponding to the <<def_revision,revision>>'s - top <<def_directory,directory>>. + A <<def_tree_object,tree object>> or an <<def_object,object>> that can + be recursively <<def_dereference,dereferenced>> to a tree object. + Dereferencing a <<def_commit_object,commit object>> yields the tree + object corresponding to the <<def_revision,revision>>'s top + <<def_directory,directory>>. The following are all tree-ishes: a <<def_commit-ish,commit-ish>>, a tree object, @@ -674,6 +725,18 @@ The most notable example is `HEAD`. object, etc. +[[def_unborn]]unborn:: + The <<def_HEAD,HEAD>> can point at a <<def_branch,branch>> + that does not yet exist and that does not have any commit on + it yet, and such a branch is called an unborn branch. The + most typical way users encounter an unborn branch is by + creating a repository anew without cloning from elsewhere. + The HEAD would point at the 'main' (or 'master', depending + on your configuration) branch that is yet to be born. Also + some operations can get you on an unborn branch with their + <<def_orphan,orphan>> option. + + [[def_unmerged_index]]unmerged index:: An <<def_index,index>> which contains unmerged <<def_index_entry,index entries>>. diff --git a/Documentation/howto/coordinate-embargoed-releases.txt b/Documentation/howto/coordinate-embargoed-releases.txt index e653775bab..b9cb95e82f 100644 --- a/Documentation/howto/coordinate-embargoed-releases.txt +++ b/Documentation/howto/coordinate-embargoed-releases.txt @@ -145,7 +145,7 @@ Opening a Security Advisory draft The first step is to https://github.com/git/git/security/advisories/new[open an advisory]. Technically, this is not necessary. However, it is the most -convenient way to obtain the CVE number and it give us a private repository +convenient way to obtain the CVE number and it gives us a private repository associated with it that can be used to collaborate on a fix. Notifying the Linux distributions diff --git a/Documentation/howto/keep-canonical-history-correct.txt b/Documentation/howto/keep-canonical-history-correct.txt index 35d48ef714..e98f03275e 100644 --- a/Documentation/howto/keep-canonical-history-correct.txt +++ b/Documentation/howto/keep-canonical-history-correct.txt @@ -13,7 +13,7 @@ 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: +Suppose that the central repository has this history: ------------ ---o---o---A @@ -213,4 +213,4 @@ The procedure will result in a history that looks like this: B0--B1---------B2 ------------ -See also http://git-blame.blogspot.com/2013/09/fun-with-first-parent-history.html +See also https://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 d07c6d44e5..45e2599c5d 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -37,22 +37,20 @@ The Policy The policy on Integration is informally mentioned in "A Note from the maintainer" message, which is periodically posted to -this mailing list after each feature release is made. +the mailing list after each feature release is made: - Feature releases are numbered as vX.Y.0 and are meant to contain bugfixes and enhancements in any area, including functionality, performance and usability, without regression. - - One release cycle for a feature release is expected to last for - eight to ten weeks. - - - Maintenance releases are numbered as vX.Y.Z and are meant + - Maintenance releases are numbered as vX.Y.Z (0 < 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 + - The 'master' branch is used to prepare for the next feature release. In other words, at some point, the tip of 'master' - branch is tagged with vX.Y.0. + branch is tagged as vX.(Y+1).0, when vX.Y.0 is the latest + feature release. - 'maint' branch is used to prepare for the next maintenance release. After the feature release vX.Y.0 is made, the tip @@ -63,11 +61,28 @@ this mailing list after each feature release is made. - 'next' branch is used to publish changes (both enhancements and fixes) that (1) have worthwhile goal, (2) are in a fairly good shape suitable for everyday use, (3) but have not yet - demonstrated to be regression free. New changes are tested - in 'next' before merged to 'master'. + demonstrated to be regression free. Reviews from contributors on + the mailing list help to make the determination. After a topic + is merged to 'next', it is tested for at least 7 calendar days + before getting merged to 'master'. - 'seen' branch is used to publish other proposed changes that do - not yet pass the criteria set for 'next'. + not yet pass the criteria set for 'next' (see above), but there + is no promise that 'seen' will contain everything. A topic that + had no reviewer reaction may not be picked up. + + - A new topic will first get merged to 'seen', unless it is + trivially correct and clearly urgent, in which case it may be + directly merged to 'next' or even to 'master'. + + - If a topic that was picked up to 'seen' becomes and stays + inactive for 3 calendar weeks without having seen a clear + consensus that it is good enough to be moved to 'next', the + topic may be discarded from 'seen'. Interested parties are + still free to revive the topic. For the purpose of this + guideline, the definition of being "inactive" is that nobody + has discussed the topic, no new iteration of the topic was + posted, and no responses to the review comments were given. - The tips of 'master' and 'maint' branches will not be rewound to allow people to build their own customization on top of them. @@ -86,10 +101,49 @@ 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'. + - When a problem is found in a topic in 'next', the topic is marked + not to be merged to 'master'. Follow-up patches are discussed on + the mailing list and applied to the topic after being reviewed and + then the topic is merged (again) to 'next'. After going through + the usual testing in 'next', the entire (fixed) topic is merged + to 'master'. + + - One release cycle for a feature release is expected to last for + eight to ten weeks. A few "release candidate" releases are + expected to be tagged about a week apart before the final + release, and a "preview" release is tagged about a week before + the first release candidate gets tagged. + + - After the preview release is tagged, topics that were well + reviewed may be merged to 'master' before spending the usual 7 + calendar days in 'next', with the expectation that any bugs in + them can be caught and fixed in the release candidates before + the final release. + + - After the first release candidate is tagged, the contributors are + strongly encouraged to focus on finding and fixing new regressions + introduced during the cycle, over addressing old bugs and any new + features. Topics stop getting merged down from 'next' to 'master', + and new topics stop getting merged to 'next'. Unless they are fixes + to new regressions in the cycle, that is. + + - Soon after a feature release is made, the tip of 'maint' gets + fast-forwarded to point at the release. Topics that have been + kept in 'next' are merged down to 'master' and a new development + cycle starts. + + 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. +Because most of the lines of code in Git are written by individual +contributors, and contributions come in the form of e-mailed patches +published on the mailing list, the project maintains a mapping from +individual commits to the Message-Id of the e-mail that resulted in +the commit, to help tracking the origin of the changes. The notes +in "refs/notes/amlog" are used for this purpose, and are published +along with the broken-out branches to the maintainer's repository. A Typical Git Day ----------------- @@ -104,7 +158,7 @@ by doing the following: files in mbox format). - Write his own patches to address issues raised on the list but - nobody has stepped up solving. Send it out just like other + nobody has stepped up to solve. Send it out just like other contributors do, and pick them up just like patches from other contributors (see above). @@ -133,6 +187,43 @@ by doing the following: In practice, almost no patch directly goes to 'master' or 'maint'. + Applying the e-mailed patches using "git am" automatically records + the mappings from 'Message-Id' to the applied commit in the "amlog" + notes. Periodically check that this is working with "git show -s + --notes=amlog $commit". + + This mapping is maintained with the aid of the "post-applypatch" + hook found in the 'todo' branch. That hook should be installed + before applying patches. It is also helpful to carry forward any + relevant amlog entries when rebasing, so the following config may + be useful: + + [notes] + rewriteRef = refs/notes/amlog + + Avoid "cherry-pick", as it does not propagate notes by design. Use + either "git commit --amend" or "git rebase" to make corrections to + an existing commit, even for a single-patch topic. + + Make sure that a push refspec for 'refs/notes/amlog' is in the + remote configuration for publishing repositories. A few sample + configurations look like the following: + + [remote "github"] + url = https://github.com/gitster/git + pushurl = github.com:gitster/git.git + mirror + + [remote "github2"] + url = https://github.com/git/git + fetch = +refs/heads/*:refs/remotes/github2/* + pushurl = github.com:git/git.git + push = refs/heads/maint:refs/heads/maint + push = refs/heads/master:refs/heads/master + push = refs/heads/next:refs/heads/next + push = +refs/heads/seen:refs/heads/seen + push = +refs/notes/amlog + - Review the last issue of "What's cooking" message, review the topics ready for merging (topic->master and topic->maint). Use "Meta/cook -w" script (where Meta/ contains a checkout of the @@ -149,6 +240,10 @@ by doing the following: $ git diff ORIG_HEAD.. ;# final review $ make test ;# final review + If the tip of 'master' is updated, also generate the preformatted + documentation and push the out result to git-htmldocs and + git-manpages repositories. + - Handle the remaining patches: - Anything unobvious that is applicable to 'master' (in other @@ -179,12 +274,12 @@ by doing the following: The initial round is done with: $ git checkout ai/topic ;# or "git checkout -b ai/topic master" - $ git am -sc3 mailbox + $ git am -sc3 --whitespace=warn mailbox 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 + $ git am -sc3 --whitespace=warn mailbox to prepare the new round on a detached HEAD, and then @@ -209,39 +304,59 @@ by doing the following: (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 expectation is that the original author will make corrections + in a reroll. + - By now, new topic branches are created and existing topic + branches are updated. The integration branches 'next', 'jch', + and 'seen' need to be updated to contain them. - - Merge maint to master as needed: + - If there are topics that have been merged to 'master' and should + be merged to 'maint', merge them to 'maint', and update the + release notes to the next maintenance release. - $ git checkout master - $ git merge maint - $ make test + - Review the latest issue of "What's cooking" again. Are topics + that have been sufficiently long in 'next' ready to be merged to + 'master'? Are topics we saw earlier and are in 'seen' now got + positive reviews and are ready to be merged to 'next'? - - Merge master to next as needed: + - If there are topics that have been cooking in 'next' long enough + and should be merged to 'master', merge them to 'master', and + update the release notes to the next feature release. - $ git checkout next - $ git merge master - $ make test + - If there were patches directly made on 'maint', merge 'maint' to + 'master'; make sure that the result is what you want. - - Review the last issue of "What's cooking" again and see if topics - that are ready to be merged to 'next' are still in good shape - (e.g. has there any new issue identified on the list with the - series?) + $ git checkout master + $ git merge -m "Sync with 'maint'" --no-log maint + $ git log -p --first-parent ORIG_HEAD.. + $ make test - - Prepare 'jch' branch, which is used to represent somewhere - between 'master' and 'seen' and often is slightly ahead of 'next'. + - Prepare to update the 'jch' branch, which is used to represent + somewhere between 'master' and 'seen' and often is slightly ahead + of 'next', and the 'seen' branch, which is used to hold the rest. $ Meta/Reintegrate master..jch >Meta/redo-jch.sh The result is a script that lists topics to be merged in order to - 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. + rebuild the current 'jch'. Do the same for 'seen'. + + - Review the Meta/redo-jch.sh and Meta/redo-seen.sh scripts. The + former should have a line '### match next'---the idea is that + merging the topics listed before the line on top of 'master' + should result in a tree identical to that of 'next'. - - Now we are ready to start merging topics to 'next'. For each - branch whose tip is not merged to 'next', one of three things can - happen: + - As newly created topics are usually merged near the tip of + 'seen', add them to the end of the Meta/redo-seen.sh script. + Among the topics that were in 'seen', there may be ones that + are not quite ready for 'next' but are getting there. Move + them from Meta/redo-seen.sh to the end of Meta/redo-jch.sh. + The expectation is that you'd use 'jch' as your daily driver + as the first guinea pig, so you should choose carefully. + + - Now we are ready to start rebuilding 'jch' and merging topics to + 'next'. For each branch whose tip is not merged to 'next', one + of three things can happen: - The commits are all next-worthy; merge the topic to next; - The new parts are of mixed quality, but earlier ones are @@ -252,10 +367,12 @@ by doing the following: If a topic that was already in 'next' gained a patch, the script would list it as "ai/topic~1". To include the new patch to the updated 'next', drop the "~1" part; to keep it excluded, do not - touch the line. If a topic that was not in 'next' should be - merged to 'next', add it at the end of the list. Then: + touch the line. + + If a topic that was not in 'next' should be merged to 'next', add + it before the '### match next' line. Then: - $ git checkout -B jch master + $ git checkout --detach master $ sh Meta/redo-jch.sh -c1 to rebuild the 'jch' branch from scratch. "-c1" tells the script @@ -267,26 +384,29 @@ by doing the following: reference to the variable under its old name), in which case prepare an appropriate merge-fix first (see appendix), and rebuild the 'jch' branch from scratch, starting at the tip of - 'master'. + 'master', this time without using "-c1" to merge all topics. - Then do the same to 'next' + Then do the same to 'next'. $ git checkout next $ sh Meta/redo-jch.sh -c1 -e The "-e" option allows the merge message that comes from the history of the topic and the comments in the "What's cooking" to - be edited. The resulting tree should match 'jch' as the same set - of topics are merged on 'master'; otherwise there is a mismerge. - Investigate why and do not proceed until the mismerge is found - and rectified. + be edited. The resulting tree should match 'jch^{/^### match next'}' + as the same set of topics are merged on 'master'; otherwise there + is a mismerge. Investigate why and do not proceed until the mismerge + is found and rectified. + + If 'master' was updated before you started redoing 'next', then - $ git diff jch next + $ git diff 'jch^{/^### match next}' next - Then build the rest of 'jch': + would show differences that went into 'master' (which 'jch' has, + but 'next' does not yet---often it is updates to the release + notes). Merge 'master' back to 'next' if that is the case. - $ git checkout jch - $ sh Meta/redo-jch.sh + $ git merge -m "Sync with 'master'" --no-log master When all is well, clean up the redo-jch.sh script with @@ -296,12 +416,7 @@ by doing the following: merged to 'master'. This may lose '### match next' marker; add it again to the appropriate place when it happens. - - Rebuild 'seen'. - - $ Meta/Reintegrate jch..seen >Meta/redo-seen.sh - - Edit the result by adding new topics that are not still in 'seen' - in the script. Then + - Rebuild 'seen' on top of 'jch'. $ git checkout -B seen jch $ sh Meta/redo-seen.sh @@ -312,7 +427,7 @@ by doing the following: Double check by running - $ git branch --no-merged seen + $ git branch --no-merged seen '??/*' to see there is no unexpected leftover topics. @@ -411,13 +526,13 @@ Preparing a "merge-fix" A merge of two topics may not textually conflict but still have conflict at the semantic level. A classic example is for one topic -to rename an variable and all its uses, while another topic adds a +to rename a variable and all its uses, while another topic adds a new use of the variable under its old name. When these two topics are merged together, the reference to the variable newly added by the latter topic will still use the old name in the result. The Meta/Reintegrate script that is used by redo-jch and redo-seen -scripts implements a crude but usable way to work this issue around. +scripts implements a crude but usable way to work around this issue. When the script merges branch $X, it checks if "refs/merge-fix/$X" exists, and if so, the effect of it is squashed into the result of the mechanical merge. In other words, diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt index 151ee84ceb..4e727deedd 100644 --- a/Documentation/howto/update-hook-example.txt +++ b/Documentation/howto/update-hook-example.txt @@ -100,7 +100,7 @@ info "The user is: '$username'" if test -f "$allowed_users_file" then - rc=$(cat $allowed_users_file | grep -v '^#' | grep -v '^$' | + rc=$(grep -Ev '^(#|$)' $allowed_users_file | while read heads user_patterns do # does this rule apply to us? @@ -138,7 +138,7 @@ info "'$groups'" if test -f "$allowed_groups_file" then - rc=$(cat $allowed_groups_file | grep -v '^#' | grep -v '^$' | + rc=$(grep -Ev '^(#|$)' $allowed_groups_file | while read heads group_patterns do # does this rule apply to us? diff --git a/Documentation/howto/use-git-daemon.txt b/Documentation/howto/use-git-daemon.txt index 7af2e52cf3..2cad9b3ca5 100644 --- a/Documentation/howto/use-git-daemon.txt +++ b/Documentation/howto/use-git-daemon.txt @@ -4,7 +4,7 @@ How to use git-daemon ===================== Git can be run in inetd mode and in stand alone mode. But all you want is -let a coworker pull from you, and therefore need to set up a Git server +to let a coworker pull from you, and therefore need to set up a Git server real quick, right? Note that git-daemon is not really chatty at the moment, especially when diff --git a/Documentation/howto/using-merge-subtree.txt b/Documentation/howto/using-merge-subtree.txt index a499a94ac2..3bd581ac35 100644 --- a/Documentation/howto/using-merge-subtree.txt +++ b/Documentation/howto/using-merge-subtree.txt @@ -11,7 +11,7 @@ Message-ID: <BAYC1-PASMTP12374B54BA370A1E1C6E78AE4E0@CEZ.ICE> How to use the subtree merge strategy ===================================== -There are situations where you want to include contents in your project +There are situations where you want to include content in your project from an independently developed project. You can just pull from the other project as long as there are no conflicting paths. diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt index 6c6baeeeb7..3a866af4a4 100644 --- a/Documentation/i18n.txt +++ b/Documentation/i18n.txt @@ -34,7 +34,7 @@ project find it more convenient to use legacy encodings, Git does not forbid it. However, there are a few things to keep in mind. -. 'git commit' and 'git commit-tree' issues +. 'git commit' and 'git commit-tree' issue a warning if the commit log message given to it does not look like a valid UTF-8 string, unless you explicitly say your project uses a legacy encoding. The way to say this is to @@ -46,7 +46,7 @@ mind. ------------ + Commit objects created with the above setting record the value -of `i18n.commitEncoding` in its `encoding` header. This is to +of `i18n.commitEncoding` in their `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. diff --git a/Documentation/lint-manpages.sh b/Documentation/lint-manpages.sh new file mode 100755 index 0000000000..92cfc0a15a --- /dev/null +++ b/Documentation/lint-manpages.sh @@ -0,0 +1,108 @@ +#!/bin/sh + +extract_variable () { + ( + cat ../Makefile + cat <<EOF +print_variable: + @\$(foreach b,\$($1),echo XXX \$(b:\$X=) YYY;) +EOF + ) | + make -C .. -f - print_variable 2>/dev/null | + sed -n -e 's/.*XXX \(.*\) YYY.*/\1/p' +} + +check_missing_docs () ( + ret=0 + + for v in $ALL_COMMANDS + do + case "$v" in + git-merge-octopus) continue;; + git-merge-ours) continue;; + git-merge-recursive) continue;; + git-merge-resolve) continue;; + git-merge-subtree) continue;; + git-fsck-objects) continue;; + git-init-db) continue;; + git-remote-*) continue;; + git-stage) continue;; + git-legacy-*) continue;; + git-?*--?* ) continue ;; + esac + + if ! test -f "$v.txt" + then + echo "no doc: $v" + ret=1 + fi + + if ! sed -e '1,/^### command list/d' -e '/^#/d' ../command-list.txt | + grep -q "^$v[ ]" + then + case "$v" in + git) + ;; + *) + echo "no link: $v" + ret=1 + ;; + esac + fi + done + + exit $ret +) + +check_extraneous_docs () { + ( + sed -e '1,/^### command list/d' \ + -e '/^#/d' \ + -e '/guide$/d' \ + -e '/interfaces$/d' \ + -e 's/[ ].*//' \ + -e 's/^/listed /' ../command-list.txt + make print-man1 | + grep '\.txt$' | + sed -e 's|^|documented |' \ + -e 's/\.txt//' + ) | ( + all_commands="$(printf "%s " "$ALL_COMMANDS" "$BUILT_INS" "$EXCLUDED_PROGRAMS" | tr '\n' ' ')" + ret=0 + + while read how cmd + do + case " $all_commands " in + *" $cmd "*) ;; + *) + echo "removed but $how: $cmd" + ret=1;; + esac + done + + exit $ret + ) +} + +BUILT_INS="$(extract_variable BUILT_INS)" +ALL_COMMANDS="$(extract_variable ALL_COMMANDS)" +EXCLUDED_PROGRAMS="$(extract_variable EXCLUDED_PROGRAMS)" + +findings=$( + if ! check_missing_docs + then + ret=1 + fi + + if ! check_extraneous_docs + then + ret=1 + fi + + exit $ret +) +ret=$? + +printf "%s" "$findings" | sort + +exit $ret diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index d8f7cd7ca0..3eaefc4e94 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -191,7 +191,7 @@ endif::git-pull[] --autostash:: --no-autostash:: Automatically create a temporary stash entry before the operation - begins, record it in the special ref `MERGE_AUTOSTASH` + begins, record it in the ref `MERGE_AUTOSTASH` 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 diff --git a/Documentation/mergetools/vimdiff.txt b/Documentation/mergetools/vimdiff.txt index 2d631e9b1f..befa86d692 100644 --- a/Documentation/mergetools/vimdiff.txt +++ b/Documentation/mergetools/vimdiff.txt @@ -32,10 +32,10 @@ have special meaning: - `+` is used to "open a new tab" - `,` is used to "open a new vertical split" - `/` is used to "open a new horizontal split" - - `@` is used to indicate which is the file containing the final version after + - `@` is used to indicate the file containing the final version after solving the conflicts. If not present, `MERGED` will be used by default. -The precedence of the operators is this one (you can use parentheses to change +The precedence of the operators is as follows (you can use parentheses to change it): `@` > `+` > `/` > `,` @@ -162,7 +162,7 @@ information as the first tab, with a different layout. | REMOTE | | --------------------------------------------- .... -Note how in the third tab definition we need to use parenthesis to make `,` +Note how in the third tab definition we need to use parentheses to make `,` have precedence over `/`. -- @@ -177,7 +177,8 @@ Instead of `--tool=vimdiff`, you can also use one of these other variants: When using these variants, in order to specify a custom layout you will have to set configuration variables `mergetool.gvimdiff.layout` and -`mergetool.nvimdiff.layout` instead of `mergetool.vimdiff.layout` +`mergetool.nvimdiff.layout` instead of `mergetool.vimdiff.layout` (though the +latter will be used as fallback if the variant-specific one is not set). In addition, for backwards compatibility with previous Git versions, you can also append `1`, `2` or `3` to either `vimdiff` or any of the variants (ex: diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index 3b71334459..8ee940b6a4 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -122,7 +122,9 @@ The placeholders are: - Placeholders that expand to a single literal character: '%n':: newline '%%':: a raw '%' -'%x00':: print a byte from a hex code +'%x00':: '%x' followed by two hexadecimal digits is replaced with a + byte with the hexadecimal digits' value (we will call this + "literal formatting code" in the rest of this document). - Placeholders that affect formatting of later placeholders: '%Cred':: switch color to red @@ -222,13 +224,30 @@ The placeholders are: linkgit:git-rev-list[1]) '%d':: ref names, like the --decorate option of linkgit:git-log[1] '%D':: ref names without the " (", ")" wrapping. -'%(describe[:options])':: human-readable name, like - linkgit:git-describe[1]; empty string for - undescribable commits. The `describe` string - may be followed by a colon and zero or more - comma-separated options. Descriptions can be - inconsistent when tags are added or removed at - the same time. +'%(decorate[:<options>])':: +ref names with custom decorations. The `decorate` string may be followed by a +colon and zero or more comma-separated options. Option values may contain +literal formatting codes. These must be used for commas (`%x2C`) and closing +parentheses (`%x29`), due to their role in the option syntax. ++ +** 'prefix=<value>': Shown before the list of ref names. Defaults to "{nbsp}`(`". +** 'suffix=<value>': Shown after the list of ref names. Defaults to "`)`". +** 'separator=<value>': Shown between ref names. Defaults to "`,`{nbsp}". +** 'pointer=<value>': Shown between HEAD and the branch it points to, if any. + Defaults to "{nbsp}`->`{nbsp}". +** 'tag=<value>': Shown before tag names. Defaults to "`tag:`{nbsp}". + ++ +For example, to produce decorations with no wrapping +or tag annotations, and spaces as separators: ++ +`%(decorate:prefix=,suffix=,tag=,separator= )` + +'%(describe[:<options>])':: +human-readable name, like linkgit:git-describe[1]; empty string for +undescribable commits. The `describe` string may be followed by a colon and +zero or more comma-separated options. Descriptions can be inconsistent when +tags are added or removed at the same time. + ** 'tags[=<bool-value>]': Instead of only considering annotated tags, consider lightweight tags as well. @@ -281,13 +300,11 @@ endif::git-rev-list[] '%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. - If any option is provided multiple times the - last occurrence wins. +'%(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. If any option is provided +multiple times, the last occurrence wins. + ** 'key=<key>': only show trailers with specified <key>. Matching is done case-insensitively and trailing colon is optional. If option is @@ -299,9 +316,8 @@ endif::git-rev-list[] `Reviewed-by`. ** 'only[=<bool>]': select whether non-trailer lines from the trailer block should be included. -** '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 +** 'separator=<sep>': specify the separator inserted between trailer + lines. Defaults to 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. E.g., `%(trailers:key=Ticket,separator=%x2C )` @@ -312,10 +328,9 @@ endif::git-rev-list[] `%(trailers:only,unfold=true)` unfolds and shows all trailer lines. ** 'keyonly[=<bool>]': only show the key part of the trailer. ** 'valueonly[=<bool>]': only show the value part of the trailer. -** 'key_value_separator=<sep>': specify a separator inserted between - trailer lines. When this option is not given each trailer key-value - pair is separated by ": ". Otherwise it shares the same semantics - as 'separator=<sep>' above. +** 'key_value_separator=<sep>': specify the separator inserted between + the key and value of each trailer. Defaults to ": ". Otherwise it + shares the same semantics as 'separator=<sep>' above. NOTE: Some placeholders may depend on other options given to the revision traversal engine. For example, the `%g*` reflog options will diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt index dc685be363..23888cd612 100644 --- a/Documentation/pretty-options.txt +++ b/Documentation/pretty-options.txt @@ -48,7 +48,7 @@ people using 80-column terminals. --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>') + to fill to the next display column that is a 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`, @@ -73,7 +73,7 @@ environment overrides). See linkgit:git-config[1] for more details. 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. +`refs/notes/` is prefixed to form the 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 @@ -87,6 +87,10 @@ being displayed. Examples: "--notes=foo" will show only notes from "--notes --notes=foo --no-notes --notes=bar" will only show notes from "refs/notes/bar". +--show-notes-by-default:: + Show the default notes unless options for displaying specific + notes are given. + --show-notes[=<ref>]:: --[no-]standard-notes:: These options are deprecated. Use the above --notes/--no-notes diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt index 95a7390b2c..d79d2f6065 100644 --- a/Documentation/pull-fetch-param.txt +++ b/Documentation/pull-fetch-param.txt @@ -25,14 +25,15 @@ 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>. +by a colon `:`, followed by the destination <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 +typically a ref, or a glob pattern with a single `*` that is used +to match a set of refs, but it can also be a fully spelled hex object name. + A <refspec> may contain a `*` in its <src> to indicate a simple pattern match. Such a refspec functions like a glob that matches any ref with the -same prefix. A pattern <refspec> must have a `*` in both the <src> and +pattern. A pattern <refspec> must have one and only one `*` in both the <src> and <dst>. It will map refs to the destination by replacing the `*` with the contents matched from the source. + @@ -71,7 +72,7 @@ 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 +a commit for another commit that doesn't have the previous commit as an ancestor etc. + Unlike when pushing with linkgit:git-push[1], there is no @@ -80,7 +81,7 @@ configuration which'll amend these rules, and nothing like a + 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` +adding an optional leading `+` to a refspec (or using the `--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. @@ -88,7 +89,7 @@ object. [NOTE] When the remote branch you want to fetch is known to be rewound and rebased regularly, it is expected that -its new tip will not be descendant of its previous tip +its new tip will not be a 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 diff --git a/Documentation/ref-storage-format.txt b/Documentation/ref-storage-format.txt new file mode 100644 index 0000000000..14fff8a9c6 --- /dev/null +++ b/Documentation/ref-storage-format.txt @@ -0,0 +1,3 @@ +* `files` for loose files with packed-refs. This is the default. +* `reftable` for the reftable format. This format is experimental and its + internals are subject to change. diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index a4a0cb93b2..00ccf68744 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -56,7 +56,7 @@ 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 + Limit the commits output to ones with a 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 @@ -72,7 +72,7 @@ endif::git-rev-list[] instead of ones that match at least one. --invert-grep:: - Limit the commits output to ones with log message that do not + Limit the commits output to ones with a log message that do not match the pattern specified with `--grep=<pattern>`. -i:: @@ -151,6 +151,10 @@ endif::git-log[] --not:: Reverses the meaning of the '{caret}' prefix (or lack thereof) for all following revision specifiers, up to the next `--not`. + When used on the command line before --stdin, the revisions passed + through stdin will not be affected by it. Conversely, when passed + via standard input, the revisions passed on the command line will + not be affected by it. --all:: Pretend as if all the refs in `refs/`, along with `HEAD`, are @@ -240,7 +244,9 @@ endif::git-rev-list[] them from standard input as well. This accepts commits and pseudo-options like `--all` and `--glob=`. When a `--` separator is seen, the following input is treated as paths and used to - limit the result. + limit the result. Flags like `--not` which are read via standard input + are only respected for arguments passed in the same way and will not + influence any subsequent command line arguments. ifdef::git-rev-list[] --quiet:: @@ -310,12 +316,12 @@ list. 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. 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), +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 +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 @@ -335,8 +341,11 @@ 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. + Show commits touching conflicted paths in the range `HEAD...<other>`, + where `<other>` is the first existing pseudoref in `MERGE_HEAD`, + `CHERRY_PICK_HEAD`, `REVERT_HEAD` or `REBASE_HEAD`. Only works + when the index has unmerged entries. This option can be used to show + relevant commits when resolving conflicts from a 3-way merge. --boundary:: Output excluded boundary commits. Boundary commits are @@ -941,10 +950,10 @@ ifdef::git-rev-list[] + 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=blob:limit=<n>[kmg]' omits blobs of size at least 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=object:type=(tag|commit|tree|blob)' omits all objects which are not of the requested type. @@ -1013,6 +1022,10 @@ 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. ++ +If some tips passed to the traversal are missing, they will be +considered as missing too, and the traversal will ignore them. In case +we cannot get their Object ID though, an error will be raised. --exclude-promisor-objects:: (For internal use only.) Prefilter object traversal at diff --git a/Documentation/scalar.txt b/Documentation/scalar.txt index 361f51a647..7e4259c674 100644 --- a/Documentation/scalar.txt +++ b/Documentation/scalar.txt @@ -86,6 +86,13 @@ cloning. If the HEAD at the remote did not point at any branch when `<entlistment>/src` directory. Use `--no-src` to place the cloned repository directly in the `<enlistment>` directory. +--[no-]tags:: + By default, `scalar clone` will fetch the tag objects advertised by + the remote and future `git fetch` commands will do the same. Use + `--no-tags` to avoid fetching tags in `scalar clone` and to configure + the repository to avoid fetching tags in the future. To fetch tags after + cloning with `--no-tags`, run `git fetch --tags`. + --[no-]full-clone:: A sparse-checkout is initialized by default. This behavior can be turned off via `--full-clone`. diff --git a/Documentation/signoff-option.txt b/Documentation/signoff-option.txt index 12aa2333e4..d98758f3cb 100644 --- a/Documentation/signoff-option.txt +++ b/Documentation/signoff-option.txt @@ -9,7 +9,7 @@ endif::git-commit[] the committer has the rights to submit the work under the project's license or agrees to some contributor representation, such as a Developer Certificate of Origin. - (See http://developercertificate.org for the one used by the + (See https://developercertificate.org for the one used by the Linux kernel and Git projects.) Consult the documentation or leadership of the project to which you're contributing to understand how the signoffs are used in that project. diff --git a/Documentation/technical/api-index-skel.txt b/Documentation/technical/api-index-skel.txt index eda8c195c1..7780a76b08 100644 --- a/Documentation/technical/api-index-skel.txt +++ b/Documentation/technical/api-index-skel.txt @@ -1,7 +1,7 @@ Git API Documents ================= -Git has grown a set of internal API over time. This collection +Git has grown a set of internal APIs over time. This collection documents them. //////////////////////////////////////////////////////////////// diff --git a/Documentation/technical/api-simple-ipc.txt b/Documentation/technical/api-simple-ipc.txt index d44ada98e7..c4fb152b23 100644 --- a/Documentation/technical/api-simple-ipc.txt +++ b/Documentation/technical/api-simple-ipc.txt @@ -2,7 +2,7 @@ Simple-IPC API ============== The Simple-IPC API is a collection of `ipc_` prefixed library routines -and a basic communication protocol that allow an IPC-client process to +and a basic communication protocol that allows an IPC-client process to send an application-specific IPC-request message to an IPC-server process and receive an application-specific IPC-response message. @@ -20,12 +20,12 @@ IPC-client. The IPC-client routines within a client application process connect to the IPC-server and send a request message and wait for a response. -When received, the response is returned back the caller. +When received, the response is returned back to the caller. For example, the `fsmonitor--daemon` feature will be built as a server application on top of the IPC-server library routines. It will have threads watching for file system events and a thread pool waiting for -client connections. Clients, such as `git status` will request a list +client connections. Clients, such as `git status`, will request a list of file system events since a point in time and the server will respond with a list of changed files and directories. The formats of the request and response are application-specific; the IPC-client and @@ -37,7 +37,7 @@ Comparison with sub-process model The Simple-IPC mechanism differs from the existing `sub-process.c` model (Documentation/technical/long-running-process-protocol.txt) and -used by applications like Git-LFS. In the LFS-style sub-process model +used by applications like Git-LFS. In the LFS-style sub-process model, the helper is started by the foreground process, communication happens via a pair of file descriptors bound to the stdin/stdout of the sub-process, the sub-process only serves the current foreground @@ -102,4 +102,4 @@ stateless request, receive an application-specific response, and disconnect. It is a one round trip facility for querying the server. The Simple-IPC routines hide the socket, named pipe, and thread pool details and allow the application -layer to focus on the application at hand. +layer to focus on the task at hand. diff --git a/Documentation/technical/api-trace2.txt b/Documentation/technical/api-trace2.txt index de5fc25059..5817b18310 100644 --- a/Documentation/technical/api-trace2.txt +++ b/Documentation/technical/api-trace2.txt @@ -128,7 +128,7 @@ yields ------------ $ cat ~/log.event -{"event":"version","sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.620713Z","file":"common-main.c","line":38,"evt":"3","exe":"2.20.1.155.g426c96fcdb"} +{"event":"version","sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.620713Z","file":"common-main.c","line":38,"evt":"4","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} @@ -344,7 +344,7 @@ only present on the "start" and "atexit" events. { "event":"version", ... - "evt":"3", # EVENT format version + "evt":"4", # EVENT format version "exe":"2.20.1.155.g426c96fcdb" # git version } ------------ @@ -835,6 +835,19 @@ The "value" field may be an integer or a string. } ------------ +`"printf"`:: + This event logs a human-readable message with no particular formatting + guidelines. ++ +------------ +{ + "event":"printf", + ... + "t_abs":0.015905, # elapsed time in seconds + "msg":"Hello world" # optional +} +------------ + == Example Trace2 API Usage diff --git a/Documentation/technical/bitmap-format.txt b/Documentation/technical/bitmap-format.txt index c2e652b71a..bfb0ec7beb 100644 --- a/Documentation/technical/bitmap-format.txt +++ b/Documentation/technical/bitmap-format.txt @@ -114,7 +114,7 @@ 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. +Where `N` is the total number of entries in this bitmap index. Each entry contains the following: ** {empty} @@ -126,7 +126,7 @@ Each entry contains the following: ** {empty} 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 + in position `x`, an 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). @@ -239,7 +239,7 @@ bitmaps. For a `.bitmap` containing `nr_entries` reachability bitmaps, the table contains a list of `nr_entries` <commit_pos, offset, xor_row> triplets -(sorted in the ascending order of `commit_pos`). The content of i'th +(sorted in the ascending order of `commit_pos`). The content of the i'th triplet is - * {empty} @@ -255,3 +255,144 @@ triplet is - xor_row (4 byte integer, network byte order): :: The position of the triplet whose bitmap is used to compress this one, or `0xffffffff` if no such bitmap exists. + +Pseudo-merge bitmaps +-------------------- + +If the `BITMAP_OPT_PSEUDO_MERGES` flag is set, a variable number of +bytes (preceding the name-hash cache, commit lookup table, and trailing +checksum) of the `.bitmap` file is used to store pseudo-merge bitmaps. + +For more information on what pseudo-merges are, why they are useful, and +how to configure them, see the information in linkgit:gitpacking[7]. + +=== File format + +If enabled, pseudo-merge bitmaps are stored in an optional section at +the end of a `.bitmap` file. The format is as follows: + +.... ++-------------------------------------------+ +| .bitmap File | ++-------------------------------------------+ +| | +| Pseudo-merge bitmaps (Variable Length) | +| +---------------------------+ | +| | commits_bitmap (EWAH) | | +| +---------------------------+ | +| | merge_bitmap (EWAH) | | +| +---------------------------+ | +| | ++-------------------------------------------+ +| | +| Lookup Table | +| +---------------------------+ | +| | commit_pos (4 bytes) | | +| +---------------------------+ | +| | offset (8 bytes) | | +| +------------+--------------+ | +| | +| Offset Cases: | +| ------------- | +| | +| 1. MSB Unset: single pseudo-merge bitmap | +| + offset to pseudo-merge bitmap | +| | +| 2. MSB Set: multiple pseudo-merges | +| + offset to extended lookup table | +| | ++-------------------------------------------+ +| | +| Extended Lookup Table (Optional) | +| +----+----------+----------+----------+ | +| | N | Offset 1 | .... | Offset N | | +| +----+----------+----------+----------+ | +| | | 8 bytes | .... | 8 bytes | | +| +----+----------+----------+----------+ | +| | ++-------------------------------------------+ +| | +| Pseudo-merge position table | +| +----+----------+----------+----------+ | +| | N | Offset 1 | .... | Offset N | | +| +----+----------+----------+----------+ | +| | | 8 bytes | .... | 8 bytes | | +| +----+----------+----------+----------+ | +| | ++-------------------------------------------+ +| | +| Pseudo-merge Metadata | +| +-----------------------------------+ | +| | # pseudo-merges (4 bytes) | | +| +-----------------------------------+ | +| | # commits (4 bytes) | | +| +-----------------------------------+ | +| | Lookup offset (8 bytes) | | +| +-----------------------------------+ | +| | Extension size (8 bytes) | | +| +-----------------------------------+ | +| | ++-------------------------------------------+ +.... + +* One or more pseudo-merge bitmaps, each containing: + + ** `commits_bitmap`, an EWAH-compressed bitmap describing the set of + commits included in the this psuedo-merge. + + ** `merge_bitmap`, an EWAH-compressed bitmap describing the union of + the set of objects reachable from all commits listed in the + `commits_bitmap`. + +* A lookup table, mapping pseudo-merged commits to the pseudo-merges + they belong to. Entries appear in increasing order of each commit's + bit position. Each entry is 12 bytes wide, and is comprised of the + following: + + ** `commit_pos`, a 4-byte unsigned value (in network byte-order) + containing the bit position for this commit. + + ** `offset`, an 8-byte unsigned value (also in network byte-order) + containing either one of two possible offsets, depending on whether or + not the most-significant bit is set. + + *** If unset (i.e. `offset & ((uint64_t)1<<63) == 0`), the offset + (relative to the beginning of the `.bitmap` file) at which the + pseudo-merge bitmap for this commit can be read. This indicates + only a single pseudo-merge bitmap contains this commit. + + *** If set (i.e. `offset & ((uint64_t)1<<63) != 0`), the offset + (again relative to the beginning of the `.bitmap` file) at which + the extended offset table can be located describing the set of + pseudo-merge bitmaps which contain this commit. This indicates + that multiple pseudo-merge bitmaps contain this commit. + +* An (optional) extended lookup table (written if and only if there is + at least one commit which appears in more than one pseudo-merge). + There are as many entries as commits which appear in multiple + pseudo-merges. Each entry contains the following: + + ** `N`, a 4-byte unsigned value equal to the number of pseudo-merges + which contain a given commit. + + ** An array of `N` 8-byte unsigned values, each of which is + interpreted as an offset (relative to the beginning of the + `.bitmap` file) at which a pseudo-merge bitmap for this commit can + be read. These values occur in no particular order. + +* Positions for all pseudo-merges, each stored as an 8-byte unsigned + value (in network byte-order) containing the offset (relative to the + beginning of the `.bitmap` file) of each consecutive pseudo-merge. + +* A 4-byte unsigned value (in network byte-order) equal to the number of + pseudo-merges. + +* A 4-byte unsigned value (in network byte-order) equal to the number of + unique commits which appear in any pseudo-merge. + +* An 8-byte unsigned value (in network byte-order) equal to the number + of bytes between the start of the pseudo-merge section and the + beginning of the lookup table. + +* An 8-byte unsigned value (in network byte-order) equal to the number + of bytes in the pseudo-merge section (including this field). diff --git a/Documentation/technical/commit-graph.txt b/Documentation/technical/commit-graph.txt index 86fed0de0f..2c26e95e51 100644 --- a/Documentation/technical/commit-graph.txt +++ b/Documentation/technical/commit-graph.txt @@ -136,7 +136,7 @@ Design Details - 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 + `--no-replace-objects`. This leads to difficulty 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. diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt index ed57481089..7102c7c8f5 100644 --- a/Documentation/technical/hash-function-transition.txt +++ b/Documentation/technical/hash-function-transition.txt @@ -148,8 +148,8 @@ 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`: +linkgit:gitrepository-layout[5]) with `extensions.objectFormat` and +`extensions.compatObjectFormat` (see linkgit:git-config[1]) set to: [core] repositoryFormatVersion = 1 diff --git a/Documentation/technical/multi-pack-index.txt b/Documentation/technical/multi-pack-index.txt index f2221d2b44..cc063b30be 100644 --- a/Documentation/technical/multi-pack-index.txt +++ b/Documentation/technical/multi-pack-index.txt @@ -61,6 +61,109 @@ Design Details - The MIDX file format uses a chunk-based approach (similar to the commit-graph file) that allows optional data to be added. +Incremental multi-pack indexes +------------------------------ + +As repositories grow in size, it becomes more expensive to write a +multi-pack index (MIDX) that includes all packfiles. To accommodate +this, the "incremental multi-pack indexes" feature allows for combining +a "chain" of multi-pack indexes. + +Each individual component of the chain need only contain a small number +of packfiles. Appending to the chain does not invalidate earlier parts +of the chain, so repositories can control how much time is spent +updating the MIDX chain by determining the number of packs in each layer +of the MIDX chain. + +=== Design state + +At present, the incremental multi-pack indexes feature is missing two +important components: + + - The ability to rewrite earlier portions of the MIDX chain (i.e., to + "compact" some collection of adjacent MIDX layers into a single + MIDX). At present the only supported way of shrinking a MIDX chain + is to rewrite the entire chain from scratch without the `--split` + flag. ++ +There are no fundamental limitations that stand in the way of being able +to implement this feature. It is omitted from the initial implementation +in order to reduce the complexity, but will be added later. + + - Support for reachability bitmaps. The classic single MIDX + implementation does support reachability bitmaps (see the section + titled "multi-pack-index reverse indexes" in + linkgit:gitformat-pack[5] for more details). ++ +As above, there are no fundamental limitations that stand in the way of +extending the incremental MIDX format to support reachability bitmaps. +The design below specifically takes this into account, and support for +reachability bitmaps will be added in a future patch series. It is +omitted from the current implementation for the same reason as above. ++ +In brief, to support reachability bitmaps with the incremental MIDX +feature, the concept of the pseudo-pack order is extended across each +layer of the incremental MIDX chain to form a concatenated pseudo-pack +order. This concatenation takes place in the same order as the chain +itself (in other words, the concatenated pseudo-pack order for a chain +`{$H1, $H2, $H3}` would be the pseudo-pack order for `$H1`, followed by +the pseudo-pack order for `$H2`, followed by the pseudo-pack order for +`$H3`). ++ +The layout will then be extended so that each layer of the incremental +MIDX chain can write a `*.bitmap`. The objects in each layer's bitmap +are offset by the number of objects in the previous layers of the chain. + +=== File layout + +Instead of storing a single `multi-pack-index` file (with an optional +`.rev` and `.bitmap` extension) in `$GIT_DIR/objects/pack`, incremental +MIDXs are stored in the following layout: + +---- +$GIT_DIR/objects/pack/multi-pack-index.d/ +$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-chain +$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-$H1.midx +$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-$H2.midx +$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-$H3.midx +---- + +The `multi-pack-index-chain` file contains a list of the incremental +MIDX files in the chain, in order. The above example shows a chain whose +`multi-pack-index-chain` file would contain the following lines: + +---- +$H1 +$H2 +$H3 +---- + +The `multi-pack-index-$H1.midx` file contains the first layer of the +multi-pack-index chain. The `multi-pack-index-$H2.midx` file contains +the second layer of the chain, and so on. + +When both an incremental- and non-incremental MIDX are present, the +non-incremental MIDX is always read first. + +=== Object positions for incremental MIDXs + +In the original multi-pack-index design, we refer to objects via their +lexicographic position (by object IDs) within the repository's singular +multi-pack-index. In the incremental multi-pack-index design, we refer +to objects via their index into a concatenated lexicographic ordering +among each component in the MIDX chain. + +If `objects_nr()` is a function that returns the number of objects in a +given MIDX layer, then the index of an object at lexicographic position +`i` within, say, $H3 is defined as: + +---- +objects_nr($H2) + objects_nr($H1) + i +---- + +(in the C implementation, this is often computed as `i + +m->num_objects_in_base`). + Future Work ----------- diff --git a/Documentation/technical/parallel-checkout.txt b/Documentation/technical/parallel-checkout.txt index 47c9b6183c..b4a144e5f4 100644 --- a/Documentation/technical/parallel-checkout.txt +++ b/Documentation/technical/parallel-checkout.txt @@ -63,7 +63,7 @@ improvements over the sequential code, but there was still too much lock contention. A `perf` profiling indicated that around 20% of the runtime during a local Linux clone (on an SSD) was spent in locking functions. For this reason this approach was rejected in favor of using multiple -child processes, which led to a better performance. +child processes, which led to better performance. Multi-Process Solution ---------------------- @@ -126,7 +126,7 @@ Then, for each assigned item, each worker: * W5: Writes the result to the file descriptor opened at W2. -* W6: Calls `fstat()` or lstat()` on the just-written path, and sends +* W6: Calls `fstat()` or `lstat()` on the just-written path, and sends the result back to the main process, together with the end status of the operation and the item's identification number. @@ -148,7 +148,7 @@ information, the main process handles the results in two steps: - First, it updates the in-memory index with the `lstat()` information sent by the workers. (This must be done first as this information - might me required in the following step.) + might be required in the following step.) - Then it writes the items which collided on disk (i.e. items marked with `PC_ITEM_COLLIDED`). More on this below. @@ -185,7 +185,7 @@ quite straightforward: for each parallel-eligible entry, the main process must remove all files that prevent this entry from being written (before enqueueing it). This includes any non-directory file in the leading path of the entry. Later, when a worker gets assigned the entry, -it looks again for the non-directories files and for an already existing +it looks again for the non-directory files and for an already existing file at the entry's path. If any of these checks finds something, the worker knows that there was a path collision. @@ -232,7 +232,7 @@ conversion and re-encoding, are eligible for parallel checkout. Ineligible entries are checked out by the classic sequential codepath *before* spawning workers. -Note: submodules's files are also eligible for parallel checkout (as +Note: submodules' files are also eligible for parallel checkout (as long as they don't fall into any of the excluding categories mentioned above). But since each submodule is checked out in its own child process, we don't mix the superproject's and the submodules' files in diff --git a/Documentation/technical/partial-clone.txt b/Documentation/technical/partial-clone.txt index 92fcee2bff..bf5ec5c82d 100644 --- a/Documentation/technical/partial-clone.txt +++ b/Documentation/technical/partial-clone.txt @@ -3,7 +3,7 @@ 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 +The goal of this work is to allow Git to better handle extremely large repositories. During clone and fetch operations, Git downloads the complete contents @@ -102,7 +102,7 @@ or commits that reference missing trees. - 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" + See `extensions.partialClone` in linkgit:git-config[1]. Handling Missing Objects @@ -256,7 +256,7 @@ remote in a specific order. - 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. + If there are a large number of refs, this may incur significant overhead. Future Work @@ -265,7 +265,7 @@ 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: +For example this could allow specifying 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." @@ -322,7 +322,7 @@ 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 + This would essentially be a sorted linear list of OIDs that were omitted by the server during a clone or subsequent fetches. This file would need to be loaded into memory on every object lookup. diff --git a/Documentation/technical/platform-support.txt b/Documentation/technical/platform-support.txt new file mode 100644 index 0000000000..0a2fb28d62 --- /dev/null +++ b/Documentation/technical/platform-support.txt @@ -0,0 +1,190 @@ +Platform Support Policy +======================= + +Git has a history of providing broad "support" for exotic platforms and older +platforms, without an explicit commitment. Stakeholders of these platforms may +want a more predictable support commitment. This is only possible when platform +stakeholders supply Git developers with adequate tooling, so we can test for +compatibility or develop workarounds for platform-specific quirks on our own. +Various levels of platform-specific tooling will allow us to make more solid +commitments around Git's compatibility with that platform. + +Note that this document is about maintaining existing support for a platform +that has generally worked in the past; for adding support to a platform which +doesn't generally work with Git, the stakeholders for that platform are expected +to do the bulk of that work themselves. We will consider such patches if they +don't make life harder for other supported platforms or for Git contributors. +Some contributors may volunteer to help with the initial or continued support, +but that's not a given. Support work which is too intrusive or difficult for the +project to maintain may still not be accepted. + +Minimum Requirements +-------------------- + +The rest of this doc describes best practices for platforms to make themselves +easy to support. However, before considering support at all, platforms need to +meet the following minimum requirements: + +* Has C99 or C11 + +* Uses versions of dependencies which are generally accepted as stable and + supportable, e.g., in line with the version used by other long-term-support + distributions + +* Has active security support (taking security releases of dependencies, etc) + +These requirements are a starting point, and not sufficient on their own for the +Git community to be enthusiastic about supporting your platform. Maintainers of +platforms which do meet these requirements can follow the steps below to make it +more likely that Git updates will respect the platform's needs. + +Compatible by next release +-------------------------- + +To increase probability that compatibility issues introduced in a release +will be fixed in a later release: + +* You should send a bug report as soon as you notice the breakage on your + platform. The sooner you notice, the better; watching `seen` means you can + notice problems before they are considered "done with review"; whereas + watching `master` means the stable branch could break for your platform, but + you have a decent chance of avoiding a tagged release breaking you. See "The + Policy" in link:../howto/maintain-git.html["How to maintain Git"] for an + overview of which branches are used in the Git project, and how. + +* The bug report should include information about what platform you are using. + +* You should also use linkgit:git-bisect[1] and determine which commit + introduced the breakage. + +* Please include any information you have about the nature of the breakage: is + it a memory alignment issue? Is an underlying library missing or broken for + your platform? Is there some quirk about your platform which means typical + practices (like malloc) behave strangely? + +* If possible, build Git from the exact same source both for your platform and + for a mainstream platform, to see if the problem you noticed appears only + on your platform. If the problem appears in both, then it's not a + compatibility issue, but we of course appreciate hearing about it in a bug + report anyway, to benefit users of every platform. If it appears only on your + platform, mention clearly that it is a compatibility issue in your report. + +* Once we begin to fix the issue, please work closely with the contributor + working on it to test the proposed fix against your platform. + +Example: NonStop +https://lore.kernel.org/git/01bd01da681a$b8d70a70$2a851f50$@nexbridge.com/[reports +problems] when they're noticed. + +Compatible on `master` and releases +----------------------------------- + +To make sure all stable builds and regular releases work for your platform the +first time, help us avoid breaking `master` for your platform: + +* You should run regular tests against the `next` branch and + publish breakage reports to the mailing list immediately when they happen. + +** Ideally, these tests should run daily. They must run more often than + weekly, as topics generally spend at least 7 days in `next` before graduating + to `master`, and it takes time to put the brakes on a patch once it lands in + `next`. + +** You may want to ask to join the mailto:git-security@googlegroups.com[security + mailing list] in order to run tests against the fixes proposed there, too. + +* It may make sense to automate these; if you do, make sure they are not noisy + (you don't need to send a report when everything works, only when something + breaks; you don't need to send repeated reports for the same breakage night + after night). + +* Breakage reports should be actionable - include clear error messages that can + help developers who may not have access to test directly on your platform. + +* You should use git-bisect and determine which commit introduced the breakage; + if you can't do this with automation, you should do this yourself manually as + soon as you notice a breakage report was sent. + +* You should either: + +** Provide on-demand access to your platform to a trusted developer working to + fix the issue, so they can test their fix, OR + +** Work closely with the developer fixing the issue; the turnaround to check + that their proposed fix works for your platform should be fast enough that it + doesn't hinder the developer working on that fix. Slow testing turnarounds + may cause the fix to miss the next release, or the developer may lose + interest in working on the fix at all. + +Example: +https://lore.kernel.org/git/CAHd-oW6X4cwD_yLNFONPnXXUAFPxgDoccv2SOdpeLrqmHCJB4Q@mail.gmail.com/[AIX] +provides a build farm and runs tests against release candidates. + +Compatible on `next` +-------------------- + +To avoid reactive debugging and fixing when changes hit a release or stable, you +can aim to ensure `next` always works for your platform. (See "The Policy" in +link:../howto/maintain-git.html["How to maintain Git"] for an overview of how +`next` is used in the Git project.) To do that: + +* You should add a runner for your platform to the GitHub Actions or GitLab CI + suite. This suite is run when any Git developer proposes a new patch, and + having a runner for your platform/configuration means every developer will + know if they break you, immediately. + +** If adding it to an existing CI suite is infeasible (due to architecture + constraints or for performance reasons), any other method which runs as + automatically and quickly as possible works, too. For example, a service + which snoops on the mailing list and automatically runs tests on new [PATCH] + emails, replying to the author with the results, would also be within the + spirit of this requirement. + +* If you rely on Git avoiding a specific pattern that doesn't work well with + your platform (like a certain malloc pattern), raise it on the mailing list. + We'll work case-by-case to look for a solution that doesn't unnecessarily + constrain other platforms to keep compatibility with yours. + +* If you rely on some configuration or behavior, add a test for it. Untested + behavior is subject to breakage at any time. + +** Clearly label these tests as necessary for platform compatibility. Add them + to an isolated compatibility-related test suite, like a new t* file or unit + test suite, so that they're easy to remove when compatibility is no longer + required. If the specific compatibility need is gated behind an issue with + another project, link to documentation of that issue (like a bug or email + thread) to make it easier to tell when that compatibility need goes away. + +** Include a comment with an expiration date for these tests no more than 1 year + from now. You can update the expiration date if your platform still needs + that assurance down the road, but we need to know you still care about that + compatibility case and are working to make it unnecessary. + +Example: We run our +https://git.kernel.org/pub/scm/git/git.git/tree/.github/workflows/main.yml[CI +suite] on Windows, Ubuntu, Mac, and others. + +Getting help writing platform support patches +--------------------------------------------- + +In general, when sending patches to fix platform support problems, follow +these guidelines to make sure the patch is reviewed with the appropriate level +of urgency: + +* Clearly state in the commit message that you are fixing a platform breakage, + and for which platform. + +* Use the CI and test suite to ensure that the fix for your platform doesn't + break other platforms. + +* If possible, add a test ensuring this regression doesn't happen again. If + it's not possible to add a test, explain why in the commit message. + +Platform Maintainers +-------------------- + +If you maintain a platform, or Git for that platform, and intend to work with +the Git project to ensure compatibility, please send a patch to add yourself to +this list. + +NonStop: Randall S. Becker <rsbecker@nexbridge.com> diff --git a/Documentation/technical/racy-git.txt b/Documentation/technical/racy-git.txt index ceda4bbfda..59bea66c0f 100644 --- a/Documentation/technical/racy-git.txt +++ b/Documentation/technical/racy-git.txt @@ -11,7 +11,7 @@ write out the next tree object to be committed. The state is "virtual" in the sense that it does not necessarily have to, and often does not, match the files in the working tree. -There are cases Git needs to examine the differences between the +There are cases where Git needs to examine the differences between the virtual working tree state in the index and the files in the working tree. The most obvious case is when the user asks `git diff` (or its low level implementation, `git diff-files`) or @@ -165,9 +165,9 @@ Avoiding runtime penalty In order to avoid the above runtime penalty, post 1.4.2 Git used to have a code that made sure the index file -got timestamp newer than the youngest files in the index when -there are many young files with the same timestamp as the -resulting index file would otherwise would have by waiting +got a timestamp newer than the youngest files in the index when +there were many young files with the same timestamp as the +resulting index file otherwise would have by waiting before finishing writing the index file out. I suspected that in practice the situation where many paths in the @@ -190,7 +190,7 @@ In a large project where raciness avoidance cost really matters, however, the initial computation of all object names in the index takes more than one second, and the index file is written out after all that happens. Therefore the timestamp of the -index file will be more than one seconds later than the +index file will be more than one second later than the youngest file in the working tree. This means that in these cases there actually will not be any racily clean entry in the resulting index. diff --git a/Documentation/technical/reftable.txt b/Documentation/technical/reftable.txt index 6a67cc4174..dd0b37c4e3 100644 --- a/Documentation/technical/reftable.txt +++ b/Documentation/technical/reftable.txt @@ -46,7 +46,7 @@ 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. +size and alignment are tunable by the writer. Performance ^^^^^^^^^^^ @@ -115,7 +115,7 @@ Varint encoding Varint encoding is identical to the ofs-delta encoding method used within pack files. -Decoder works such as: +Decoder works as follows: .... val = buf[ptr] & 0x7f @@ -175,7 +175,7 @@ log_index* footer .... -in a log-only file the first log block immediately follows the file +In a log-only file, the first log block immediately follows the file header, without padding to block alignment. Block size @@ -247,7 +247,7 @@ 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. +("sha1" for SHA1 and "s256" for SHA-256) appended to the header. For maximum backward compatibility, it is recommended to use version 1 when writing SHA1 reftables. @@ -288,7 +288,7 @@ The 2-byte `restart_count` stores the number of entries in the `restart_count` to binary search between restarts before starting a linear scan. -Exactly `restart_count` 3-byte `restart_offset` values precedes the +Exactly `restart_count` 3-byte `restart_offset` values precede 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, diff --git a/Documentation/technical/repository-version.txt b/Documentation/technical/repository-version.txt index 8ef664b0b9..b9bb81a81f 100644 --- a/Documentation/technical/repository-version.txt +++ b/Documentation/technical/repository-version.txt @@ -65,38 +65,6 @@ Note that if no extensions are specified in the config file, then 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) +The defined extensions are given in the `extensions.*` section of +linkgit:git-config[1]. Any implementation wishing to define a new +extension should make a note of it there, in order to claim the name. diff --git a/Documentation/technical/rerere.txt b/Documentation/technical/rerere.txt index be58f1bee3..580f23360a 100644 --- a/Documentation/technical/rerere.txt +++ b/Documentation/technical/rerere.txt @@ -60,7 +60,7 @@ By resolving this conflict, to leave line D, the user declares: 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. +this is also compatible with 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 @@ -76,7 +76,7 @@ examples would both result in the following normalized conflict: Sorting hunks ~~~~~~~~~~~~~ -As before, lets imagine that a common ancestor had a file with line A +As before, let's 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: @@ -145,7 +145,7 @@ 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 +version, and 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. diff --git a/Documentation/technical/sparse-checkout.txt b/Documentation/technical/sparse-checkout.txt index fa0d01cbda..d968659354 100644 --- a/Documentation/technical/sparse-checkout.txt +++ b/Documentation/technical/sparse-checkout.txt @@ -287,7 +287,7 @@ everything behaves like a dense checkout with a few exceptions (e.g. branch checkouts and switches write fewer things, knowing the VFS will lazily write the rest on an as-needed basis). -Since there is no publically available VFS-related code for folks to try, +Since there is no publicly available VFS-related code for folks to try, the number of folks who can test such a usecase is limited. The primary reason to note the Behavior C usecase is that as we fix things diff --git a/Documentation/technical/unit-tests.txt b/Documentation/technical/unit-tests.txt new file mode 100644 index 0000000000..5a432b7b29 --- /dev/null +++ b/Documentation/technical/unit-tests.txt @@ -0,0 +1,242 @@ += Unit Testing + +In our current testing environment, we spend a significant amount of effort +crafting end-to-end tests for error conditions that could easily be captured by +unit tests (or we simply forgo some hard-to-setup and rare error conditions). +Unit tests additionally provide stability to the codebase and can simplify +debugging through isolation. Writing unit tests in pure C, rather than with our +current shell/test-tool helper setup, simplifies test setup, simplifies passing +data around (no shell-isms required), and reduces testing runtime by not +spawning a separate process for every test invocation. + +We believe that a large body of unit tests, living alongside the existing test +suite, will improve code quality for the Git project. + +== Definitions + +For the purposes of this document, we'll use *test framework* to refer to +projects that support writing test cases and running tests within the context +of a single executable. *Test harness* will refer to projects that manage +running multiple executables (each of which may contain multiple test cases) and +aggregating their results. + +In reality, these terms are not strictly defined, and many of the projects +discussed below contain features from both categories. + +For now, we will evaluate projects solely on their framework features. Since we +are relying on having TAP output (see below), we can assume that any framework +can be made to work with a harness that we can choose later. + + +== Summary + +We believe the best way forward is to implement a custom TAP framework for the +Git project. We use a version of the framework originally proposed in +https://lore.kernel.org/git/c902a166-98ce-afba-93f2-ea6027557176@gmail.com/[1]. + +See the <<framework-selection,Framework Selection>> section below for the +rationale behind this decision. + + +== Choosing a test harness + +During upstream discussion, it was occasionally noted that `prove` provides many +convenient features, such as scheduling slower tests first, or re-running +previously failed tests. + +While we already support the use of `prove` as a test harness for the shell +tests, it is not strictly required. The t/Makefile allows running shell tests +directly (though with interleaved output if parallelism is enabled). Git +developers who wish to use `prove` as a more advanced harness can do so by +setting DEFAULT_TEST_TARGET=prove in their config.mak. + +We will follow a similar approach for unit tests: by default the test +executables will be run directly from the t/Makefile, but `prove` can be +configured with DEFAULT_UNIT_TEST_TARGET=prove. + + +[[framework-selection]] +== Framework selection + +There are a variety of features we can use to rank the candidate frameworks, and +those features have different priorities: + +* Critical features: we probably won't consider a framework without these +** Can we legally / easily use the project? +*** <<license,License>> +*** <<vendorable-or-ubiquitous,Vendorable or ubiquitous>> +*** <<maintainable-extensible,Maintainable / extensible>> +*** <<major-platform-support,Major platform support>> +** Does the project support our bare-minimum needs? +*** <<tap-support,TAP support>> +*** <<diagnostic-output,Diagnostic output>> +*** <<runtime-skippable-tests,Runtime-skippable tests>> +* Nice-to-have features: +** <<parallel-execution,Parallel execution>> +** <<mock-support,Mock support>> +** <<signal-error-handling,Signal & error-handling>> +* Tie-breaker stats +** <<project-kloc,Project KLOC>> +** <<adoption,Adoption>> + +[[license]] +=== License + +We must be able to legally use the framework in connection with Git. As Git is +licensed only under GPLv2, we must eliminate any LGPLv3, GPLv3, or Apache 2.0 +projects. + +[[vendorable-or-ubiquitous]] +=== Vendorable or ubiquitous + +We want to avoid forcing Git developers to install new tools just to run unit +tests. Any prospective frameworks and harnesses must either be vendorable +(meaning, we can copy their source directly into Git's repository), or so +ubiquitous that it is reasonable to expect that most developers will have the +tools installed already. + +[[maintainable-extensible]] +=== Maintainable / extensible + +It is unlikely that any pre-existing project perfectly fits our needs, so any +project we select will need to be actively maintained and open to accepting +changes. Alternatively, assuming we are vendoring the source into our repo, it +must be simple enough that Git developers can feel comfortable making changes as +needed to our version. + +In the comparison table below, "True" means that the framework seems to have +active developers, that it is simple enough that Git developers can make changes +to it, and that the project seems open to accepting external contributions (or +that it is vendorable). "Partial" means that at least one of the above +conditions holds. + +[[major-platform-support]] +=== Major platform support + +At a bare minimum, unit-testing must work on Linux, MacOS, and Windows. + +In the comparison table below, "True" means that it works on all three major +platforms with no issues. "Partial" means that there may be annoyances on one or +more platforms, but it is still usable in principle. + +[[tap-support]] +=== TAP support + +The https://testanything.org/[Test Anything Protocol] is a text-based interface +that allows tests to communicate with a test harness. It is already used by +Git's integration test suite. Supporting TAP output is a mandatory feature for +any prospective test framework. + +In the comparison table below, "True" means this is natively supported. +"Partial" means TAP output must be generated by post-processing the native +output. + +Frameworks that do not have at least Partial support will not be evaluated +further. + +[[diagnostic-output]] +=== Diagnostic output + +When a test case fails, the framework must generate enough diagnostic output to +help developers find the appropriate test case in source code in order to debug +the failure. + +[[runtime-skippable-tests]] +=== Runtime-skippable tests + +Test authors may wish to skip certain test cases based on runtime circumstances, +so the framework should support this. + +[[parallel-execution]] +=== Parallel execution + +Ideally, we will build up a significant collection of unit test cases, most +likely split across multiple executables. It will be necessary to run these +tests in parallel to enable fast develop-test-debug cycles. + +In the comparison table below, "True" means that individual test cases within a +single test executable can be run in parallel. We assume that executable-level +parallelism can be handled by the test harness. + +[[mock-support]] +=== Mock support + +Unit test authors may wish to test code that interacts with objects that may be +inconvenient to handle in a test (e.g. interacting with a network service). +Mocking allows test authors to provide a fake implementation of these objects +for more convenient tests. + +[[signal-error-handling]] +=== Signal & error handling + +The test framework should fail gracefully when test cases are themselves buggy +or when they are interrupted by signals during runtime. + +[[project-kloc]] +=== Project KLOC + +The size of the project, in thousands of lines of code as measured by +https://dwheeler.com/sloccount/[sloccount] (rounded up to the next multiple of +1,000). As a tie-breaker, we probably prefer a project with fewer LOC. + +[[adoption]] +=== Adoption + +As a tie-breaker, we prefer a more widely-used project. We use the number of +GitHub / GitLab stars to estimate this. + + +=== Comparison + +:true: [lime-background]#True# +:false: [red-background]#False# +:partial: [yellow-background]#Partial# + +:gpl: [lime-background]#GPL v2# +:isc: [lime-background]#ISC# +:mit: [lime-background]#MIT# +:expat: [lime-background]#Expat# +:lgpl: [lime-background]#LGPL v2.1# + +:custom-impl: https://lore.kernel.org/git/c902a166-98ce-afba-93f2-ea6027557176@gmail.com/[Custom Git impl.] +:greatest: https://github.com/silentbicycle/greatest[Greatest] +:criterion: https://github.com/Snaipe/Criterion[Criterion] +:c-tap: https://github.com/rra/c-tap-harness/[C TAP] +:check: https://libcheck.github.io/check/[Check] +:clar: https://github.com/clar-test/clar[Clar] + +[format="csv",options="header",width="33%",subs="specialcharacters,attributes,quotes,macros"] +|===== +Framework,"<<license,License>>","<<vendorable-or-ubiquitous,Vendorable or ubiquitous>>","<<maintainable-extensible,Maintainable / extensible>>","<<major-platform-support,Major platform support>>","<<tap-support,TAP support>>","<<diagnostic-output,Diagnostic output>>","<<runtime--skippable-tests,Runtime- skippable tests>>","<<parallel-execution,Parallel execution>>","<<mock-support,Mock support>>","<<signal-error-handling,Signal & error handling>>","<<project-kloc,Project KLOC>>","<<adoption,Adoption>>" +{custom-impl},{gpl},{true},{true},{true},{true},{true},{true},{false},{false},{false},1,0 +{greatest},{isc},{true},{partial},{true},{partial},{true},{true},{false},{false},{false},3,1400 +{criterion},{mit},{false},{partial},{true},{true},{true},{true},{true},{false},{true},19,1800 +{c-tap},{expat},{true},{partial},{partial},{true},{false},{true},{false},{false},{false},4,33 +{check},{lgpl},{false},{partial},{true},{true},{true},{false},{false},{false},{true},17,973 +{clar},{isc},{false},{partial},{true},{true},{true},{true},{false},{false},{true},1,192 +|===== + +=== Additional framework candidates + +Several suggested frameworks have been eliminated from consideration: + +* Incompatible licenses: +** https://github.com/zorgnax/libtap[libtap] (LGPL v3) +** https://cmocka.org/[cmocka] (Apache 2.0) +* Missing source: https://www.kindahl.net/mytap/doc/index.html[MyTap] +* No TAP support: +** https://nemequ.github.io/munit/[µnit] +** https://github.com/google/cmockery[cmockery] +** https://github.com/lpabon/cmockery2[cmockery2] +** https://github.com/ThrowTheSwitch/Unity[Unity] +** https://github.com/siu/minunit[minunit] +** https://cunit.sourceforge.net/[CUnit] + + +== Milestones + +* Add useful tests of library-like code +* Integrate with + https://lore.kernel.org/git/20230502211454.1673000-1-calvinwan@google.com/[stdlib + work] +* Run alongside regular `make test` target diff --git a/Documentation/trace2-target-values.txt b/Documentation/trace2-target-values.txt index 3985b6d3c2..06f1953313 100644 --- a/Documentation/trace2-target-values.txt +++ b/Documentation/trace2-target-values.txt @@ -5,7 +5,7 @@ * `<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 +* `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/urls-remotes.txt b/Documentation/urls-remotes.txt index ae8c2db427..bf17012241 100644 --- a/Documentation/urls-remotes.txt +++ b/Documentation/urls-remotes.txt @@ -33,7 +33,7 @@ config file would appear like this: ------------ The `<pushurl>` is used for pushes only. It is optional and defaults -to `<URL>`. Pushing to a remote affects all defined pushurls or to all +to `<URL>`. Pushing to a remote affects all defined pushurls or all defined urls if no pushurls are defined. Fetch, however, will only fetch from the first defined url if multiple urls are defined. @@ -48,7 +48,7 @@ provide a refspec on the command line. This file should have the following format: ------------ - URL: one of the above URL format + URL: one of the above URL formats Push: <refspec> Pull: <refspec> diff --git a/Documentation/urls.txt b/Documentation/urls.txt index 1c229d7581..9c871e716a 100644 --- a/Documentation/urls.txt +++ b/Documentation/urls.txt @@ -6,23 +6,23 @@ address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent. -Git supports ssh, git, http, and https protocols (in addition, ftp, +Git supports ssh, git, http, and https protocols (in addition, ftp and ftps can be used for fetching, but this is inefficient and -deprecated; do not use it). +deprecated; do not use them). -The native transport (i.e. git:// URL) does no authentication and +The native transport (i.e. `git://` URL) does no authentication and should be used with caution on unsecured networks. The following syntaxes may be used with them: -- ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/ -- git://host.xz{startsb}:port{endsb}/path/to/repo.git/ -- http{startsb}s{endsb}://host.xz{startsb}:port{endsb}/path/to/repo.git/ -- ftp{startsb}s{endsb}://host.xz{startsb}:port{endsb}/path/to/repo.git/ +- `ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>` +- `git://<host>[:<port>]/<path-to-git-repo>` +- `http[s]://<host>[:<port>]/<path-to-git-repo>` +- `ftp[s]://<host>[:<port>]/<path-to-git-repo>` An alternative scp-like syntax may also be used with the ssh protocol: -- {startsb}user@{endsb}host.xz:path/to/repo.git/ +- `[<user>@]<host>:/<path-to-git-repo>` This syntax is only recognized if there are no slashes before the first colon. This helps differentiate a local path that contains a @@ -30,40 +30,40 @@ colon. For example the local path `foo:bar` could be specified as an absolute path or `./foo:bar` to avoid being misinterpreted as an ssh url. -The ssh and git protocols additionally support ~username expansion: +The ssh and git protocols additionally support `~<username>` expansion: -- ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/~{startsb}user{endsb}/path/to/repo.git/ -- git://host.xz{startsb}:port{endsb}/~{startsb}user{endsb}/path/to/repo.git/ -- {startsb}user@{endsb}host.xz:/~{startsb}user{endsb}/path/to/repo.git/ +- `ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>` +- `git://<host>[:<port>]/~<user>/<path-to-git-repo>` +- `[<user>@]<host>:~<user>/<path-to-git-repo>` For local repositories, also supported by Git natively, the following syntaxes may be used: -- /path/to/repo.git/ -- \file:///path/to/repo.git/ +- `/path/to/repo.git/` +- `file:///path/to/repo.git/` ifndef::git-clone[] These two syntaxes are mostly equivalent, except when cloning, when -the former implies --local option. See linkgit:git-clone[1] for +the former implies `--local` option. See linkgit:git-clone[1] for details. endif::git-clone[] ifdef::git-clone[] These two syntaxes are mostly equivalent, except the former implies ---local option. +`--local` option. endif::git-clone[] -'git clone', 'git fetch' and 'git pull', but not 'git push', will also +`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 +attempts to use the `remote-<transport>` remote helper, if one exists. To explicitly request a remote helper, the following syntax may be used: -- <transport>::<address> +- `<transport>::<address>` -where <address> may be a path, a server and path, or an arbitrary +where _<address>_ may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. See linkgit:gitremote-helpers[7] for details. @@ -72,10 +72,11 @@ you want to use a different format for them (such that the URLs you use will be rewritten into URLs that work), you can create a configuration section of the form: ------------- - [url "<actual url base>"] - insteadOf = <other url base> ------------- +[verse] +-- + [url "__<actual-url-base>__"] + insteadOf = _<other-url-base>_ +-- For example, with this: @@ -91,10 +92,11 @@ rewritten in any context that takes a URL to be "git://git.host.xz/repo.git". If you want to rewrite URLs for push only, you can create a configuration section of the form: ------------- - [url "<actual url base>"] - pushInsteadOf = <other url base> ------------- +[verse] +-- + [url "__<actual-url-base>__"] + pushInsteadOf = _<other-url-base>_ +-- For example, with this: diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 4281396093..90a4189358 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1122,7 +1122,7 @@ choosing "Stage Hunk For Commit"). === 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 +with a single short (no more than 50 characters) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used @@ -1344,7 +1344,7 @@ $ git diff --theirs file.txt # same as the above. ------------------------------------------------- When using the 'ort' merge strategy (the default), before updating the working -tree with the result of the merge, Git writes a special ref named AUTO_MERGE +tree with the result of the merge, Git writes a ref named AUTO_MERGE reflecting the state of the tree it is about to write. Conflicted paths with textual conflicts that could not be automatically merged are written to this tree with conflict markers, just as in the working tree. AUTO_MERGE can thus be @@ -4093,15 +4093,46 @@ that not only specifies their type, but also provides size information about the data in the object. It's worth noting that the SHA-1 hash that is used to name the object is the hash of the original data plus this header, so `sha1sum` 'file' does not match the object name -for 'file'. +for 'file' (the earliest versions of Git hashed slightly differently +but the conclusion is still the same). + +The following is a short example that demonstrates how these hashes +can be generated manually: + +Let's assume a small text file with some simple content: + +------------------------------------------------- +$ echo "Hello world" >hello.txt +------------------------------------------------- + +We can now manually generate the hash Git would use for this file: + +- The object we want the hash for is of type "blob" and its size is + 12 bytes. + +- Prepend the object header to the file content and feed this to + `sha1sum`: + +------------------------------------------------- +$ { printf "blob 12\0"; cat hello.txt; } | sha1sum +802992c4220de19a90767f3000a79a31b98d0df7 - +------------------------------------------------- + +This manually constructed hash can be verified using `git hash-object` +which of course hides the addition of the header: + +------------------------------------------------- +$ git hash-object hello.txt +802992c4220de19a90767f3000a79a31b98d0df7 +------------------------------------------------- As a result, the general consistency of an object can always be tested independently of the contents or the type of the object: all objects can be validated by verifying that (a) their hashes match the content of the file and (b) the object successfully inflates to a stream of bytes that forms a sequence of -`<ascii type without space> + <space> + <ascii decimal size> + -<byte\0> + <binary object data>`. +`<ascii-type-without-space> + <space> + <ascii-decimal-size> + +<byte\0> + <binary-object-data>`. The structured objects can further have their structure and connectivity to other objects verified. This is generally done with @@ -4123,7 +4154,8 @@ $ git switch --detach e83c5163 ---------------------------------------------------- The initial revision lays the foundation for almost everything Git has -today, but is small enough to read in one sitting. +today (even though details may differ in a few places), but is small +enough to read in one sitting. Note that terminology has changed since that revision. For example, the README in that revision uses the word "changeset" to describe what we |