diff options
Diffstat (limited to 'Documentation')
44 files changed, 798 insertions, 58 deletions
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index ed4e443a3c..390ceece52 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -91,8 +91,6 @@ For shell scripts specifically (not exhaustive): - No shell arrays. - - No strlen ${#parameter}. - - No pattern replacement ${parameter/pattern/string}. - We use Arithmetic Expansion $(( ... )). diff --git a/Documentation/Makefile b/Documentation/Makefile index 8fe829cc1b..59e6ce3a2a 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -30,6 +30,7 @@ MAN7_TXT += gitcredentials.txt MAN7_TXT += gitcvs-migration.txt MAN7_TXT += gitdiffcore.txt MAN7_TXT += giteveryday.txt +MAN7_TXT += gitfaq.txt MAN7_TXT += gitglossary.txt MAN7_TXT += gitnamespaces.txt MAN7_TXT += gitremote-helpers.txt diff --git a/Documentation/MyFirstObjectWalk.txt b/Documentation/MyFirstObjectWalk.txt index aa828dfdc4..c3f2d1a831 100644 --- a/Documentation/MyFirstObjectWalk.txt +++ b/Documentation/MyFirstObjectWalk.txt @@ -357,9 +357,6 @@ static void walken_commit_walk(struct rev_info *rev) ... while ((commit = get_revision(rev))) { - if (!commit) - continue; - strbuf_reset(&prettybuf); pp_commit_easy(CMIT_FMT_ONELINE, commit, &prettybuf); puts(prettybuf.buf); diff --git a/Documentation/RelNotes/2.17.4.txt b/Documentation/RelNotes/2.17.4.txt new file mode 100644 index 0000000000..7d794ca01a --- /dev/null +++ b/Documentation/RelNotes/2.17.4.txt @@ -0,0 +1,16 @@ +Git v2.17.4 Release Notes +========================= + +This release is to address the security issue: CVE-2020-5260 + +Fixes since v2.17.3 +------------------- + + * With a crafted URL that contains a newline in it, the credential + helper machinery can be fooled to give credential information for + a wrong host. The attack has been made impossible by forbidding + a newline character in any value passed via the credential + protocol. + +Credit for finding the vulnerability goes to Felix Wilhelm of Google +Project Zero. diff --git a/Documentation/RelNotes/2.17.5.txt b/Documentation/RelNotes/2.17.5.txt new file mode 100644 index 0000000000..2abb821a73 --- /dev/null +++ b/Documentation/RelNotes/2.17.5.txt @@ -0,0 +1,22 @@ +Git v2.17.5 Release Notes +========================= + +This release is to address a security issue: CVE-2020-11008 + +Fixes since v2.17.4 +------------------- + + * With a crafted URL that contains a newline or empty host, or lacks + a scheme, the credential helper machinery can be fooled into + providing credential information that is not appropriate for the + protocol in use and host being contacted. + + Unlike the vulnerability CVE-2020-5260 fixed in v2.17.4, the + credentials are not for a host of the attacker's choosing; instead, + they are for some unspecified host (based on how the configured + credential helper handles an absent "host" parameter). + + The attack has been made impossible by refusing to work with + under-specified credential patterns. + +Credit for finding the vulnerability goes to Carlo Arenas. diff --git a/Documentation/RelNotes/2.18.3.txt b/Documentation/RelNotes/2.18.3.txt new file mode 100644 index 0000000000..25143f0cec --- /dev/null +++ b/Documentation/RelNotes/2.18.3.txt @@ -0,0 +1,5 @@ +Git v2.18.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.18.4.txt b/Documentation/RelNotes/2.18.4.txt new file mode 100644 index 0000000000..e8ef858a00 --- /dev/null +++ b/Documentation/RelNotes/2.18.4.txt @@ -0,0 +1,5 @@ +Git v2.18.4 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.19.4.txt b/Documentation/RelNotes/2.19.4.txt new file mode 100644 index 0000000000..35d0ae561b --- /dev/null +++ b/Documentation/RelNotes/2.19.4.txt @@ -0,0 +1,5 @@ +Git v2.19.4 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.19.5.txt b/Documentation/RelNotes/2.19.5.txt new file mode 100644 index 0000000000..18a4dcbfd6 --- /dev/null +++ b/Documentation/RelNotes/2.19.5.txt @@ -0,0 +1,5 @@ +Git v2.19.5 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.20.3.txt b/Documentation/RelNotes/2.20.3.txt new file mode 100644 index 0000000000..f6eccd103b --- /dev/null +++ b/Documentation/RelNotes/2.20.3.txt @@ -0,0 +1,5 @@ +Git v2.20.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.20.4.txt b/Documentation/RelNotes/2.20.4.txt new file mode 100644 index 0000000000..5a9e24e470 --- /dev/null +++ b/Documentation/RelNotes/2.20.4.txt @@ -0,0 +1,5 @@ +Git v2.20.4 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.21.2.txt b/Documentation/RelNotes/2.21.2.txt new file mode 100644 index 0000000000..a0fb83bb53 --- /dev/null +++ b/Documentation/RelNotes/2.21.2.txt @@ -0,0 +1,5 @@ +Git v2.21.2 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.21.3.txt b/Documentation/RelNotes/2.21.3.txt new file mode 100644 index 0000000000..2ca0aa5c62 --- /dev/null +++ b/Documentation/RelNotes/2.21.3.txt @@ -0,0 +1,5 @@ +Git v2.21.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.22.3.txt b/Documentation/RelNotes/2.22.3.txt new file mode 100644 index 0000000000..57296f6d17 --- /dev/null +++ b/Documentation/RelNotes/2.22.3.txt @@ -0,0 +1,5 @@ +Git v2.22.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.22.4.txt b/Documentation/RelNotes/2.22.4.txt new file mode 100644 index 0000000000..8b5f3e3f37 --- /dev/null +++ b/Documentation/RelNotes/2.22.4.txt @@ -0,0 +1,5 @@ +Git v2.22.4 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.23.2.txt b/Documentation/RelNotes/2.23.2.txt new file mode 100644 index 0000000000..b697cbe0e3 --- /dev/null +++ b/Documentation/RelNotes/2.23.2.txt @@ -0,0 +1,5 @@ +Git v2.23.2 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.23.3.txt b/Documentation/RelNotes/2.23.3.txt new file mode 100644 index 0000000000..2e35490137 --- /dev/null +++ b/Documentation/RelNotes/2.23.3.txt @@ -0,0 +1,5 @@ +Git v2.23.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.24.2.txt b/Documentation/RelNotes/2.24.2.txt new file mode 100644 index 0000000000..0049f65503 --- /dev/null +++ b/Documentation/RelNotes/2.24.2.txt @@ -0,0 +1,5 @@ +Git v2.24.2 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.24.3.txt b/Documentation/RelNotes/2.24.3.txt new file mode 100644 index 0000000000..5302e0f73b --- /dev/null +++ b/Documentation/RelNotes/2.24.3.txt @@ -0,0 +1,5 @@ +Git v2.24.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.25.3.txt b/Documentation/RelNotes/2.25.3.txt new file mode 100644 index 0000000000..15f7f21f10 --- /dev/null +++ b/Documentation/RelNotes/2.25.3.txt @@ -0,0 +1,5 @@ +Git v2.25.3 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.25.4.txt b/Documentation/RelNotes/2.25.4.txt new file mode 100644 index 0000000000..0dbb5daeec --- /dev/null +++ b/Documentation/RelNotes/2.25.4.txt @@ -0,0 +1,5 @@ +Git v2.25.4 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.26.1.txt b/Documentation/RelNotes/2.26.1.txt new file mode 100644 index 0000000000..1b4ecb3fdc --- /dev/null +++ b/Documentation/RelNotes/2.26.1.txt @@ -0,0 +1,5 @@ +Git v2.26.1 Release Notes +========================= + +This release merges the security fix that appears in v2.17.4; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.26.2.txt b/Documentation/RelNotes/2.26.2.txt new file mode 100644 index 0000000000..d434d0c695 --- /dev/null +++ b/Documentation/RelNotes/2.26.2.txt @@ -0,0 +1,5 @@ +Git v2.26.2 Release Notes +========================= + +This release merges the security fix that appears in v2.17.5; see +the release notes for that version for details. diff --git a/Documentation/RelNotes/2.27.0.txt b/Documentation/RelNotes/2.27.0.txt new file mode 100644 index 0000000000..7a5c7fff80 --- /dev/null +++ b/Documentation/RelNotes/2.27.0.txt @@ -0,0 +1,94 @@ +Git 2.27 Release Notes +====================== + +Updates since v2.26 +------------------- + +Backward compatibility notes + + * When "git describe C" finds that commit C is pointed by a signed or + annotated tag, which records T as its tagname in the object, the + command gives T as its answer. Even if the user renames or moves + such a tag from its natural location in the "refs/tags/" hierarchy, + "git describe C" would still give T as the answer, but in such a + case "git show T^0" would no longer work as expected. There may be + nothing at "refs/tags/T" or even worse there may be a different tag + instead. + + Starting from this version, "git describe" will always use the + "long" version, as if the "--long" option were given, when giving + its output based on such a misplaced tag to work around the problem. + + * "git pull" issues a warning message until the pull.rebase + configuration variable is explicitly given, which some existing + users may find annoying---those who prefer not to rebase need to + set the variable to false to squelch the warning. + + +UI, Workflows & Features + + * A handful of options to configure SSL when talking to proxies have + been added. + + * Smudge/clean conversion filters are now given more information + (e.g. the object of the tree-ish in which the blob being converted + appears, in addition to its path, which has already been given). + + * When "git describe C" finds an annotated tag with tagname A to be + the best name to explain commit C, and the tag is stored in a + "wrong" place in the refs/tags hierarchy, e.g. refs/tags/B, the + command gave a warning message but used A (not B) to describe C. + If C is exactly at the tag, the describe output would be "A", but + "git rev-parse A^0" would not be equal as "git rev-parse C^0". The + behavior of the command has been changed to use the "long" form + i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse. + + * "git pull" learned to warn when no pull.rebase configuration + exists, and neither --[no-]rebase nor --ff-only is given (which + would result a merge). + + +Performance, Internal Implementation, Development Support etc. + + * The advise API has been revamped to allow more systematic enumeration of + advice knobs in the future. + + * SHA-256 transition continues. + + * The code to interface with GnuPG has been refactored. + + * "git stash" has kept an escape hatch to use the scripted version + for a few releases, which got stale. It has been removed. + + +Fixes since v2.26 +----------------- + + * The real_path() convenience function can easily be misused; with a + bit of code refactoring in the callers' side, its use has been + eliminated. + (merge 49d3c4b481 am/real-path-fix later to maint). + + * Update "git p4" to work with Python 3. + (merge 6bb40ed20a yz/p4-py3 later to maint). + + * The mechanism to prevent "git commit" from making an empty commit + or amending during an interrupted cherry-pick was broken during the + rewrite of "git rebase" in C, which has been corrected. + (merge 430b75f720 pw/advise-rebase-skip later to maint). + + * Fix "git checkout --recurse-submodules" of a nested submodule + hierarchy. + (merge 846f34d351 pb/recurse-submodules-fix later to maint). + + * The "--fork-point" mode of "git rebase" regressed when the command + was rewritten in C back in 2.20 era, which has been corrected. + (merge f08132f889 at/rebase-fork-point-regression-fix later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge 564956f358 jc/maintain-doc later to maint). + (merge 7422b2a0a1 sg/commit-slab-clarify-peek later to maint). + (merge 9c688735f6 rs/doc-passthru-fetch-options later to maint). + (merge 757c2ba3e2 en/oidset-uninclude-hashmap later to maint). + (merge 8312aa7d74 jc/config-tar later to maint). + (merge d00a5bdd50 ss/submodule-foreach-cb later to maint). diff --git a/Documentation/config.txt b/Documentation/config.txt index 08b13ba72b..2450589a0e 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -447,6 +447,8 @@ include::config/submodule.txt[] include::config/tag.txt[] +include::config/tar.txt[] + include::config/trace2.txt[] include::config/transfer.txt[] diff --git a/Documentation/config/feature.txt b/Documentation/config/feature.txt index 875f8c8a66..4e3a5c0ceb 100644 --- a/Documentation/config/feature.txt +++ b/Documentation/config/feature.txt @@ -12,9 +12,6 @@ feature.experimental:: setting if you are interested in providing feedback on experimental features. The new default values are: + -* `pack.useSparse=true` uses a new algorithm when constructing a pack-file -which can improve `git push` performance in repos with many files. -+ * `fetch.negotiationAlgorithm=skipping` may improve fetch negotiation times by skipping more commits at a time, reducing the number of round trips. + diff --git a/Documentation/config/http.txt b/Documentation/config/http.txt index e806033aab..3968fbb697 100644 --- a/Documentation/config/http.txt +++ b/Documentation/config/http.txt @@ -29,6 +29,27 @@ http.proxyAuthMethod:: * `ntlm` - NTLM authentication (compare the --ntlm option of `curl(1)`) -- +http.proxySSLCert:: + The pathname of a file that stores a client certificate to use to authenticate + with an HTTPS proxy. Can be overridden by the `GIT_PROXY_SSL_CERT` environment + variable. + +http.proxySSLKey:: + The pathname of a file that stores a private key to use to authenticate with + an HTTPS proxy. Can be overridden by the `GIT_PROXY_SSL_KEY` environment + variable. + +http.proxySSLCertPasswordProtected:: + Enable Git's password prompt for the proxy SSL certificate. Otherwise OpenSSL + will prompt the user, possibly many times, if the certificate or private key + is encrypted. Can be overriden by the `GIT_PROXY_SSL_CERT_PASSWORD_PROTECTED` + environment variable. + +http.proxySSLCAInfo:: + Pathname to the file containing the certificate bundle that should be used to + verify the proxy with when using an HTTPS proxy. Can be overriden by the + `GIT_PROXY_SSL_CAINFO` environment variable. + http.emptyAuth:: Attempt authentication without seeking a username or password. This can be used to attempt GSS-Negotiate authentication without specifying diff --git a/Documentation/config/pack.txt b/Documentation/config/pack.txt index 0dac580581..837f1b1679 100644 --- a/Documentation/config/pack.txt +++ b/Documentation/config/pack.txt @@ -119,8 +119,8 @@ pack.useSparse:: objects. This can have significant performance benefits when computing a pack to send a small change. However, it is possible that extra objects are added to the pack-file if the included - commits contain certain types of direct renames. Default is `false` - unless `feature.experimental` is enabled. + commits contain certain types of direct renames. Default is + `true`. pack.writeBitmaps (deprecated):: This is a deprecated synonym for `repack.writeBitmaps`. diff --git a/Documentation/config/stash.txt b/Documentation/config/stash.txt index abc7ef4a3a..00eb35434e 100644 --- a/Documentation/config/stash.txt +++ b/Documentation/config/stash.txt @@ -1,17 +1,9 @@ stash.useBuiltin:: - Set to `false` to use the legacy shell script implementation of - linkgit:git-stash[1]. Is `true` by default, which means use - the built-in rewrite of it in C. -+ -The C rewrite is first included with Git version 2.22 (and Git for Windows -version 2.19). This option serves as an escape hatch to re-enable the -legacy version in case any bugs are found in the rewrite. This option and -the shell script version of linkgit:git-stash[1] will be removed in some -future release. -+ -If you find some reason to set this option to `false`, other than -one-off testing, you should report the behavior difference as a bug in -Git (see https://git-scm.com/community for details). + Unused configuration variable. Used in Git versions 2.22 to + 2.26 as an escape hatch to enable the legacy shellscript + implementation of stash. Now the built-in rewrite of it in C + is always used. Setting this will emit a warning, to alert any + remaining users that setting this now does nothing. stash.showPatch:: If this is set to true, the `git stash show` command without an diff --git a/Documentation/config/tag.txt b/Documentation/config/tag.txt index 6d9110d84c..5062a057ff 100644 --- a/Documentation/config/tag.txt +++ b/Documentation/config/tag.txt @@ -15,10 +15,3 @@ tag.gpgSign:: convenient to use an agent to avoid typing your gpg passphrase several times. Note that this option doesn't affect tag signing behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options. - -tar.umask:: - This variable can be used to restrict the permission bits of - tar archive entries. The default is 0002, which turns off the - world write bit. The special value "user" indicates that the - archiving user's umask will be used instead. See umask(2) and - linkgit:git-archive[1]. diff --git a/Documentation/config/tar.txt b/Documentation/config/tar.txt new file mode 100644 index 0000000000..de8ff48ea9 --- /dev/null +++ b/Documentation/config/tar.txt @@ -0,0 +1,6 @@ +tar.umask:: + This variable can be used to restrict the permission bits of + tar archive entries. The default is 0002, which turns off the + world write bit. The special value "user" indicates that the + archiving user's umask will be used instead. See umask(2) and + linkgit:git-archive[1]. diff --git a/Documentation/config/trace2.txt b/Documentation/config/trace2.txt index 4ce0b9a6d1..01d3afd8a8 100644 --- a/Documentation/config/trace2.txt +++ b/Documentation/config/trace2.txt @@ -48,6 +48,15 @@ trace2.configParams:: May be overridden by the `GIT_TRACE2_CONFIG_PARAMS` environment variable. Unset by default. +trace2.envVars:: + A comma-separated list of "important" environment variables that should + be recorded in the trace2 output. For example, + `GIT_HTTP_USER_AGENT,GIT_CONFIG` would cause the trace2 output to + contain events listing the overrides for HTTP user agent and the + location of the Git configuration file (assuming any are set). May be + overriden by the `GIT_TRACE2_ENV_VARS` environment variable. Unset by + default. + trace2.destinationDebug:: Boolean. When true Git will print error messages when a trace target destination cannot be opened for writing. diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index a115a1ae0e..05709f67a1 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -61,10 +61,8 @@ this option multiple times, one for each matching ref name. See also the `fetch.negotiationAlgorithm` configuration variable documented in linkgit:git-config[1]. -ifndef::git-pull[] --dry-run:: Show what would be done, without making any changes. -endif::git-pull[] -f:: --force:: @@ -95,6 +93,7 @@ ifndef::git-pull[] --[no-]write-commit-graph:: Write a commit-graph after fetching. This overrides the config setting `fetch.writeCommitGraph`. +endif::git-pull[] -p:: --prune:: @@ -107,6 +106,7 @@ ifndef::git-pull[] was cloned with the --mirror option), then they are also subject to pruning. Supplying `--prune-tags` is a shorthand for providing the tag refspec. +ifndef::git-pull[] + See the PRUNING section below for more details. @@ -133,7 +133,6 @@ endif::git-pull[] behavior for a remote may be specified with the remote.<name>.tagOpt setting. See linkgit:git-config[1]. -ifndef::git-pull[] --refmap=<refspec>:: When fetching refs listed on the command line, use the specified refspec (can be given more than once) to map the @@ -154,6 +153,7 @@ ifndef::git-pull[] is used (though tags may be pruned anyway if they are also the destination of an explicit refspec; see `--prune`). +ifndef::git-pull[] --recurse-submodules[=yes|on-demand|no]:: This option controls if and under what conditions new commits of populated submodules should be fetched too. It can be used as a @@ -164,6 +164,7 @@ ifndef::git-pull[] when the superproject retrieves a commit that updates the submodule's reference to a commit that isn't already in the local submodule clone. +endif::git-pull[] -j:: --jobs=<n>:: @@ -177,9 +178,11 @@ parallel. To control them independently, use the config settings Typically, parallel recursive and multi-remote fetches will be faster. By default fetches are performed sequentially, not in parallel. +ifndef::git-pull[] --no-recurse-submodules:: Disable recursive fetching of submodules (this has the same effect as using the `--recurse-submodules=no` option). +endif::git-pull[] --set-upstream:: If the remote is fetched successfully, pull and add upstream @@ -188,6 +191,7 @@ default fetches are performed sequentially, not in parallel. see `branch.<name>.merge` and `branch.<name>.remote` in linkgit:git-config[1]. +ifndef::git-pull[] --submodule-prefix=<path>:: Prepend <path> to paths printed in informative messages such as "Fetching submodule foo". This option is used @@ -200,7 +204,6 @@ default fetches are performed sequentially, not in parallel. recursion (such as settings in linkgit:gitmodules[5] and linkgit:git-config[1]) override this option, as does specifying --[no-]recurse-submodules directly. -endif::git-pull[] -u:: --update-head-ok:: @@ -210,6 +213,7 @@ endif::git-pull[] to communicate with 'git fetch', and unless you are implementing your own Porcelain you are not supposed to use it. +endif::git-pull[] --upload-pack <upload-pack>:: When given, and the repository to fetch from is handled diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index bf24f1813a..08d6045c4a 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -15,7 +15,8 @@ SYNOPSIS [--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] [--] <repository> + [--[no-]remote-submodules] [--jobs <n>] [--sparse] + [--filter=<filter>] [--] <repository> [<directory>] DESCRIPTION @@ -162,6 +163,16 @@ objects from the source repository into a pack in the cloned repository. of the repository. The sparse-checkout file can be modified to grow the working directory as needed. +--filter=<filter-spec>:: + Use the partial clone feature and request that the server sends + a subset of reachable objects according to a given object filter. + When using `--filter`, the supplied `<filter-spec>` is used for + the partial clone filter. For example, `--filter=blob:none` will + filter out all blobs (file contents) until needed by Git. Also, + `--filter=blob:limit=<size>` will filter out all blobs of size + at least `<size>`. For more details on filter specifications, see + the `--filter` option in linkgit:git-rev-list[1]. + --mirror:: Set up a mirror of the source repository. This implies `--bare`. Compared to `--bare`, `--mirror` not only maps local branches of the diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 7889f95940..77c6b3d001 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -122,6 +122,26 @@ Locations of Marks Files Relative and non-relative marks may be combined by interweaving --(no-)-relative-marks with the --(import|export)-marks= options. +Submodule Rewriting +~~~~~~~~~~~~~~~~~~~ + +--rewrite-submodules-from=<name>:<file>:: +--rewrite-submodules-to=<name>:<file>:: + Rewrite the object IDs for the submodule specified by <name> from the values + used in the from <file> to those used in the to <file>. The from marks should + have been created by `git fast-export`, and the to marks should have been + created by `git fast-import` when importing that same submodule. ++ +<name> may be any arbitrary string not containing a colon character, but the +same value must be used with both options when specifying corresponding marks. +Multiple submodules may be specified with different values for <name>. It is an +error not to use these options in corresponding pairs. ++ +These options are primarily useful when converting a repository from one hash +algorithm to another; without them, fast-import will fail if it encounters a +submodule because it has no way of writing the object ID into the new hash +algorithm. + Performance and Compression Tuning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 32880aafb0..adc6adfd38 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git init' [-q | --quiet] [--bare] [--template=<template_directory>] - [--separate-git-dir <git dir>] + [--separate-git-dir <git dir>] [--object-format=<format] [--shared[=<permissions>]] [directory] @@ -48,6 +48,11 @@ Only print error and warning messages; all other output will be suppressed. Create a bare repository. If `GIT_DIR` environment is not set, it is set to the current working directory. +--object-format=<format>:: + +Specify the given object format (hash algorithm) for the repository. The valid +values are 'sha1' and (if enabled) 'sha256'. 'sha1' is the default. + --template=<template_directory>:: Specify the directory from which templates will be used. (See the "TEMPLATE diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index 3494a1db3e..dab9609013 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -374,14 +374,55 @@ These options can be used to modify 'git p4 submit' behavior. been submitted. Implies --disable-rebase. Can also be set with git-p4.disableP4Sync. Sync with origin/master still goes ahead if possible. -Hook for submit -~~~~~~~~~~~~~~~ +Hooks for submit +---------------- + +p4-pre-submit +~~~~~~~~~~~~~ + The `p4-pre-submit` hook is executed if it exists and is executable. The hook takes no parameters and nothing from standard input. Exiting with non-zero status from this script prevents `git-p4 submit` from launching. +It can be bypassed with the `--no-verify` command line option. One usage scenario is to run unit tests in the hook. +p4-prepare-changelist +~~~~~~~~~~~~~~~~~~~~~ + +The `p4-prepare-changelist` hook is executed right after preparing +the default changelist message and before the editor is started. +It takes one parameter, the name of the file that contains the +changelist text. Exiting with a non-zero status from the script +will abort the process. + +The purpose of the hook is to edit the message file in place, +and it is not supressed by the `--no-verify` option. This hook +is called even if `--prepare-p4-only` is set. + +p4-changelist +~~~~~~~~~~~~~ + +The `p4-changelist` hook is executed after the changelist +message has been edited by the user. It can be bypassed with the +`--no-verify` option. It takes a single parameter, the name +of the file that holds the proposed changelist text. Exiting +with a non-zero status causes the command to abort. + +The hook is allowed to edit the changelist file and can be used +to normalize the text into some project standard format. It can +also be used to refuse the Submit after inspect the message file. + +p4-post-changelist +~~~~~~~~~~~~~~~~~~ + +The `p4-post-changelist` hook is invoked after the submit has +successfully occured in P4. It takes no parameters and is meant +primarily for notification and cannot affect the outcome of the +git p4 submit action. + + + Rebase options ~~~~~~~~~~~~~~ These options can be used to modify 'git p4 rebase' behavior. diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt index fecdf2600c..eaa2f2a404 100644 --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -14,7 +14,7 @@ SYNOPSIS [--local] [--incremental] [--window=<n>] [--depth=<n>] [--revs [--unpacked | --all]] [--keep-pack=<pack-name>] [--stdout [--filter=<filter-spec>] | base-name] - [--shallow] [--keep-true-parents] [--sparse] < object-list + [--shallow] [--keep-true-parents] [--[no-]sparse] < object-list DESCRIPTION @@ -196,14 +196,16 @@ depth is 4095. Add --no-reuse-object if you want to force a uniform compression level on all data no matter the source. ---sparse:: - Use the "sparse" algorithm to determine which objects to include in +--[no-]sparse:: + Toggle the "sparse" algorithm to determine which objects to include in the pack, when combined with the "--revs" option. This algorithm only walks trees that appear in paths that introduce new objects. This can have significant performance benefits when computing a pack to send a small change. However, it is possible that extra objects are added to the pack-file if the included commits contain - certain types of direct renames. + certain types of direct renames. If this option is not included, + it defaults to the value of `pack.useSparse`, which is true unless + otherwise specified. --thin:: Create a "thin" pack by omitting the common objects between a diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index f7a6033607..46ddf172d9 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -605,7 +605,7 @@ BEHAVIORAL DIFFERENCES ----------------------- git rebase has two primary backends: apply and merge. (The apply -backend used to known as the 'am' backend, but the name led to +backend used to be known as the 'am' backend, but the name led to confusion as it looks like a verb instead of a noun. Also, the merge backend used to be known as the interactive backend, but it is now used for non-interactive cases as well. Both were renamed based on diff --git a/Documentation/git.txt b/Documentation/git.txt index b0672bd806..9d6769e95a 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -493,6 +493,12 @@ double-quotes and respecting backslash escapes. E.g., the value details. This variable has lower precedence than other path variables such as GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY... +`GIT_DEFAULT_HASH_ALGORITHM`:: + If this variable is set, the default hash algorithm for new + repositories will be set to this value. This value is currently + ignored when cloning; the setting of the remote repository + is used instead. The default is "sha1". + Git Commits ~~~~~~~~~~~ `GIT_AUTHOR_NAME`:: diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt new file mode 100644 index 0000000000..1cf83df118 --- /dev/null +++ b/Documentation/gitfaq.txt @@ -0,0 +1,337 @@ +gitfaq(7) +========= + +NAME +---- +gitfaq - Frequently asked questions about using Git + +SYNOPSIS +-------- +gitfaq + +DESCRIPTION +----------- + +The examples in this FAQ assume a standard POSIX shell, like `bash` or `dash`, +and a user, A U Thor, who has the account `author` on the hosting provider +`git.example.org`. + +Configuration +------------- + +[[user-name]] +What should I put in `user.name`?:: + You should put your personal name, generally a form using a given name + and family name. For example, the current maintainer of Git uses "Junio + C Hamano". This will be the name portion that is stored in every commit + you make. ++ +This configuration doesn't have any effect on authenticating to remote services; +for that, see `credential.username` in linkgit:git-config[1]. + +[[http-postbuffer]] +What does `http.postBuffer` really do?:: + This option changes the size of the buffer that Git uses when pushing + data to a remote over HTTP or HTTPS. If the data is larger than this + size, libcurl, which handles the HTTP support for Git, will use chunked + transfer encoding since it isn't known ahead of time what the size of + the pushed data will be. ++ +Leaving this value at the default size is fine unless you know that either the +remote server or a proxy in the middle doesn't support HTTP/1.1 (which +introduced the chunked transfer encoding) or is known to be broken with chunked +data. This is often (erroneously) suggested as a solution for generic push +problems, but since almost every server and proxy supports at least HTTP/1.1, +raising this value usually doesn't solve most push problems. A server or proxy +that didn't correctly support HTTP/1.1 and chunked transfer encoding wouldn't be +that useful on the Internet today, since it would break lots of traffic. ++ +Note that increasing this value will increase the memory used on every relevant +push that Git does over HTTP or HTTPS, since the entire buffer is allocated +regardless of whether or not it is all used. Thus, it's best to leave it at the +default unless you are sure you need a different value. + +[[configure-editor]] +How do I configure a different editor?:: + If you haven't specified an editor specifically for Git, it will by default + use the editor you've configured using the `VISUAL` or `EDITOR` environment + variables, or if neither is specified, the system default (which is usually + `vi`). Since some people find `vi` difficult to use or prefer a different + editor, it may be desirable to change the editor used. ++ +If you want to configure a general editor for most programs which need one, you +can edit your shell configuration (e.g., `~/.bashrc` or `~/.zshenv`) to contain +a line setting the `EDITOR` or `VISUAL` environment variable to an appropriate +value. For example, if you prefer the editor `nano`, then you could write the +following: ++ +---- +export VISUAL=nano +---- ++ +If you want to configure an editor specifically for Git, you can either set the +`core.editor` configuration value or the `GIT_EDITOR` environment variable. You +can see linkgit:git-var[1] for details on the order in which these options are +consulted. ++ +Note that in all cases, the editor value will be passed to the shell, so any +arguments containing spaces should be appropriately quoted. Additionally, if +your editor normally detaches from the terminal when invoked, you should specify +it with an argument that makes it not do that, or else Git will not see any +changes. An example of a configuration addressing both of these issues on +Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`, +which quotes the filename with spaces and specifies the `--nofork` option to +avoid backgrounding the process. + +Credentials +----------- + +[[http-credentials]] +How do I specify my credentials when pushing over HTTP?:: + The easiest way to do this is to use a credential helper via the + `credential.helper` configuration. Most systems provide a standard + choice to integrate with the system credential manager. For example, + Git for Windows provides the `wincred` credential manager, macOS has the + `osxkeychain` credential manager, and Unix systems with a standard + desktop environment can use the `libsecret` credential manager. All of + these store credentials in an encrypted store to keep your passwords or + tokens secure. ++ +In addition, you can use the `store` credential manager which stores in a file +in your home directory, or the `cache` credential manager, which does not +permanently store your credentials, but does prevent you from being prompted for +them for a certain period of time. ++ +You can also just enter your password when prompted. While it is possible to +place the password (which must be percent-encoded) in the URL, this is not +particularly secure and can lead to accidental exposure of credentials, so it is +not recommended. + +[[http-credentials-environment]] +How do I read a password or token from an environment variable?:: + The `credential.helper` configuration option can also take an arbitrary + shell command that produces the credential protocol on standard output. + This is useful when passing credentials into a container, for example. ++ +Such a shell command can be specified by starting the option value with an +exclamation point. If your password or token were stored in the `GIT_TOKEN`, +you could run the following command to set your credential helper: ++ +---- +$ git config credential.helper \ + '!f() { echo username=author; echo "password=$GIT_TOKEN"; };f' +---- + +[[http-reset-credentials]] +How do I change the password or token I've saved in my credential manager?:: + Usually, if the password or token is invalid, Git will erase it and + prompt for a new one. However, there are times when this doesn't always + happen. To change the password or token, you can erase the existing + credentials and then Git will prompt for new ones. To erase + credentials, use a syntax like the following (substituting your username + and the hostname): ++ +---- +$ echo url=https://author@git.example.org | git credential reject +---- + +[[multiple-accounts-http]] +How do I use multiple accounts with the same hosting provider using HTTP?:: + Usually the easiest way to distinguish between these accounts is to use + the username in the URL. For example, if you have the accounts `author` + and `committer` on `git.example.org`, you can use the URLs + https://author@git.example.org/org1/project1.git and + https://committer@git.example.org/org2/project2.git. This way, when you + use a credential helper, it will automatically try to look up the + correct credentials for your account. If you already have a remote set + up, you can change the URL with something like `git remote set-url + origin https://author@git.example.org/org1/project1.git` (see + linkgit:git-remote[1] for details). + +[[multiple-accounts-ssh]] +How do I use multiple accounts with the same hosting provider using SSH?:: + With most hosting providers that support SSH, a single key pair uniquely + identifies a user. Therefore, to use multiple accounts, it's necessary + to create a key pair for each account. If you're using a reasonably + modern OpenSSH version, you can create a new key pair with something + like `ssh-keygen -t ed25519 -f ~/.ssh/id_committer`. You can then + register the public key (in this case, `~/.ssh/id_committer.pub`; note + the `.pub`) with the hosting provider. ++ +Most hosting providers use a single SSH account for pushing; that is, all users +push to the `git` account (e.g., `git@git.example.org`). If that's the case for +your provider, you can set up multiple aliases in SSH to make it clear which key +pair to use. For example, you could write something like the following in +`~/.ssh/config`, substituting the proper private key file: ++ +---- +# This is the account for author on git.example.org. +Host example_author + HostName git.example.org + User git + # This is the key pair registered for author with git.example.org. + IdentityFile ~/.ssh/id_author + IdentitiesOnly yes +# This is the account for committer on git.example.org. +Host example_committer + HostName git.example.org + User git + # This is the key pair registered for committer with git.example.org. + IdentityFile ~/.ssh/id_committer + IdentitiesOnly yes +---- ++ +Then, you can adjust your push URL to use `git@example_author` or +`git@example_committer` instead of `git@example.org` (e.g., `git remote set-url +git@example_author:org1/project1.git`). + +Common Issues +------------- + +[[last-commit-amend]] +I've made a mistake in the last commit. How do I change it?:: + You can make the appropriate change to your working tree, run `git add + <file>` or `git rm <file>`, as appropriate, to stage it, and then `git + commit --amend`. Your change will be included in the commit, and you'll + be prompted to edit the commit message again; if you wish to use the + original message verbatim, you can use the `--no-edit` option to `git + commit` in addition, or just save and quit when your editor opens. + +[[undo-previous-change]] +I've made a change with a bug and it's been included in the main branch. How should I undo it?:: + The usual way to deal with this is to use `git revert`. This preserves + the history that the original change was made and was a valuable + contribution, but also introduces a new commit that undoes those changes + because the original had a problem. The commit message of the revert + indicates the commit which was reverted and is usually edited to include + an explanation as to why the revert was made. + +[[ignore-tracked-files]] +How do I ignore changes to a tracked file?:: + Git doesn't provide a way to do this. The reason is that if Git needs + to overwrite this file, such as during a checkout, it doesn't know + whether the changes to the file are precious and should be kept, or + whether they are irrelevant and can safely be destroyed. Therefore, it + has to take the safe route and always preserve them. ++ +It's tempting to try to use certain features of `git update-index`, namely the +assume-unchanged and skip-worktree bits, but these don't work properly for this +purpose and shouldn't be used this way. ++ +If your goal is to modify a configuration file, it can often be helpful to have +a file checked into the repository which is a template or set of defaults which +can then be copied alongside and modified as appropriate. This second, modified +file is usually ignored to prevent accidentally committing it. + +Hooks +----- + +[[restrict-with-hooks]] +How do I use hooks to prevent users from making certain changes?:: + The only safe place to make these changes is on the remote repository + (i.e., the Git server), usually in the `pre-receive` hook or in a + continuous integration (CI) system. These are the locations in which + policy can be enforced effectively. ++ +It's common to try to use `pre-commit` hooks (or, for commit messages, +`commit-msg` hooks) to check these things, which is great if you're working as a +solo developer and want the tooling to help you. However, using hooks on a +developer machine is not effective as a policy control because a user can bypass +these hooks with `--no-verify` without being noticed (among various other ways). +Git assumes that the user is in control of their local repositories and doesn't +try to prevent this or tattle on the user. ++ +In addition, some advanced users find `pre-commit` hooks to be an impediment to +workflows that use temporary commits to stage work in progress or that create +fixup commits, so it's better to push these kinds of checks to the server +anyway. + +Cross-Platform Issues +--------------------- + +[[windows-text-binary]] +I'm on Windows and my text files are detected as binary.:: + Git works best when you store text files as UTF-8. Many programs on + Windows support UTF-8, but some do not and only use the little-endian + UTF-16 format, which Git detects as binary. If you can't use UTF-8 with + your programs, you can specify a working tree encoding that indicates + which encoding your files should be checked out with, while still + storing these files as UTF-8 in the repository. This allows tools like + linkgit:git-diff[1] to work as expected, while still allowing your tools + to work. ++ +To do so, you can specify a linkgit:gitattributes[5] pattern with the +`working-tree-encoding` attribute. For example, the following pattern sets all +C files to use UTF-16LE-BOM, which is a common encoding on Windows: ++ +---- +*.c working-tree-encoding=UTF-16LE-BOM +---- ++ +You will need to run `git add --renormalize` to have this take effect. Note +that if you are making these changes on a project that is used across platforms, +you'll probably want to make it in a per-user configuration file or in the one +in `$GIT_DIR/info/attributes`, since making it in a `.gitattributes` file in the +repository will apply to all users of the repository. ++ +See the following entry for information about normalizing line endings as well, +and see linkgit:gitattributes[5] for more information about attribute files. + +[[windows-diff-control-m]] +I'm on Windows and git diff shows my files as having a `^M` at the end.:: + By default, Git expects files to be stored with Unix line endings. As such, + the carriage return (`^M`) that is part of a Windows line ending is shown + because it is considered to be trailing whitespace. Git defaults to showing + trailing whitespace only on new lines, not existing ones. ++ +You can store the files in the repository with Unix line endings and convert +them automatically to your platform's line endings. To do that, set the +configuration option `core.eol` to `native` and see the following entry for +information about how to configure files as text or binary. ++ +You can also control this behavior with the `core.whitespace` setting if you +don't wish to remove the carriage returns from your line endings. + +[[recommended-storage-settings]] +What's the recommended way to store files in Git?:: + While Git can store and handle any file of any type, there are some + settings that work better than others. In general, we recommend that + text files be stored in UTF-8 without a byte-order mark (BOM) with LF + (Unix-style) endings. We also recommend the use of UTF-8 (again, + without BOM) in commit messages. These are the settings that work best + across platforms and with tools such as `git diff` and `git merge`. ++ +Additionally, if you have a choice between storage formats that are text based +or non-text based, we recommend storing files in the text format and, if +necessary, transforming them into the other format. For example, a text-based +SQL dump with one record per line will work much better for diffing and merging +than an actual database file. Similarly, text-based formats such as Markdown +and AsciiDoc will work better than binary formats such as Microsoft Word and +PDF. ++ +Similarly, storing binary dependencies (e.g., shared libraries or JAR files) or +build products in the repository is generally not recommended. Dependencies and +build products are best stored on an artifact or package server with only +references, URLs, and hashes stored in the repository. ++ +We also recommend setting a linkgit:gitattributes[5] file to explicitly mark +which files are text and which are binary. If you want Git to guess, you can +set the attribute `text=auto`. For example, the following might be appropriate +in some projects: ++ +---- +# By default, guess. +* text=auto +# Mark all C files as text. +*.c text +# Mark all JPEG files as binary. +*.jpg binary +---- ++ +These settings help tools pick the right format for output such as patches and +result in files being checked out in the appropriate line ending for the +platform. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index 3dccab5375..81f2a87e88 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -522,12 +522,61 @@ The exit status determines whether git will use the data from the hook to limit its search. On error, it will fall back to verifying all files and folders. +p4-changelist +~~~~~~~~~~~~~ + +This hook is invoked by `git-p4 submit`. + +The `p4-changelist` hook is executed after the changelist +message has been edited by the user. It can be bypassed with the +`--no-verify` option. It takes a single parameter, the name +of the file that holds the proposed changelist text. Exiting +with a non-zero status causes the command to abort. + +The hook is allowed to edit the changelist file and can be used +to normalize the text into some project standard format. It can +also be used to refuse the Submit after inspect the message file. + +Run `git-p4 submit --help` for details. + +p4-prepare-changelist +~~~~~~~~~~~~~~~~~~~~~ + +This hook is invoked by `git-p4 submit`. + +The `p4-prepare-changelist` hook is executed right after preparing +the default changelist message and before the editor is started. +It takes one parameter, the name of the file that contains the +changelist text. Exiting with a non-zero status from the script +will abort the process. + +The purpose of the hook is to edit the message file in place, +and it is not supressed by the `--no-verify` option. This hook +is called even if `--prepare-p4-only` is set. + +Run `git-p4 submit --help` for details. + +p4-post-changelist +~~~~~~~~~~~~~~~~~~ + +This hook is invoked by `git-p4 submit`. + +The `p4-post-changelist` hook is invoked after the submit has +successfully occured in P4. It takes no parameters and is meant +primarily for notification and cannot affect the outcome of the +git p4 submit action. + +Run `git-p4 submit --help` for details. + p4-pre-submit ~~~~~~~~~~~~~ This hook is invoked by `git-p4 submit`. It takes no parameters and nothing from standard input. Exiting with non-zero status from this script prevent -`git-p4 submit` from launching. Run `git-p4 submit --help` for details. +`git-p4 submit` from launching. It can be bypassed with the `--no-verify` +command line option. Run `git-p4 submit --help` for details. + + post-index-change ~~~~~~~~~~~~~~~~~ diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index ca4378740c..73be8b49f8 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -154,15 +154,17 @@ by doing the following: - Anything unobvious that is applicable to 'master' (in other words, does not depend on anything that is still in 'next' and not in 'master') is applied to a new topic branch that - is forked from the tip of 'master'. This includes both + is forked from the tip of 'master' (or the last feature release, + which is a bit older than 'master'). This includes both enhancements and unobvious fixes to 'master'. A topic branch is named as ai/topic where "ai" is two-letter string named after author's initial and "topic" is a descriptive name of the topic (in other words, "what's the series is about"). - An unobvious fix meant for 'maint' is applied to a new - topic branch that is forked from the tip of 'maint'. The - topic is named as ai/maint-topic. + topic branch that is forked from the tip of 'maint' (or the + oldest and still relevant maintenance branch). The + topic may be named as ai/maint-topic. - Changes that pertain to an existing topic are applied to the branch, but: @@ -174,24 +176,40 @@ by doing the following: - Replacement patches to an existing topic are accepted only for commits not in 'next'. - The above except the "replacement" are all done with: + The initial round is done with: $ git checkout ai/topic ;# or "git checkout -b ai/topic master" $ git am -sc3 mailbox - while patch replacement is often done by: + and replacing an existing topic with subsequent round is done with: - $ git format-patch ai/topic~$n..ai/topic ;# export existing + $ git checkout master...ai/topic ;# try to reapply to the same base + $ git am -sc3 mailbox + + to prepare the new round on a detached HEAD, and then + + $ git range-diff @{-1}... + $ git diff @{-1} - then replace some parts with the new patch, and reapplying: + to double check what changed since the last round, and finally - $ git checkout ai/topic - $ git reset --hard ai/topic~$n - $ git am -sc3 -s 000*.txt + $ git checkout -B @{-1} + + to conclude (the last step is why a topic already in 'next' is + not replaced but updated incrementally). + + Whether it is the initial round or a subsequent round, the topic + may not build even in isolation, or may break the build when + merged to integration branches due to bugs. There may already + be obvious and trivial improvements suggested on the list. The + maintainer often adds an extra commit, with "SQUASH???" in its + title, to fix things up, before publishing the integration + branches to make it usable by other developers for testing. + These changes are what the maintainer is not 100% committed to + (trivial typofixes etc. are often squashed directly into the + patches that need fixing, without being applied as a separate + "SQUASH???" commit), so that they can be removed easily as needed. - The full test suite is always run for 'maint' and 'master' - after patch application; for topic branches the tests are run - as time permits. - Merge maint to master as needed: @@ -371,6 +389,14 @@ Some observations to be made. be included in the next feature release. Being in the 'master' branch typically is. + * Due to the nature of "SQUASH???" fix-ups, if the original author + agrees with the suggested changes, it is OK to squash them to + appropriate patches in the next round (when the suggested change + is small enough, the author should not even bother with + "Helped-by"). It is also OK to drop them from the next round + when the original author does not agree with the suggestion, but + the author is expected to say why somewhere in the discussion. + Appendix -------- diff --git a/Documentation/technical/api-trace2.txt b/Documentation/technical/api-trace2.txt index 4f07ceadcb..6b6085585d 100644 --- a/Documentation/technical/api-trace2.txt +++ b/Documentation/technical/api-trace2.txt @@ -656,7 +656,8 @@ The "exec_id" field is a command-unique id and is only useful if the ------------ `"def_param"`:: - This event is generated to log a global parameter. + This event is generated to log a global parameter, such as a config + setting, command-line flag, or environment variable. + ------------ { |