Inclusive naming: the long game

.gitignore

@@ -67,6 +67,7 @@
 /git-filter-branch
 /git-fmt-merge-msg
 /git-for-each-ref
+/git-for-each-repo
 /git-format-patch
 /git-fsck
 /git-fsck-objects

Documentation/.gitattributes

@@ -1 +1 @@
-*.txt whitespace
+*.txt whitespace=-indent-with-non-tab

Documentation/blame-options.txt

@@ -11,11 +11,12 @@
 
 -L <start>,<end>::
 -L :<funcname>::
-	Annotate only the given line range. May be specified multiple times.
-	Overlapping ranges are allowed.
+	Annotate only the line range given by '<start>,<end>',
+	or by the function name regex '<funcname>'.
+	May be specified multiple times. Overlapping ranges are allowed.
 +
-<start> and <end> are optional. ``-L <start>'' or ``-L <start>,'' spans from
-<start> to end of file. ``-L ,<end>'' spans from start of file to <end>.
+'<start>' and '<end>' are optional. `-L <start>` or `-L <start>,` spans from
+'<start>' to end of file. `-L ,<end>` spans from start of file to '<end>'.
 +
 include::line-range-format.txt[]
 

Documentation/config.txt

@@ -444,6 +444,8 @@ include::config/sequencer.txt[]
 
 include::config/showbranch.txt[]
 
+include::config/sparse.txt[]
+
 include::config/splitindex.txt[]
 
 include::config/ssh.txt[]

Documentation/config/format.txt

@@ -94,6 +94,11 @@ format.outputDirectory::
 	Set a custom directory to store the resulting files instead of the
 	current working directory. All directory components will be created.
 
+format.filenameMaxLength::
+	The maximum length of the output filenames generated by the
+	`format-patch` command; defaults to 64.  Can be overridden
+	by the `--filename-max-length=<n>` command line option.
+
 format.useAutoBase::
 	A boolean value which lets you enable the `--base=auto` option of
 	format-patch by default. Can also be set to "whenAble" to allow

Documentation/config/grep.txt

@@ -16,9 +16,23 @@ grep.extendedRegexp::
 	other than 'default'.
 
 grep.threads::
-	Number of grep worker threads to use.
-	See `grep.threads` in linkgit:git-grep[1] for more information.
+	Number of grep worker threads to use. See `--threads`
+ifndef::git-grep[]
+	in linkgit:git-grep[1]
+endif::git-grep[]
+	for more information.
+
+grep.fullName::
+	If set to true, enable `--full-name` option by default.
 
 grep.fallbackToNoIndex::
 	If set to true, fall back to git grep --no-index if git grep
 	is executed outside of a git repository.  Defaults to false.
+
+ifdef::git-grep[]
+sparse.restrictCmds::
+	See base definition in linkgit:git-config[1]. grep honors
+	sparse.restrictCmds by limiting searches to the sparsity paths in three
+	cases: when searching the working tree, when searching the index with
+	--cached, and when searching a specified commit.
+endif::git-grep[]

Documentation/config/maintenance.txt

@@ -1,10 +1,35 @@
+maintenance.auto::
+	This boolean config option controls whether some commands run
+	`git maintenance run --auto` after doing their normal work. Defaults
+	to true.
+
+maintenance.strategy::
+	This string config option provides a way to specify one of a few
+	recommended schedules for background maintenance. This only affects
+	which tasks are run during `git maintenance run --schedule=X`
+	commands, provided no `--task=<task>` arguments are provided.
+	Further, if a `maintenance.<task>.schedule` config value is set,
+	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.
+* `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 and the
+  `loose-objects` and `incremental-repack` tasks daily.
+
 maintenance.<task>.enabled::
 	This boolean config option controls whether the maintenance task
 	with name `<task>` is run when no `--task` option is specified to
 	`git maintenance run`. These config values are ignored if a
 	`--task` option exists. By default, only `maintenance.gc.enabled`
 	is true.
 
+maintenance.<task>.schedule::
+	This config option controls whether or not the given `<task>` runs
+	during a `git maintenance run --schedule=<frequency>` command. The
+	value must be one of "hourly", "daily", or "weekly".
+
 maintenance.commit-graph.auto::
 	This integer config option controls how often the `commit-graph` task
 	should be run as part of `git maintenance run --auto`. If zero, then

Documentation/config/push.txt

@@ -37,9 +37,9 @@ This mode has become the default in Git 2.0.
 * `matching` - push all branches having the same name on both ends.
   This makes the repository you are pushing to remember the set of
   branches that will be pushed out (e.g. if you always push 'maint'
-  and 'master' there and no other branches, the repository you push
+  and 'main' there and no other branches, the repository you push
   to will have these two branches, and your local 'maint' and
-  'master' will be pushed there).
+  'main' will be pushed there).
 +
 To use this mode effectively, you have to make sure _all_ the
 branches you would push out are ready to be pushed out before

Documentation/config/receive.txt

@@ -124,8 +124,8 @@ receive.procReceiveRefs::
 	`execute_commands` function.
 +
 For example, if this variable is set to "refs/for", pushing to reference
-such as "refs/for/master" will not create or update a reference named
-"refs/for/master", but may create or update a pull request directly by
+such as "refs/for/main" will not create or update a reference named
+"refs/for/main", but may create or update a pull request directly by
 running the hook "proc-receive".
 +
 Optional modifiers can be provided in the beginning of the value to filter

Documentation/config/sparse.txt

@@ -0,0 +1,20 @@
+sparse.restrictCmds::
+	Only meaningful in conjunction with core.sparseCheckout. This option
+	extends sparse checkouts (which limit which paths are written to the
+	working tree), so that output and operations are also limited to the
+	sparsity paths where possible and implemented. The purpose of this
+	option is to (1) focus output for the user on the portion of the
+	repository that is of interest to them, and (2) enable potentially
+	dramatic performance improvements, especially in conjunction with
+	partial clones.
++
+When this option is true (default), some git commands may limit their behavior
+to the paths specified by the sparsity patterns, or to the intersection of
+those paths and any (like `*.c`) that the user might also specify on the
+command line. When false, the affected commands will work on full trees,
+ignoring the sparsity patterns. For now, only git-grep honors this setting.
++
+Note: commands which export, integrity check, or create history will always
+operate on full trees (e.g. fast-export, format-patch, fsck, commit, etc.),
+unaffected by any sparsity patterns. Also, writing commands such as
+sparse-checkout and read-tree will not be affected by this configuration.

Documentation/config/transfer.txt

@@ -53,10 +53,10 @@ If you have multiple hideRefs values, later entries override earlier ones
 +
 If a namespace is in use, the namespace prefix is stripped from each
 reference before it is matched against `transfer.hiderefs` patterns.
-For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
-the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
-is omitted from the advertisements but `refs/heads/master` and
-`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
+For example, if `refs/heads/main` is specified in `transfer.hideRefs` and
+the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/main`
+is omitted from the advertisements but `refs/heads/main` and
+`refs/namespaces/bar/refs/heads/main` are still advertised as so-called
 "have" lines. In order to match refs before stripping, add a `^` in front of
 the ref name. If you combine `!` and `^`, `!` must be specified first.
 +

Documentation/diff-options.txt

@@ -704,7 +704,10 @@ endif::git-format-patch[]
 
 -W::
 --function-context::
-	Show whole surrounding functions of changes.
+	Show whole function as context lines for each change.
+	The function names are determined in the same way as
+	`git diff` works out patch hunk headers (see 'Defining a
+	custom hunk-header' in linkgit:gitattributes[5]).
 
 ifndef::git-format-patch[]
 ifndef::git-log[]

Documentation/git-archimport.txt

@@ -45,7 +45,7 @@ archives that it imports, it is also possible to specify Git branch names
 manually.  To do so, write a Git branch name after each <archive/branch>
 parameter, separated by a colon.  This way, you can shorten the Arch
 branch names and convert Arch jargon to Git jargon, for example mapping a
-"PROJECT{litdd}devo{litdd}VERSION" branch to "master".
+"PROJECT{litdd}devo{litdd}VERSION" branch to "main".
 
 Associating multiple Arch branches to one Git branch is possible; the
 result will make the most sense only if no commits are made to the first

Documentation/git-branch.txt

@@ -331,7 +331,7 @@ $ git branch -D test                                    <2>
 <1> Delete the remote-tracking branches "todo", "html" and "man". The next
     'fetch' or 'pull' will create them again unless you configure them not to.
     See linkgit:git-fetch[1].
-<2> Delete the "test" branch even if the "master" branch (or whichever branch
+<2> Delete the "test" branch even if the "main" branch (or whichever branch
     is currently checked out) does not have all commits from the test branch.
 
 Listing branches from a specific remote::

Documentation/git-bundle.txt

@@ -67,8 +67,8 @@ unbundle <file>::
 	A list of arguments, acceptable to 'git rev-parse' and
 	'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES
 	below), that specifies the specific objects and references
-	to transport.  For example, `master~10..master` causes the
-	current master reference to be packaged along with all objects
+	to transport.  For example, `main~10..main` causes the
+	current main reference to be packaged along with all objects
 	added since its 10th ancestor commit.  There is no explicit
 	limit to the number of references and objects that may be
 	packaged.
@@ -119,12 +119,12 @@ SPECIFYING REFERENCES
 
 'git bundle' will only package references that are shown by
 'git show-ref': this includes heads, tags, and remote heads.  References
-such as `master~1` cannot be packaged, but are perfectly suitable for
+such as `main~1` cannot be packaged, but are perfectly suitable for
 defining the basis.  More than one reference may be packaged, and more
 than one basis can be specified.  The objects packaged are those not
 contained in the union of the given bases.  Each basis can be
-specified explicitly (e.g. `^master~10`), or implicitly (e.g.
-`master~10..master`, `--since=10.days.ago master`).
+specified explicitly (e.g. `^main~10`), or implicitly (e.g.
+`main~10..main`, `--since=10.days.ago main`).
 
 It is very important that the basis used be held by the destination.
 It is okay to err on the side of caution, causing the bundle file
@@ -146,7 +146,7 @@ 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.
+We want to update R2 with development made on the branch main in R1.
 
 To bootstrap the process, you can first create a bundle that does not have
 any basis. You can use a tag to remember up to what commit you last
@@ -155,16 +155,16 @@ with an incremental bundle:
 
 ----------------
 machineA$ cd R1
-machineA$ git bundle create file.bundle master
-machineA$ git tag -f lastR2bundle master
+machineA$ git bundle create file.bundle main
+machineA$ git tag -f lastR2bundle main
 ----------------
 
 Then you transfer file.bundle to the target machine B. Because this
 bundle does not require any existing object to be extracted, you can
 create a new repository on machine B by cloning from it:
 
 ----------------
-machineB$ git clone -b master /home/me/tmp/file.bundle R2
+machineB$ git clone -b main /home/me/tmp/file.bundle R2
 ----------------
 
 This will define a remote called "origin" in the resulting repository that
@@ -186,8 +186,8 @@ incremental bundle to update the other repository:
 
 ----------------
 machineA$ cd R1
-machineA$ git bundle create file.bundle lastR2bundle..master
-machineA$ git tag -f lastR2bundle master
+machineA$ git bundle create file.bundle lastR2bundle..main
+machineA$ git tag -f lastR2bundle main
 ----------------
 
 You then transfer the bundle to the other machine to replace
@@ -208,19 +208,19 @@ the linkgit:git-log[1] command. Here are more examples:
 You can use a tag that is present in both:
 
 ----------------
-$ git bundle create mybundle v1.0.0..master
+$ git bundle create mybundle v1.0.0..main
 ----------------
 
 You can use a basis based on time:
 
 ----------------
-$ git bundle create mybundle --since=10.days master
+$ git bundle create mybundle --since=10.days main
 ----------------
 
 You can use the number of commits:
 
 ----------------
-$ git bundle create mybundle -10 master
+$ git bundle create mybundle -10 main
 ----------------
 
 You can run `git-bundle verify` to see if you can extract from a bundle
@@ -238,7 +238,7 @@ regular repository which it fetches or pulls from. You can, for example, map
 references when fetching:
 
 ----------------
-$ git fetch mybundle master:localRef
+$ git fetch mybundle main:localRef
 ----------------
 
 You can also see what references it offers: