Git 2.24.4

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

.cirrus.yml

@@ -1,15 +0,0 @@
-env:
-  CIRRUS_CLONE_DEPTH: 1
-
-freebsd_12_task:
-  freebsd_instance:
-    image: freebsd-12-1-release-amd64
-  install_script:
-    pkg install -y gettext gmake perl5
-  create_user_script:
-    - pw useradd git
-    - chown -R git:git .
-  build_script:
-    - su git -c gmake
-  test_script:
-    - su git -c 'gmake test'

.gitignore

@@ -158,7 +158,6 @@
 /git-show-branch
 /git-show-index
 /git-show-ref
-/git-sparse-checkout
 /git-stage
 /git-stash
 /git-status

.mailmap

@@ -60,7 +60,6 @@ David Turner <novalis@novalis.org> <dturner@twopensource.com>
 David Turner <novalis@novalis.org> <dturner@twosigma.com>
 Derrick Stolee <dstolee@microsoft.com> <stolee@gmail.com>
 Deskin Miller <deskinm@umich.edu>
-Đoàn Trần Công Danh <congdanhqx@gmail.com> Doan Tran Cong Danh
 Dirk Süsserott <newsletter@dirk.my1.cc>
 Eric Blake <eblake@redhat.com> <ebb9@byu.net>
 Eric Hanchrow <eric.hanchrow@gmail.com> <offby1@blarg.net>

Documentation/CodingGuidelines

@@ -75,7 +75,7 @@ For shell scripts specifically (not exhaustive):
 
  - If you want to find out if a command is available on the user's
    $PATH, you should use 'type <command>', instead of 'which <command>'.
-   The output of 'which' is not machine parsable and its exit code
+   The output of 'which' is not machine parseable and its exit code
    is not reliable across platforms.
 
  - We use POSIX compliant parameter substitutions and avoid bashisms;
@@ -203,7 +203,7 @@ For C programs:
    . since early 2012 with e1327023ea, we have been using an enum
      definition whose last element is followed by a comma.  This, like
      an array initializer that ends with a trailing comma, can be used
-     to reduce the patch noise when adding a new identifier at the end.
+     to reduce the patch noise when adding a new identifer at the end.
 
    . since mid 2017 with cbc0f81d, we have been using designated
      initializers for struct (e.g. "struct t v = { .val = 'a' };").

Documentation/Makefile

@@ -77,7 +77,6 @@ API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technica
 SP_ARTICLES += $(API_DOCS)
 
 TECH_DOCS += MyFirstContribution
-TECH_DOCS += MyFirstObjectWalk
 TECH_DOCS += SubmittingPatches
 TECH_DOCS += technical/hash-function-transition
 TECH_DOCS += technical/http-protocol

Documentation/MyFirstContribution.txt

@@ -38,26 +38,6 @@ $ git clone https://github.com/git/git git
 $ cd git
 ----
 
-[[dependencies]]
-=== Installing Dependencies
-
-To build Git from source, you need to have a handful of dependencies installed
-on your system. For a hint of what's needed, you can take a look at
-`INSTALL`, paying close attention to the section about Git's dependencies on
-external programs and libraries. That document mentions a way to "test-drive"
-our freshly built Git without installing; that's the method we'll be using in
-this tutorial.
-
-Make sure that your environment has everything you need by building your brand
-new clone of Git from the above step:
-
-----
-$ make
-----
-
-NOTE: The Git build is parallelizable. `-j#` is not included above but you can
-use it as you prefer, here and elsewhere.
-
 [[identify-problem]]
 === Identify Problem to Solve
 
@@ -158,6 +138,9 @@ NOTE: When you are developing the Git project, it's preferred that you use the
 `DEVELOPER` flag; if there's some reason it doesn't work for you, you can turn
 it off, but it's a good idea to mention the problem to the mailing list.
 
+NOTE: The Git build is parallelizable. `-j#` is not included above but you can
+use it as you prefer, here and elsewhere.
+
 Great, now your new command builds happily on its own. But nobody invokes it.
 Let's change that.
 
@@ -551,28 +534,6 @@ you want to pass as a parameter something which would usually be interpreted as
 a flag.) `parse_options()` will terminate parsing when it reaches `--` and give
 you the rest of the options afterwards, untouched.
 
-Now that you have a usage hint, you can teach Git how to show it in the general
-command list shown by `git help git` or `git help -a`, which is generated from
-`command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
-line above it in alphabetical order. Now, we can add some attributes about the
-command which impacts where it shows up in the aforementioned help commands. The
-top of `command-list.txt` shares some information about what each attribute
-means; in those help pages, the commands are sorted according to these
-attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
-"mainporcelain". For "mainporcelain" commands, the comments at the top of
-`command-list.txt` indicate we can also optionally add an attribute from another
-list; since `git psuh` shows some information about the user's workspace but
-doesn't modify anything, let's mark it as "info". Make sure to keep your
-attributes in the same style as the rest of `command-list.txt` using spaces to
-align and delineate them:
-
-----
-git-prune-packed                        plumbingmanipulators
-git-psuh                                mainporcelain		info
-git-pull                                mainporcelain           remote
-git-push                                mainporcelain           remote
-----
-
 Build again. Now, when you run with `-h`, you should see your usage printed and
 your command terminated before anything else interesting happens. Great!
 
@@ -785,14 +746,6 @@ will automatically run your PRs through the CI even without the permission given
 but you will not be able to `/submit` your changes until someone allows you to
 use the tool.
 
-NOTE: You can typically find someone who can `/allow` you on GitGitGadget by
-either examining recent pull requests where someone has been granted `/allow`
-(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search:
-is:pr is:open "/allow"]), in which case both the author and the person who
-granted the `/allow` can now `/allow` you, or by inquiring on the
-https://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode
-linking your pull request and asking for someone to `/allow` you.
-
 If the CI fails, you can update your changes with `git rebase -i` and push your
 branch again:
 
@@ -1017,7 +970,7 @@ reviewers the changes you've made that may not be as visible.
 You will also need to go and find the Message-Id of your previous cover letter.
 You can either note it when you send the first series, from the output of `git
 send-email`, or you can look it up on the
-https://lore.kernel.org/git[mailing list]. Find your cover letter in the
+https://public-inbox.org/git[mailing list]. Find your cover letter in the
 archives, click on it, then click "permalink" or "raw" to reveal the Message-Id
 header. It should match:
 

Documentation/MyFirstObjectWalk.txt

@@ -1,905 +0,0 @@
-= My First Object Walk
-
-== What's an Object Walk?
-
-The object walk is a key concept in Git - this is the process that underpins
-operations like object transfer and fsck. Beginning from a given commit, the
-list of objects is found by walking parent relationships between commits (commit
-X based on commit W) and containment relationships between objects (tree Y is
-contained within commit X, and blob Z is located within tree Y, giving our
-working tree for commit X something like `y/z.txt`).
-
-A related concept is the revision walk, which is focused on commit objects and
-their parent relationships and does not delve into other object types. The
-revision walk is used for operations like `git log`.
-
-=== Related Reading
-
-- `Documentation/user-manual.txt` under "Hacking Git" contains some coverage of
-  the revision walker in its various incarnations.
-- `revision.h`
-- https://eagain.net/articles/git-for-computer-scientists/[Git for Computer Scientists]
-  gives a good overview of the types of objects in Git and what your object
-  walk is really describing.
-
-== Setting Up
-
-Create a new branch from `master`.
-
-----
-git checkout -b revwalk origin/master
-----
-
-We'll put our fiddling into a new command. For fun, let's name it `git walken`.
-Open up a new file `builtin/walken.c` and set up the command handler:
-
-----
-/*
- * "git walken"
- *
- * Part of the "My First Object Walk" tutorial.
- */
-
-#include "builtin.h"
-
-int cmd_walken(int argc, const char **argv, const char *prefix)
-{
-	trace_printf(_("cmd_walken incoming...\n"));
-	return 0;
-}
-----
-
-NOTE: `trace_printf()` differs from `printf()` in that it can be turned on or
-off at runtime. For the purposes of this tutorial, we will write `walken` as
-though it is intended for use as a "plumbing" command: that is, a command which
-is used primarily in scripts, rather than interactively by humans (a "porcelain"
-command). So we will send our debug output to `trace_printf()` instead. When
-running, enable trace output by setting the environment variable `GIT_TRACE`.
-
-Add usage text and `-h` handling, like all subcommands should consistently do
-(our test suite will notice and complain if you fail to do so).
-
-----
-int cmd_walken(int argc, const char **argv, const char *prefix)
-{
-	const char * const walken_usage[] = {
-		N_("git walken"),
-		NULL,
-	}
-	struct option options[] = {
-		OPT_END()
-	};
-
-	argc = parse_options(argc, argv, prefix, options, walken_usage, 0);
-
-	...
-}
-----
-
-Also add the relevant line in `builtin.h` near `cmd_whatchanged()`:
-
-----
-int cmd_walken(int argc, const char **argv, const char *prefix);
-----
-
-Include the command in `git.c` in `commands[]` near the entry for `whatchanged`,
-maintaining alphabetical ordering:
-
-----
-{ "walken", cmd_walken, RUN_SETUP },
-----
-
-Add it to the `Makefile` near the line for `builtin/worktree.o`:
-
-----
-BUILTIN_OBJS += builtin/walken.o
-----
-
-Build and test out your command, without forgetting to ensure the `DEVELOPER`
-flag is set, and with `GIT_TRACE` enabled so the debug output can be seen:
-
-----
-$ echo DEVELOPER=1 >>config.mak
-$ make
-$ GIT_TRACE=1 ./bin-wrappers/git walken
-----
-
-NOTE: For a more exhaustive overview of the new command process, take a look at
-`Documentation/MyFirstContribution.txt`.
-
-NOTE: A reference implementation can be found at
-https://github.com/nasamuffin/git/tree/revwalk.
-
-=== `struct rev_cmdline_info`
-
-The definition of `struct rev_cmdline_info` can be found in `revision.h`.
-
-This struct is contained within the `rev_info` struct and is used to reflect
-parameters provided by the user over the CLI.
-
-`nr` represents the number of `rev_cmdline_entry` present in the array.
-
-`alloc` is used by the `ALLOC_GROW` macro. Check `cache.h` - this variable is
-used to track the allocated size of the list.
-
-Per entry, we find:
-
-`item` is the object provided upon which to base the object walk. Items in Git
-can be blobs, trees, commits, or tags. (See `Documentation/gittutorial-2.txt`.)
-
-`name` is the object ID (OID) of the object - a hex string you may be familiar
-with from using Git to organize your source in the past. Check the tutorial
-mentioned above towards the top for a discussion of where the OID can come
-from.
-
-`whence` indicates some information about what to do with the parents of the
-specified object. We'll explore this flag more later on; take a look at
-`Documentation/revisions.txt` to get an idea of what could set the `whence`
-value.
-
-`flags` are used to hint the beginning of the revision walk and are the first
-block under the `#include`s in `revision.h`. The most likely ones to be set in
-the `rev_cmdline_info` are `UNINTERESTING` and `BOTTOM`, but these same flags
-can be used during the walk, as well.
-
-=== `struct rev_info`
-
-This one is quite a bit longer, and many fields are only used during the walk
-by `revision.c` - not configuration options. Most of the configurable flags in
-`struct rev_info` have a mirror in `Documentation/rev-list-options.txt`. It's a
-good idea to take some time and read through that document.
-
-== Basic Commit Walk
-
-First, let's see if we can replicate the output of `git log --oneline`. We'll
-refer back to the implementation frequently to discover norms when performing
-an object walk of our own.
-
-To do so, we'll first find all the commits, in order, which preceded the current
-commit. We'll extract the name and subject of the commit from each.
-
-Ideally, we will also be able to find out which ones are currently at the tip of
-various branches.
-
-=== Setting Up
-
-Preparing for your object walk has some distinct stages.
-
-1. Perform default setup for this mode, and others which may be invoked.
-2. Check configuration files for relevant settings.
-3. Set up the `rev_info` struct.
-4. Tweak the initialized `rev_info` to suit the current walk.
-5. Prepare the `rev_info` for the walk.
-6. Iterate over the objects, processing each one.
-
-==== Default Setups
-
-Before examining configuration files which may modify command behavior, set up
-default state for switches or options your command may have. If your command
-utilizes other Git components, ask them to set up their default states as well.
-For instance, `git log` takes advantage of `grep` and `diff` functionality, so
-its `init_log_defaults()` sets its own state (`decoration_style`) and asks
-`grep` and `diff` to initialize themselves by calling each of their
-initialization functions.
-
-For our first example within `git walken`, we don't intend to use any other
-components within Git, and we don't have any configuration to do.  However, we
-may want to add some later, so for now, we can add an empty placeholder. Create
-a new function in `builtin/walken.c`:
-
-----
-static void init_walken_defaults(void)
-{
-	/*
-	 * We don't actually need the same components `git log` does; leave this
-	 * empty for now.
-	 */
-}
-----
-
-Make sure to add a line invoking it inside of `cmd_walken()`.
-
-----
-int cmd_walken(int argc, const char **argv, const char *prefix)
-{
-	init_walken_defaults();
-}
-----
-
-==== Configuring From `.gitconfig`
-
-Next, we should have a look at any relevant configuration settings (i.e.,
-settings readable and settable from `git config`). This is done by providing a
-callback to `git_config()`; within that callback, you can also invoke methods
-from other components you may need that need to intercept these options. Your
-callback will be invoked once per each configuration value which Git knows about
-(global, local, worktree, etc.).
-
-Similarly to the default values, we don't have anything to do here yet
-ourselves; however, we should call `git_default_config()` if we aren't calling
-any other existing config callbacks.
-
-Add a new function to `builtin/walken.c`:
-
-----
-static int git_walken_config(const char *var, const char *value, void *cb)
-{
-	/*
-	 * For now, we don't have any custom configuration, so fall back to
-	 * the default config.
-	 */
-	return git_default_config(var, value, cb);
-}
-----
-
-Make sure to invoke `git_config()` with it in your `cmd_walken()`:
-
-----
-int cmd_walken(int argc, const char **argv, const char *prefix)
-{
-	...
-
-	git_config(git_walken_config, NULL);
-
-	...
-}
-----
-
-==== Setting Up `rev_info`
-
-Now that we've gathered external configuration and options, it's time to
-initialize the `rev_info` object which we will use to perform the walk. This is
-typically done by calling `repo_init_revisions()` with the repository you intend
-to target, as well as the `prefix` argument of `cmd_walken` and your `rev_info`
-struct.
-
-Add the `struct rev_info` and the `repo_init_revisions()` call:
-----
-int cmd_walken(int argc, const char **argv, const char *prefix)
-{
-	/* This can go wherever you like in your declarations.*/
-	struct rev_info rev;
-	...
-
-	/* This should go after the git_config() call. */
-	repo_init_revisions(the_repository, &rev, prefix);
-
-	...
-}
-----
-
-==== Tweaking `rev_info` For the Walk
-
-We're getting close, but we're still not quite ready to go. Now that `rev` is
-initialized, we can modify it to fit our needs. This is usually done within a
-helper for clarity, so let's add one:
-
-----
-static void final_rev_info_setup(struct rev_info *rev)
-{
-	/*
-	 * We want to mimic the appearance of `git log --oneline`, so let's
-	 * force oneline format.
-	 */
-	get_commit_format("oneline", rev);
-
-	/* Start our object walk at HEAD. */
-	add_head_to_pending(rev);
-}
-----
-
-[NOTE]
-====
-Instead of using the shorthand `add_head_to_pending()`, you could do
-something like this:
-----
-	struct setup_revision_opt opt;
-
-	memset(&opt, 0, sizeof(opt));
-	opt.def = "HEAD";
-	opt.revarg_opt = REVARG_COMMITTISH;
-	setup_revisions(argc, argv, rev, &opt);
-----
-Using a `setup_revision_opt` gives you finer control over your walk's starting
-point.
-====
-
-Then let's invoke `final_rev_info_setup()` after the call to
-`repo_init_revisions()`:
-
-----
-int cmd_walken(int argc, const char **argv, const char *prefix)
-{
-	...
-
-	final_rev_info_setup(&rev);
-
-	...
-}
-----
-
-Later, we may wish to add more arguments to `final_rev_info_setup()`. But for
-now, this is all we need.
-
-==== Preparing `rev_info` For the Walk
-
-Now that `rev` is all initialized and configured, we've got one more setup step
-before we get rolling. We can do this in a helper, which will both prepare the
-`rev_info` for the walk, and perform the walk itself. Let's start the helper
-with the call to `prepare_revision_walk()`, which can return an error without
-dying on its own:
-
-----
-static void walken_commit_walk(struct rev_info *rev)
-{
-	if (prepare_revision_walk(rev))
-		die(_("revision walk setup failed"));
-}
-----
-
-NOTE: `die()` prints to `stderr` and exits the program. Since it will print to
-`stderr` it's likely to be seen by a human, so we will localize it.
-
-==== Performing the Walk!
-
-Finally! We are ready to begin the walk itself. Now we can see that `rev_info`
-can also be used as an iterator; we move to the next item in the walk by using
-`get_revision()` repeatedly. Add the listed variable declarations at the top and
-the walk loop below the `prepare_revision_walk()` call within your
-`walken_commit_walk()`:
-
-----
-static void walken_commit_walk(struct rev_info *rev)
-{
-	struct commit *commit;
-	struct strbuf prettybuf = STRBUF_INIT;
-
-	...
-
-	while ((commit = get_revision(rev))) {
-		if (!commit)
-			continue;
-
-		strbuf_reset(&prettybuf);
-		pp_commit_easy(CMIT_FMT_ONELINE, commit, &prettybuf);
-		puts(prettybuf.buf);
-	}
-	strbuf_release(&prettybuf);
-}
-----
-
-NOTE: `puts()` prints a `char*` to `stdout`. Since this is the part of the
-command we expect to be machine-parsed, we're sending it directly to stdout.
-
-Give it a shot.
-
-----
-$ make
-$ ./bin-wrappers/git walken
-----
-
-You should see all of the subject lines of all the commits in
-your tree's history, in order, ending with the initial commit, "Initial revision
-of "git", the information manager from hell". Congratulations! You've written
-your first revision walk. You can play with printing some additional fields
-from each commit if you're curious; have a look at the functions available in
-`commit.h`.
-
-=== Adding a Filter
-
-Next, let's try to filter the commits we see based on their author. This is
-equivalent to running `git log --author=<pattern>`. We can add a filter by
-modifying `rev_info.grep_filter`, which is a `struct grep_opt`.
-
-First some setup. Add `init_grep_defaults()` to `init_walken_defaults()` and add
-`grep_config()` to `git_walken_config()`:
-
-----
-static void init_walken_defaults(void)
-{
-	init_grep_defaults(the_repository);
-}
-
-...
-
-static int git_walken_config(const char *var, const char *value, void *cb)
-{
-	grep_config(var, value, cb);
-	return git_default_config(var, value, cb);
-}
-----
-
-Next, we can modify the `grep_filter`. This is done with convenience functions
-found in `grep.h`. For fun, we're filtering to only commits from folks using a
-`gmail.com` email address - a not-very-precise guess at who may be working on
-Git as a hobby. Since we're checking the author, which is a specific line in the
-header, we'll use the `append_header_grep_pattern()` helper. We can use
-the `enum grep_header_field` to indicate which part of the commit header we want
-to search.
-
-In `final_rev_info_setup()`, add your filter line:
-
-----
-static void final_rev_info_setup(int argc, const char **argv,
-		const char *prefix, struct rev_info *rev)
-{
-	...
-
-	append_header_grep_pattern(&rev->grep_filter, GREP_HEADER_AUTHOR,
-		"gmail");
-	compile_grep_patterns(&rev->grep_filter);
-
-	...
-}
-----
-
-`append_header_grep_pattern()` adds your new "gmail" pattern to `rev_info`, but
-it won't work unless we compile it with `compile_grep_patterns()`.
-
-NOTE: If you are using `setup_revisions()` (for example, if you are passing a
-`setup_revision_opt` instead of using `add_head_to_pending()`), you don't need
-to call `compile_grep_patterns()` because `setup_revisions()` calls it for you.
-
-NOTE: We could add the same filter via the `append_grep_pattern()` helper if we
-wanted to, but `append_header_grep_pattern()` adds the `enum grep_context` and
-`enum grep_pat_token` for us.
-
-=== Changing the Order
-
-There are a few ways that we can change the order of the commits during a
-revision walk. Firstly, we can use the `enum rev_sort_order` to choose from some
-typical orderings.
-
-`topo_order` is the same as `git log --topo-order`: we avoid showing a parent
-before all of its children have been shown, and we avoid mixing commits which
-are in different lines of history. (`git help log`'s section on `--topo-order`
-has a very nice diagram to illustrate this.)
-
-Let's see what happens when we run with `REV_SORT_BY_COMMIT_DATE` as opposed to
-`REV_SORT_BY_AUTHOR_DATE`. Add the following:
-
-----
-static void final_rev_info_setup(int argc, const char **argv,
-		const char *prefix, struct rev_info *rev)
-{
-	...
-
-	rev->topo_order = 1;
-	rev->sort_order = REV_SORT_BY_COMMIT_DATE;
-
-	...
-}
-----
-
-Let's output this into a file so we can easily diff it with the walk sorted by
-author date.
-
-----
-$ make
-$ ./bin-wrappers/git walken > commit-date.txt
-----
-
-Then, let's sort by author date and run it again.
-
-----
-static void final_rev_info_setup(int argc, const char **argv,
-		const char *prefix, struct rev_info *rev)
-{
-	...
-
-	rev->topo_order = 1;
-	rev->sort_order = REV_SORT_BY_AUTHOR_DATE;
-
-	...
-}
-----
-
-----
-$ make
-$ ./bin-wrappers/git walken > author-date.txt
-----
-
-Finally, compare the two. This is a little less helpful without object names or
-dates, but hopefully we get the idea.
-
-----
-$ diff -u commit-date.txt author-date.txt
-----
-
-This display indicates that commits can be reordered after they're written, for
-example with `git rebase`.
-
-Let's try one more reordering of commits. `rev_info` exposes a `reverse` flag.
-Set that flag somewhere inside of `final_rev_info_setup()`:
-
-----
-static void final_rev_info_setup(int argc, const char **argv, const char *prefix,
-		struct rev_info *rev)
-{
-	...
-
-	rev->reverse = 1;
-
-	...
-}
-----
-
-Run your walk again and note the difference in order. (If you remove the grep
-pattern, you should see the last commit this call gives you as your current
-HEAD.)
-
-== Basic Object Walk
-
-So far we've been walking only commits. But Git has more types of objects than
-that! Let's see if we can walk _all_ objects, and find out some information
-about each one.
-
-We can base our work on an example. `git pack-objects` prepares all kinds of
-objects for packing into a bitmap or packfile. The work we are interested in
-resides in `builtins/pack-objects.c:get_object_list()`; examination of that
-function shows that the all-object walk is being performed by
-`traverse_commit_list()` or `traverse_commit_list_filtered()`. Those two
-functions reside in `list-objects.c`; examining the source shows that, despite
-the name, these functions traverse all kinds of objects. Let's have a look at
-the arguments to `traverse_commit_list_filtered()`, which are a superset of the
-arguments to the unfiltered version.
-
-- `struct list_objects_filter_options *filter_options`: This is a struct which
-  stores a filter-spec as outlined in `Documentation/rev-list-options.txt`.
-- `struct rev_info *revs`: This is the `rev_info` used for the walk.
-- `show_commit_fn show_commit`: A callback which will be used to handle each
-  individual commit object.
-- `show_object_fn show_object`: A callback which will be used to handle each
-  non-commit object (so each blob, tree, or tag).
-- `void *show_data`: A context buffer which is passed in turn to `show_commit`
-  and `show_object`.
-- `struct oidset *omitted`: A linked-list of object IDs which the provided
-  filter caused to be omitted.
-
-It looks like this `traverse_commit_list_filtered()` uses callbacks we provide
-instead of needing us to call it repeatedly ourselves. Cool! Let's add the
-callbacks first.
-
-For the sake of this tutorial, we'll simply keep track of how many of each kind
-of object we find. At file scope in `builtin/walken.c` add the following
-tracking variables:
-
-----
-static int commit_count;
-static int tag_count;
-static int blob_count;
-static int tree_count;
-----
-
-Commits are handled by a different callback than other objects; let's do that
-one first:
-
-----
-static void walken_show_commit(struct commit *cmt, void *buf)
-{
-	commit_count++;
-}
-----
-
-The `cmt` argument is fairly self-explanatory. But it's worth mentioning that
-the `buf` argument is actually the context buffer that we can provide to the
-traversal calls - `show_data`, which we mentioned a moment ago.
-
-Since we have the `struct commit` object, we can look at all the same parts that
-we looked at in our earlier commit-only walk. For the sake of this tutorial,
-though, we'll just increment the commit counter and move on.
-
-The callback for non-commits is a little different, as we'll need to check
-which kind of object we're dealing with:
-
-----
-static void walken_show_object(struct object *obj, const char *str, void *buf)
-{
-	switch (obj->type) {
-	case OBJ_TREE:
-		tree_count++;
-		break;
-	case OBJ_BLOB:
-		blob_count++;
-		break;
-	case OBJ_TAG:
-		tag_count++;
-		break;
-	case OBJ_COMMIT:
-		BUG("unexpected commit object in walken_show_object\n");
-	default:
-		BUG("unexpected object type %s in walken_show_object\n",
-			type_name(obj->type));
-	}
-}
-----
-
-Again, `obj` is fairly self-explanatory, and we can guess that `buf` is the same
-context pointer that `walken_show_commit()` receives: the `show_data` argument
-to `traverse_commit_list()` and `traverse_commit_list_filtered()`. Finally,
-`str` contains the name of the object, which ends up being something like
-`foo.txt` (blob), `bar/baz` (tree), or `v1.2.3` (tag).
-
-To help assure us that we aren't double-counting commits, we'll include some
-complaining if a commit object is routed through our non-commit callback; we'll
-also complain if we see an invalid object type. Since those two cases should be
-unreachable, and would only change in the event of a semantic change to the Git
-codebase, we complain by using `BUG()` - which is a signal to a developer that
-the change they made caused unintended consequences, and the rest of the
-codebase needs to be updated to understand that change. `BUG()` is not intended
-to be seen by the public, so it is not localized.
-
-Our main object walk implementation is substantially different from our commit
-walk implementation, so let's make a new function to perform the object walk. We
-can perform setup which is applicable to all objects here, too, to keep separate
-from setup which is applicable to commit-only walks.
-
-We'll start by enabling all types of objects in the `struct rev_info`.  We'll
-also turn on `tree_blobs_in_commit_order`, which means that we will walk a
-commit's tree and everything it points to immediately after we find each commit,
-as opposed to waiting for the end and walking through all trees after the commit
-history has been discovered. With the appropriate settings configured, we are
-ready to call `prepare_revision_walk()`.
-
-----
-static void walken_object_walk(struct rev_info *rev)
-{
-	rev->tree_objects = 1;
-	rev->blob_objects = 1;
-	rev->tag_objects = 1;
-	rev->tree_blobs_in_commit_order = 1;
-
-	if (prepare_revision_walk(rev))
-		die(_("revision walk setup failed"));
-
-	commit_count = 0;
-	tag_count = 0;
-	blob_count = 0;
-	tree_count = 0;
-----
-
-Let's start by calling just the unfiltered walk and reporting our counts.
-Complete your implementation of `walken_object_walk()`:
-
-----
-	traverse_commit_list(rev, walken_show_commit, walken_show_object, NULL);
-
-	printf("commits %d\nblobs %d\ntags %d\ntrees %d\n", commit_count,
-		blob_count, tag_count, tree_count);
-}
-----
-
-NOTE: This output is intended to be machine-parsed. Therefore, we are not
-sending it to `trace_printf()`, and we are not localizing it - we need scripts
-to be able to count on the formatting to be exactly the way it is shown here.
-If we were intending this output to be read by humans, we would need to localize
-it with `_()`.
-
-Finally, we'll ask `cmd_walken()` to use the object walk instead. Discussing
-command line options is out of scope for this tutorial, so we'll just hardcode
-a branch we can change at compile time. Where you call `final_rev_info_setup()`
-and `walken_commit_walk()`, instead branch like so:
-
-----
-	if (1) {
-		add_head_to_pending(&rev);
-		walken_object_walk(&rev);
-	} else {
-		final_rev_info_setup(argc, argv, prefix, &rev);
-		walken_commit_walk(&rev);
-	}
-----
-
-NOTE: For simplicity, we've avoided all the filters and sorts we applied in
-`final_rev_info_setup()` and simply added `HEAD` to our pending queue. If you
-want, you can certainly use the filters we added before by moving
-`final_rev_info_setup()` out of the conditional and removing the call to
-`add_head_to_pending()`.
-
-Now we can try to run our command! It should take noticeably longer than the
-commit walk, but an examination of the output will give you an idea why. Your
-output should look similar to this example, but with different counts:
-
-----
-Object walk completed. Found 55733 commits, 100274 blobs, 0 tags, and 104210 trees.
-----
-
-This makes sense. We have more trees than commits because the Git project has
-lots of subdirectories which can change, plus at least one tree per commit. We
-have no tags because we started on a commit (`HEAD`) and while tags can point to
-commits, commits can't point to tags.
-
-NOTE: You will have different counts when you run this yourself! The number of
-objects grows along with the Git project.
-
-=== Adding a Filter
-
-There are a handful of filters that we can apply to the object walk laid out in
-`Documentation/rev-list-options.txt`. These filters are typically useful for
-operations such as creating packfiles or performing a partial clone. They are
-defined in `list-objects-filter-options.h`. For the purposes of this tutorial we
-will use the "tree:1" filter, which causes the walk to omit all trees and blobs
-which are not directly referenced by commits reachable from the commit in
-`pending` when the walk begins. (`pending` is the list of objects which need to
-be traversed during a walk; you can imagine a breadth-first tree traversal to
-help understand. In our case, that means we omit trees and blobs not directly
-referenced by `HEAD` or `HEAD`'s history, because we begin the walk with only
-`HEAD` in the `pending` list.)
-
-First, we'll need to `#include "list-objects-filter-options.h`" and set up the
-`struct list_objects_filter_options` at the top of the function.
-
-----
-static void walken_object_walk(struct rev_info *rev)
-{
-	struct list_objects_filter_options filter_options = {};
-
-	...
-----
-
-For now, we are not going to track the omitted objects, so we'll replace those
-parameters with `NULL`. For the sake of simplicity, we'll add a simple
-build-time branch to use our filter or not. Replace the line calling
-`traverse_commit_list()` with the following, which will remind us which kind of
-walk we've just performed:
-
-----
-	if (0) {
-		/* Unfiltered: */
-		trace_printf(_("Unfiltered object walk.\n"));
-		traverse_commit_list(rev, walken_show_commit,
-				walken_show_object, NULL);
-	} else {
-		trace_printf(
-			_("Filtered object walk with filterspec 'tree:1'.\n"));
-		parse_list_objects_filter(&filter_options, "tree:1");
-
-		traverse_commit_list_filtered(&filter_options, rev,
-			walken_show_commit, walken_show_object, NULL, NULL);
-	}
-----
-
-`struct list_objects_filter_options` is usually built directly from a command
-line argument, so the module provides an easy way to build one from a string.
-Even though we aren't taking user input right now, we can still build one with
-a hardcoded string using `parse_list_objects_filter()`.
-
-With the filter spec "tree:1", we are expecting to see _only_ the root tree for
-each commit; therefore, the tree object count should be less than or equal to
-the number of commits. (For an example of why that's true: `git commit --revert`
-points to the same tree object as its grandparent.)
-
-=== Counting Omitted Objects
-
-We also have the capability to enumerate all objects which were omitted by a
-filter, like with `git log --filter=<spec> --filter-print-omitted`. Asking
-`traverse_commit_list_filtered()` to populate the `omitted` list means that our
-object walk does not perform any better than an unfiltered object walk; all
-reachable objects are walked in order to populate the list.
-
-First, add the `struct oidset` and related items we will use to iterate it:
-
-----
-static void walken_object_walk(
-	...
-
-	struct oidset omitted;
-	struct oidset_iter oit;
-	struct object_id *oid = NULL;
-	int omitted_count = 0;
-	oidset_init(&omitted, 0);
-
-	...
-----
-
-Modify the call to `traverse_commit_list_filtered()` to include your `omitted`
-object:
-
-----
-	...
-
-		traverse_commit_list_filtered(&filter_options, rev,
-			walken_show_commit, walken_show_object, NULL, &omitted);
-
-	...
-----
-
-Then, after your traversal, the `oidset` traversal is pretty straightforward.
-Count all the objects within and modify the print statement:
-
-----
-	/* Count the omitted objects. */
-	oidset_iter_init(&omitted, &oit);
-
-	while ((oid = oidset_iter_next(&oit)))
-		omitted_count++;
-
-	printf("commits %d\nblobs %d\ntags %d\ntrees%d\nomitted %d\n",
-		commit_count, blob_count, tag_count, tree_count, omitted_count);
-----
-
-By running your walk with and without the filter, you should find that the total
-object count in each case is identical. You can also time each invocation of
-the `walken` subcommand, with and without `omitted` being passed in, to confirm
-to yourself the runtime impact of tracking all omitted objects.
-
-=== Changing the Order
-
-Finally, let's demonstrate that you can also reorder walks of all objects, not
-just walks of commits. First, we'll make our handlers chattier - modify
-`walken_show_commit()` and `walken_show_object()` to print the object as they
-go:
-
-----
-static void walken_show_commit(struct commit *cmt, void *buf)
-{
-	trace_printf("commit: %s\n", oid_to_hex(&cmt->object.oid));
-	commit_count++;
-}
-
-static void walken_show_object(struct object *obj, const char *str, void *buf)
-{
-	trace_printf("%s: %s\n", type_name(obj->type), oid_to_hex(&obj->oid));
-
-	...
-}
-----
-
-NOTE: Since we will be examining this output directly as humans, we'll use
-`trace_printf()` here. Additionally, since this change introduces a significant
-number of printed lines, using `trace_printf()` will allow us to easily silence
-those lines without having to recompile.
-
-(Leave the counter increment logic in place.)
-
-With only that change, run again (but save yourself some scrollback):
-
-----
-$ GIT_TRACE=1 ./bin-wrappers/git walken | head -n 10
-----
-
-Take a look at the top commit with `git show` and the object ID you printed; it
-should be the same as the output of `git show HEAD`.
-
-Next, let's change a setting on our `struct rev_info` within
-`walken_object_walk()`. Find where you're changing the other settings on `rev`,
-such as `rev->tree_objects` and `rev->tree_blobs_in_commit_order`, and add the
-`reverse` setting at the bottom:
-
-----
-	...
-
-	rev->tree_objects = 1;
-	rev->blob_objects = 1;
-	rev->tag_objects = 1;
-	rev->tree_blobs_in_commit_order = 1;
-	rev->reverse = 1;
-
-	...
-----
-
-Now, run again, but this time, let's grab the last handful of objects instead
-of the first handful:
-
-----
-$ make
-$ GIT_TRACE=1 ./bin-wrappers git walken | tail -n 10
-----
-
-The last commit object given should have the same OID as the one we saw at the
-top before, and running `git show <oid>` with that OID should give you again
-the same results as `git show HEAD`. Furthermore, if you run and examine the
-first ten lines again (with `head` instead of `tail` like we did before applying
-the `reverse` setting), you should see that now the first commit printed is the
-initial commit, `e83c5163`.
-
-== Wrapping Up
-
-Let's review. In this tutorial, we:
-
-- Built a commit walk from the ground up
-- Enabled a grep filter for that commit walk
-- Changed the sort order of that filtered commit walk
-- Built an object walk (tags, commits, trees, and blobs) from the ground up
-- Learned how to add a filter-spec to an object walk
-- Changed the display order of the filtered object walk

Documentation/RelNotes/1.5.0.txt

@@ -251,7 +251,7 @@ Updates in v1.5.0 since v1.4.4 series
    the repository when that happens.
 
 
-* Cruft removal
+* Crufts removal
 
  - We used to say "old commits are retrievable using reflog and
    'master@{yesterday}' syntax as long as you haven't run
@@ -379,7 +379,7 @@ Updates in v1.5.0 since v1.4.4 series
  - The value of i18n.commitencoding in the originating
    repository is recorded in the commit object on the "encoding"
    header, if it is not UTF-8.  git-log and friends notice this,
-   and re-encodes the message to the log output encoding when
+   and reencodes the message to the log output encoding when
    displaying, if they are different.  The log output encoding
    is determined by "git log --encoding=<encoding>",
    i18n.logoutputencoding configuration, or i18n.commitencoding

Documentation/RelNotes/1.6.2.txt

@@ -11,7 +11,7 @@ push running this release will issue a big warning when the
 configuration variable is missing.  Please refer to:
 
   http://git.or.cz/gitwiki/GitFaq#non-bare
-  https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
+  http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
 
 for more details on the reason why this change is needed and the
 transition plan.

Documentation/RelNotes/1.6.3.txt

@@ -11,7 +11,7 @@ push running this release will issue a big warning when the
 configuration variable is missing.  Please refer to:
 
   http://git.or.cz/gitwiki/GitFaq#non-bare
-  https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
+  http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
 
 for more details on the reason why this change is needed and the
 transition plan.

Documentation/RelNotes/1.6.4.txt

@@ -11,7 +11,7 @@ push running this release will issue a big warning when the
 configuration variable is missing.  Please refer to:
 
   http://git.or.cz/gitwiki/GitFaq#non-bare
-  https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
+  http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
 
 for more details on the reason why this change is needed and the
 transition plan.

Documentation/RelNotes/1.6.5.4.txt

@@ -10,7 +10,7 @@ Fixes since v1.6.5.3
 
  * "git prune-packed" gave progress output even when its standard error is
    not connected to a terminal; this caused cron jobs that run it to
-   produce cruft.
+   produce crufts.
 
  * "git pack-objects --all-progress" is an option to ask progress output
    from write-object phase _if_ progress output were to be produced, and

Documentation/RelNotes/1.6.5.txt

@@ -22,7 +22,7 @@ push running this release will issue a big warning when the
 configuration variable is missing.  Please refer to:
 
   http://git.or.cz/gitwiki/GitFaq#non-bare
-  https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
+  http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
 
 for more details on the reason why this change is needed and the
 transition plan.

Documentation/RelNotes/1.6.6.txt

@@ -64,7 +64,7 @@ users will fare this time.
    Please refer to:
 
    http://git.or.cz/gitwiki/GitFaq#non-bare
-   https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
+   http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
 
    for more details on the reason why this change is needed and the
    transition process that already took place so far.

Documentation/RelNotes/1.7.0.2.txt

@@ -34,7 +34,7 @@ Fixes since v1.7.0.1
  * "git status" in 1.7.0 lacked the optimization we used to have in 1.6.X series
    to speed up scanning of large working tree.
 
- * "gitweb" did not diagnose parsing errors properly while reading its configuration
+ * "gitweb" did not diagnose parsing errors properly while reading tis configuration
    file.
 
 And other minor fixes and documentation updates.

Documentation/RelNotes/1.7.10.4.txt

@@ -7,7 +7,7 @@ Fixes since v1.7.10.3
  * The message file for Swedish translation has been updated a bit.
 
  * A name taken from mailmap was copied into an internal buffer
-   incorrectly and could overrun the buffer if it is too long.
+   incorrectly and could overun the buffer if it is too long.
 
  * A malformed commit object that has a header line chomped in the
    middle could kill git with a NULL pointer dereference.

Documentation/RelNotes/1.7.12.3.txt

@@ -25,7 +25,7 @@ Fixes since v1.7.12.2
    its Accept-Encoding header.
 
  * "git receive-pack" (the counterpart to "git push") did not give
-   progress output while processing objects it received to the user
+   progress output while processing objects it received to the puser
    when run over the smart-http protocol.
 
  * "git status" honored the ignore=dirty settings in .gitmodules but

Documentation/RelNotes/1.7.5.3.txt

@@ -22,7 +22,7 @@ Fixes since v1.7.5.2
  * "git log --stdin path" with an input that has additional pathspec
    used to corrupt memory.
 
- * "git send-pack" (hence "git push") over smart-HTTP protocol could
+ * "git send-pack" (hence "git push") over smalt-HTTP protocol could
    deadlock when the client side pack-object died early.
 
  * Compressed tarball gitweb generates used to be made with the timestamp

Documentation/RelNotes/1.8.0.txt

@@ -233,7 +233,7 @@ to them for details).
    together, misdetected branches.
 
  * "git receive-pack" (the counterpart to "git push") did not give
-   progress output while processing objects it received to the user
+   progress output while processing objects it received to the puser
    when run over the smart-http protocol.
 
  * When you misspell the command name you give to the "exec" action in

Documentation/RelNotes/1.8.4.1.txt

@@ -15,7 +15,7 @@ Fixes since v1.8.4
    in 1.8.4-rc1).
 
  * "git rebase -i" and other scripted commands were feeding a
-   random, data dependent error message to 'echo' and expecting it
+   random, data dependant error message to 'echo' and expecting it
    to come out literally.
 
  * Setting the "submodule.<name>.path" variable to the empty

Documentation/RelNotes/1.8.4.txt

@@ -58,7 +58,7 @@ Foreign interfaces, subsystems and ports.
    credential helper interface from Git.pm.
 
  * Update build for Cygwin 1.[57].  Torsten Bögershausen reports that
-   this is fine with Cygwin 1.7 (cf. <51A606A0.5060101@web.de>) so let's try moving it
+   this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it
    ahead.
 
  * The credential helper to talk to keychain on OS X (in contrib/) has

Documentation/RelNotes/2.1.3.txt

@@ -13,7 +13,7 @@ Git v2.1.3 Release Notes
    they are new enough to support the `--output` option.
 
  * "git pack-objects" forgot to disable the codepath to generate
-   object reachability bitmap when it needs to split the resulting
+   object recheability bitmap when it needs to split the resulting
    pack.
 
  * "gitweb" used deprecated CGI::startfrom, which was removed from

Documentation/RelNotes/2.10.0.txt

@@ -478,7 +478,7 @@ notes for details).
  * One part of "git am" had an oddball helper function that called
    stuff from outside "his" as opposed to calling what we have "ours",
    which was not gender-neutral and also inconsistent with the rest of
-   the system where outside stuff is usually called "theirs" in
+   the system where outside stuff is usuall called "theirs" in
    contrast to "ours".
 
  * "git blame file" allowed the lineage of lines in the uncommitted,

Documentation/RelNotes/2.10.2.txt

@@ -86,7 +86,7 @@ Fixes since v2.10.1
    by refusing to check out a branch that is already checked out in
    another worktree.  However, this also prevented checking out a
    branch, which is designated as the primary branch of a bare
-   repository, in a worktree that is connected to the bare
+   reopsitory, in a worktree that is connected to the bare
    repository.  The check has been corrected to allow it.
 
  * "git rebase" immediately after "git clone" failed to find the fork

Documentation/RelNotes/2.11.1.txt

@@ -104,7 +104,7 @@ Fixes since v2.11
    "git difftool --dir-diff" from a subdirectory never worked. This
    has been fixed.
 
- * "git p4" that tracks multiple p4 paths imported a single changelist
+ * "git p4" that tracks multile p4 paths imported a single changelist
    that touches files in these multiple paths as one commit, followed
    by many empty commits.  This has been fixed.
 

Documentation/RelNotes/2.12.0.txt

@@ -315,7 +315,7 @@ notes for details).
    "git difftool --dir-diff" from a subdirectory never worked. This
    has been fixed.
 
- * "git p4" that tracks multiple p4 paths imported a single changelist
+ * "git p4" that tracks multile p4 paths imported a single changelist
    that touches files in these multiple paths as one commit, followed
    by many empty commits.  This has been fixed.
 

Documentation/RelNotes/2.13.0.txt

@@ -177,7 +177,7 @@ UI, Workflows & Features
    been changed to enable "--decorate".
 
  * The output from "git status --short" has been extended to show
-   various kinds of dirtiness in submodules differently; instead of to
+   various kinds of dirtyness in submodules differently; instead of to
    "M" for modified, 'm' and '?' can be shown to signal changes only
    to the working tree of the submodule but not the commit that is
    checked out.

Documentation/RelNotes/2.13.3.txt

@@ -25,7 +25,7 @@ Fixes since v2.13.2
  * The code to pick up and execute command alias definition from the
    configuration used to switch to the top of the working tree and
    then come back when the expanded alias was executed, which was
-   unnecessarily complex.  Attempt to simplify the logic by using the
+   unnecessarilyl complex.  Attempt to simplify the logic by using the
    early-config mechanism that does not chdir around.
 
  * "git add -p" were updated in 2.12 timeframe to cope with custom
@@ -35,7 +35,7 @@ Fixes since v2.13.2
  * Fix a recent regression to "git rebase -i" and add tests that would
    have caught it and others.
 
- * An unaligned 32-bit access in pack-bitmap code has been corrected.
+ * An unaligned 32-bit access in pack-bitmap code ahs been corrected.
 
  * Tighten error checks for invalid "git apply" input.
 

Documentation/RelNotes/2.14.0.txt

@@ -141,7 +141,7 @@ Performance, Internal Implementation, Development Support etc.
  * Some platforms have ulong that is smaller than time_t, and our
    historical use of ulong for timestamp would mean they cannot
    represent some timestamp that the platform allows.  Invent a
-   separate and dedicated timestamp_t (so that we can distinguish
+   separate and dedicated timestamp_t (so that we can distingiuish
    timestamps and a vanilla ulongs, which along is already a good
    move), and then declare uintmax_t is the type to be used as the
    timestamp_t.
@@ -442,7 +442,7 @@ notes for details).
  * The code to pick up and execute command alias definition from the
    configuration used to switch to the top of the working tree and
    then come back when the expanded alias was executed, which was
-   unnecessarily complex.  Attempt to simplify the logic by using the
+   unnecessarilyl complex.  Attempt to simplify the logic by using the
    early-config mechanism that does not chdir around.
 
  * Fix configuration codepath to pay proper attention to commondir

Documentation/RelNotes/2.16.0.txt

@@ -407,7 +407,7 @@ Fixes since v2.15
    (merge eef3df5a93 bw/pathspec-match-submodule-boundary later to maint).
 
  * Amending commits in git-gui broke the author name that is non-ascii
-   due to incorrect encoding conversion.
+   due to incorrect enconding conversion.
 
  * Recent update to the submodule configuration code broke "diff-tree"
    by accidentally stopping to read from the index upfront.

Documentation/RelNotes/2.16.3.txt

@@ -24,7 +24,7 @@ Fixes since v2.16.2
 
  * The http tracing code, often used to debug connection issues,
    learned to redact potentially sensitive information from its output
-   so that it can be more safely shareable.
+   so that it can be more safely sharable.
 
  * Crash fix for a corner case where an error codepath tried to unlock
    what it did not acquire lock on.

Documentation/RelNotes/2.17.0.txt

@@ -216,7 +216,7 @@ Fixes since v2.16
 
  * The http tracing code, often used to debug connection issues,
    learned to redact potentially sensitive information from its output
-   so that it can be more safely shareable.
+   so that it can be more safely sharable.
    (merge 8ba18e6fa4 jt/http-redact-cookies later to maint).
 
  * Crash fix for a corner case where an error codepath tried to unlock

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.

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.

Documentation/RelNotes/2.17.6.txt

@@ -0,0 +1,16 @@
+Git v2.17.6 Release Notes
+=========================
+
+This release addresses the security issues CVE-2021-21300.
+
+Fixes since v2.17.5
+-------------------
+
+ * CVE-2021-21300:
+   On case-insensitive file systems with support for symbolic links,
+   if Git is configured globally to apply delay-capable clean/smudge
+   filters (such as Git LFS), Git could be fooled into running
+   remote code during a clone.
+
+Credit for finding and fixing this vulnerability goes to Matheus
+Tavares, helped by Johannes Schindelin.

Documentation/RelNotes/2.18.0.txt

@@ -179,7 +179,7 @@ Performance, Internal Implementation, Development Support etc.
    (merge 00a3da2a13 nd/remove-ignore-env-field later to maint).
 
  * Code to find the length to uniquely abbreviate object names based
-   on packfile content, which is a relatively recent addition, has been
+   on packfile content, which is a relatively recent addtion, has been
    optimized to use the same fan-out table.
 
  * The mechanism to use parse-options API to automate the command line

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.

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.

Documentation/RelNotes/2.18.5.txt

@@ -0,0 +1,6 @@
+Git v2.18.5 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6 to address
+the security issue CVE-2021-21300; see the release notes for that
+version for details.

Documentation/RelNotes/2.19.0.txt

@@ -106,7 +106,7 @@ Performance, Internal Implementation, Development Support etc.
  * The conversion to pass "the_repository" and then "a_repository"
    throughout the object access API continues.
 
- * Continuing with the idea to programmatically enumerate various
+ * Continuing with the idea to programatically enumerate various
    pieces of data required for command line completion, teach the
    codebase to report the list of configuration variables
    subcommands care about to help complete them.

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.

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.

Documentation/RelNotes/2.19.6.txt

@@ -0,0 +1,6 @@
+Git v2.19.6 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6 and
+v2.18.5 to address the security issue CVE-2021-21300; see the
+release notes for these versions for details.

Documentation/RelNotes/2.20.0.txt

@@ -119,7 +119,7 @@ UI, Workflows & Features
    alias expansion.
 
  * The documentation of "git gc" has been updated to mention that it
-   is no longer limited to "pruning away cruft" but also updates
+   is no longer limited to "pruning away crufts" but also updates
    ancillary files like commit-graph as a part of repository
    optimization.
 

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.

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.

Documentation/RelNotes/2.20.5.txt

@@ -0,0 +1,6 @@
+Git v2.20.5 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5
+and v2.19.6 to address the security issue CVE-2021-21300; see
+the release notes for these versions for details.

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.

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.

Documentation/RelNotes/2.21.4.txt

@@ -0,0 +1,6 @@
+Git v2.21.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5,
+v2.19.6 and v2.20.5 to address the security issue CVE-2021-21300;
+see the release notes for these versions for details.

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.

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.

Documentation/RelNotes/2.22.5.txt

@@ -0,0 +1,7 @@
+Git v2.22.5 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6,
+v2.18.5, v2.19.6, v2.20.5 and v2.21.4 to address the security
+issue CVE-2021-21300; see the release notes for these versions
+for details.

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.

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.

Documentation/RelNotes/2.23.4.txt

@@ -0,0 +1,7 @@
+Git v2.23.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5,
+v2.19.6, v2.20.5, v2.21.4 and v2.22.5 to address the security
+issue CVE-2021-21300; see the release notes for these versions
+for details.

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.

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.

Documentation/RelNotes/2.24.4.txt

@@ -0,0 +1,7 @@
+Git v2.24.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5,
+v2.19.6, v2.20.5, v2.21.4, v2.22.5 and v2.23.4 to address the
+security issue CVE-2021-21300; see the release notes for these
+versions for details.

Documentation/RelNotes/2.25.0.txt

@@ -1,353 +0,0 @@
-Git 2.25 Release Notes
-======================
-
-Updates since v2.24
--------------------
-
-Backward compatibility notes
-
-
-UI, Workflows & Features
-
- * A tutorial on object enumeration has been added.
-
- * The branch description ("git branch --edit-description") has been
-   used to fill the body of the cover letters by the format-patch
-   command; this has been enhanced so that the subject can also be
-   filled.
-
- * "git rebase --preserve-merges" has been marked as deprecated; this
-   release stops advertising it in the "git rebase -h" output.
-
- * The code to generate multi-pack index learned to show (or not to
-   show) progress indicators.
-
- * "git apply --3way" learned to honor merge.conflictStyle
-   configuration variable, like merges would.
-
- * The custom format for "git log --format=<format>" learned the l/L
-   placeholder that is similar to e/E that fills in the e-mail
-   address, but only the local part on the left side of '@'.
-
- * Documentation pages for "git shortlog" now list commit limiting
-   options explicitly.
-
- * The patterns to detect function boundary for Elixir language has
-   been added.
-
- * The completion script (in contrib/) learned that the "--onto"
-   option of "git rebase" can take its argument as the value of the
-   option.
-
- * The userdiff machinery has been taught that "async def" is another
-   way to begin a "function" in Python.
-
- * "git range-diff" learned to take the "--notes=<ref>" and the
-   "--no-notes" options to control the commit notes included in the
-   log message that gets compared.
-
- * "git rev-parse --show-toplevel" run outside of any working tree did
-   not error out, which has been corrected.
-
- * A few commands learned to take the pathspec from the standard input
-   or a named file, instead of taking it as the command line
-   arguments, with the "--pathspec-from-file" option.
-
- * "git rebase -i" learned a few options that are known by "git
-   rebase" proper.
-
- * "git submodule" learned a subcommand "set-url".
-
- * "git log" family learned "--pretty=reference" that gives the name
-   of a commit in the format that is often used to refer to it in log
-   messages.
-
- * The interaction between "git clone --recurse-submodules" and
-   alternate object store was ill-designed.  The documentation and
-   code have been taught to make more clear recommendations when the
-   users see failures.
-
- * Management of sparsely checked-out working tree has gained a
-   dedicated "sparse-checkout" command.
-
- * Miscellaneous small UX improvements on "git-p4".
-
-
-Performance, Internal Implementation, Development Support etc.
-
- * Debugging support for lazy cloning has been a bit improved.
-
- * Move the definition of a set of bitmask constants from 0ctal
-   literal to (1U<<count) notation.
-
- * Test updates to prepare for SHA-2 transition continues.
-
- * Crufty code and logic accumulated over time around the object
-   parsing and low-level object access used in "git fsck" have been
-   cleaned up.
-
- * The implementation of "git log --graph" got refactored and then its
-   output got simplified.
-
- * Follow recent push to move API docs from Documentation/ to header
-   files and update config.h
-
- * "git bundle" has been taught to use the parse options API.  "git
-   bundle verify" learned "--quiet" and "git bundle create" learned
-   options to control the progress output.
-
- * Handling of commit objects that use non UTF-8 encoding during
-   "rebase -i" has been improved.
-
- * The beginning of rewriting "git add -i" in C.
-
- * A label used in the todo list that are generated by "git rebase
-   --rebase-merges" is used as a part of a refname; the logic to come
-   up with the label has been tightened to avoid names that cannot be
-   used as such.
-
- * The logic to avoid duplicate label names generated by "git rebase
-   --rebase-merges" forgot that the machinery itself uses "onto" as a
-   label name, which must be avoided by auto-generated labels, which
-   has been corrected.
-
- * We have had compatibility fallback macro definitions for "PRIuMAX",
-   "PRIu32", etc. but did not for "PRIdMAX", while the code used the
-   last one apparently without any hiccup reported recently.  The
-   fallback macro definitions for these <inttypes.h> macros that must
-   appear in C99 systems have been removed.
-
- * Recently we have declared that GIT_TEST_* variables take the
-   usual boolean values (it used to be that some used "non-empty
-   means true" and taking GIT_TEST_VAR=YesPlease as true); make
-   sure we notice and fail when non-bool strings are given to
-   these variables.
-
- * Users of oneway_merge() (like "reset --hard") learned to take
-   advantage of fsmonitor to avoid unnecessary lstat(2) calls.
-
- * Performance tweak on "git push" into a repository with many refs
-   that point at objects we have never heard of.
-
- * PerfTest fix to avoid stale result mixed up with the latest round
-   of test results.
-
- * Hide lower-level verify_signed-buffer() API as a pure helper to
-   implement the public check_signature() function, in order to
-   encourage new callers to use the correct and more strict
-   validation.
-
- * Unnecessary reading of state variables back from the disk during
-   sequencer operation has been reduced.
-
- * The code has been made to avoid gmtime() and localtime() and prefer
-   their reentrant counterparts.
-
- * The effort to reimplement "git add -i" in C continues.
-
- * In a repository with many packfiles, the cost of the procedure that
-   avoids registering the same packfile twice was unnecessarily high
-   by using an inefficient search algorithm, which has been corrected.
-
- * Redo "git name-rev" to avoid recursive calls.
-
- * FreeBSD CI support via Cirrus-CI has been added.
-
-
-Fixes since v2.24
------------------
-
- * "rebase -i" ceased to run post-commit hook by mistake in an earlier
-   update, which has been corrected.
-
- * "git notes copy $original" ought to copy the notes attached to the
-   original object to HEAD, but a mistaken tightening to command line
-   parameter validation made earlier disabled that feature by mistake.
-
- * When all files from some subdirectory were renamed to the root
-   directory, the directory rename heuristics would fail to detect that
-   as a rename/merge of the subdirectory to the root directory, which has
-   been corrected.
-
- * Code clean-up and a bugfix in the logic used to tell worktree local
-   and repository global refs apart.
-   (merge f45f88b2e4 sg/dir-trie-fixes later to maint).
-
- * "git stash save" in a working tree that is sparsely checked out
-   mistakenly removed paths that are outside the area of interest.
-   (merge 4a58c3d7f7 js/update-index-ignore-removal-for-skip-worktree later to maint).
-
- * "git rev-parse --git-path HEAD.lock" did not give the right path
-   when run in a secondary worktree.
-   (merge 76a53d640f js/git-path-head-dot-lock-fix later to maint).
-
- * "git merge --no-commit" needs "--no-ff" if you do not want to move
-   HEAD, which has been corrected in the manual page for "git bisect".
-   (merge 8dd327b246 ma/bisect-doc-sample-update later to maint).
-
- * "git worktree add" internally calls "reset --hard" that should not
-   descend into submodules, even when submodule.recurse configuration
-   is set, but it was affected.  This has been corrected.
-   (merge 4782cf2ab6 pb/no-recursive-reset-hard-in-worktree-add later to maint).
-
- * Messages from die() etc. can be mixed up from multiple processes
-   without even line buffering on Windows, which has been worked
-   around.
-   (merge 116d1fa6c6 js/vreportf-wo-buffering later to maint).
-
- * HTTP transport had possible allocator/deallocator mismatch, which
-   has been corrected.
-
- * The watchman integration for fsmonitor was racy, which has been
-   corrected to be more conservative.
-   (merge dd0b61f577 kw/fsmonitor-watchman-fix later to maint).
-
- * Fetching from multiple remotes into the same repository in parallel
-   had a bad interaction with the recent change to (optionally) update
-   the commit-graph after a fetch job finishes, as these parallel
-   fetches compete with each other.  Which has been corrected.
-
- * Recent update to "git stash pop" made the command empty the index
-   when run with the "--quiet" option, which has been corrected.
-
- * "git fetch" codepath had a big "do not lazily fetch missing objects
-   when I ask if something exists" switch.  This has been corrected by
-   marking the "does this thing exist?" calls with "if not please do not
-   lazily fetch it" flag.
-
- * Test update to avoid wasted cycles.
-   (merge e0316695ec sg/skip-skipped-prereq later to maint).
-
- * Error handling after "git push" finishes sending the packdata and
-   waits for the response to the remote side has been improved.
-   (merge ad7a403268 jk/send-pack-remote-failure later to maint).
-
- * Some codepaths in "gitweb" that forgot to escape URLs generated
-   based on end-user input have been corrected.
-   (merge a376e37b2c jk/gitweb-anti-xss later to maint).
-
- * CI jobs for macOS has been made less chatty when updating perforce
-   package used during testing.
-   (merge 0dbc4a0edf jc/azure-ci-osx-fix-fix later to maint).
-
- * "git unpack-objects" used to show progress based only on the number
-   of received and unpacked objects, which stalled when it has to
-   handle an unusually large object.  It now shows the throughput as
-   well.
-   (merge bae60ba7e9 sg/unpack-progress-throughput later to maint).
-
- * The sequencer machinery compared the HEAD and the state it is
-   attempting to commit to decide if the result would be a no-op
-   commit, even when amending a commit, which was incorrect, and
-   has been corrected.
-
- * The code to parse GPG output used to assume incorrectly that the
-   finterprint for the primary key would always be present for a valid
-   signature, which has been corrected.
-   (merge 67a6ea6300 hi/gpg-optional-pkfp-fix later to maint).
-
- * "git submodule status" and "git submodule status --cached" show
-   different things, but the documentation did not cover them
-   correctly, which has been corrected.
-   (merge 8d483c8408 mg/doc-submodule-status-cached later to maint).
-
- * "git reset --patch $object" without any pathspec should allow a
-   tree object to be given, but incorrectly required a committish,
-   which has been corrected.
-
- * "git submodule status" that is run from a subdirectory of the
-   superproject did not work well, which has been corrected.
-   (merge 1f3aea22c7 mg/submodule-status-from-a-subdirectory later to maint).
-
- * The revision walking machinery uses resources like per-object flag
-   bits that need to be reset before a new iteration of walking
-   begins, but the resources related to topological walk were not
-   cleared correctly, which has been corrected.
-   (merge 0aa0c2b2ec mh/clear-topo-walk-upon-reset later to maint).
-
- * TravisCI update.
-   (merge 176441bfb5 sg/osx-force-gcc-9 later to maint).
-
- * While running "revert" or "cherry-pick --edit" for multiple
-   commits, a recent regression incorrectly detected "nothing to
-   commit, working tree clean", instead of replaying the commits,
-   which has been corrected.
-   (merge befd4f6a81 sg/assume-no-todo-update-in-cherry-pick later to maint).
-
- * Work around a issue where a FD that is left open when spawning a
-   child process and is kept open in the child can interfere with the
-   operation in the parent process on Windows.
-
- * One kind of progress messages were always given during commit-graph
-   generation, instead of following the "if it takes more than two
-   seconds, show progress" pattern, which has been corrected.
-
- * "git rebase" did not work well when format.useAutoBase
-   configuration variable is set, which has been corrected.
-
- * The "diff" machinery learned not to lose added/removed blank lines
-   in the context when --ignore-blank-lines and --function-context are
-   used at the same time.
-   (merge 0bb313a552 rs/xdiff-ignore-ws-w-func-context later to maint).
-
- * The test on "fast-import" used to get stuck when "fast-import" died
-   in the middle.
-   (merge 0d9b0d7885 sg/t9300-robustify later to maint).
-
- * "git format-patch" can take a set of configured format.notes values
-   to specify which notes refs to use in the log message part of the
-   output.  The behaviour of this was not consistent with multiple
-   --notes command line options, which has been corrected.
-   (merge e0f9095aaa dl/format-patch-notes-config-fixup later to maint).
-
- * "git p4" used to ignore lfs.storage configuration variable, which
-   has been corrected.
-   (merge ea94b16fb8 rb/p4-lfs later to maint).
-
- * Assorted fixes to the directory traversal API.
-   (merge 6836d2fe06 en/fill-directory-fixes later to maint).
-
- * Forbid pathnames that the platform's filesystem cannot represent on
-   MinGW.
-   (merge 4dc42c6c18 js/mingw-reserved-filenames later to maint).
-
- * "git rebase --signoff" stopped working when the command was written
-   in C, which has been corrected.
-   (merge 4fe7e43c53 en/rebase-signoff-fix later to maint).
-
- * Other code cleanup, docfix, build fix, etc.
-   (merge 80736d7c5e jc/am-show-current-patch-docfix later to maint).
-   (merge 8b656572ca sg/commit-graph-usage-fix later to maint).
-   (merge 6c02042139 mr/clone-dir-exists-to-path-exists later to maint).
-   (merge 44ae131e38 sg/blame-indent-heuristics-is-now-the-default later to maint).
-   (merge 0115e5d929 dl/doc-diff-no-index-implies-exit-code later to maint).
-   (merge 270de6acbe en/t6024-style later to maint).
-   (merge 14c4776d75 ns/test-desc-typofix later to maint).
-   (merge 68d40f30c4 dj/typofix-merge-strat later to maint).
-   (merge f66e0401ab jk/optim-in-pack-idx-conversion later to maint).
-   (merge 169bed7421 rs/parse-options-dup-null-fix later to maint).
-   (merge 51bd6be32d rs/use-copy-array-in-mingw-shell-command-preparation later to maint).
-   (merge b018719927 ma/t7004 later to maint).
-   (merge 932757b0cc ar/install-doc-update-cmds-needing-the-shell later to maint).
-   (merge 46efd28be1 ep/guard-kset-tar-headers later to maint).
-   (merge 9e5afdf997 ec/fetch-mark-common-refs-trace2 later to maint).
-   (merge f0e58b3fe8 pb/submodule-update-fetches later to maint).
-   (merge 2a02262078 dl/t5520-cleanup later to maint).
-   (merge a4fb016ba1 js/pkt-line-h-typofix later to maint).
-   (merge 54a7a64613 rs/simplify-prepare-cmd later to maint).
-   (merge 3eae30e464 jk/lore-is-the-archive later to maint).
-   (merge 14b7664df8 dl/lore-is-the-archive later to maint).
-   (merge 0e40a73a4c po/bundle-doc-clonable later to maint).
-   (merge e714b898c6 as/t7812-missing-redirects-fix later to maint).
-   (merge 528d9e6d01 jk/perf-wo-git-dot-pm later to maint).
-   (merge fc42f20e24 sg/test-squelch-noise-in-commit-bulk later to maint).
-   (merge c64368e3a2 bc/t9001-zsh-in-posix-emulation-mode later to maint).
-   (merge 11de8dd7ef dr/branch-usage-casefix later to maint).
-   (merge e05e8cf074 rs/archive-zip-code-cleanup later to maint).
-   (merge 147ee35558 rs/commit-export-env-simplify later to maint).
-   (merge 4507ecc771 rs/patch-id-use-oid-to-hex later to maint).
-   (merge 51a0a4ed95 mr/bisect-use-after-free later to maint).
-   (merge cc2bd5c45d pb/submodule-doc-xref later to maint).
-   (merge df5be01669 ja/doc-markup-cleanup later to maint).
-   (merge 7c5cea7242 mr/bisect-save-pointer-to-const-string later to maint).
-   (merge 20a67e8ce9 js/use-test-tool-on-path later to maint).

Documentation/RelNotes/2.3.3.txt

@@ -12,7 +12,7 @@ Fixes since v2.3.2
  * Description given by "grep -h" for its --exclude-standard option
    was phrased poorly.
 
- * Documentation for "git remote add" mentioned "--tags" and
+ * Documentaton for "git remote add" mentioned "--tags" and
    "--no-tags" and it was not clear that fetch from the remote in
    the future will use the default behaviour when neither is given
    to override it.

Documentation/RelNotes/2.3.7.txt

@@ -4,7 +4,7 @@ Git v2.3.7 Release Notes
 Fixes since v2.3.6
 ------------------
 
- * An earlier update to the parser that dissects a URL broke an
+ * An earlier update to the parser that disects a URL broke an
    address, followed by a colon, followed by an empty string (instead
    of the port number), e.g. ssh://example.com:/path/to/repo.
 

Documentation/RelNotes/2.4.3.txt

@@ -66,7 +66,7 @@ Fixes since v2.4.3
  * Some time ago, "git blame" (incorrectly) lost the convert_to_git()
    call when synthesizing a fake "tip" commit that represents the
    state in the working tree, which broke folks who record the history
-   with LF line ending to make their project portable across
+   with LF line ending to make their project portabile across
    platforms while terminating lines in their working tree files with
    CRLF for their platform.
 

Documentation/RelNotes/2.5.0.txt

@@ -172,8 +172,7 @@ Performance, Internal Implementation, Development Support etc.
    incorrect patch text to "git apply".  Add tests to demonstrate
    this.
 
-   I have a slight suspicion that this may be
-   cf. <7vtzf77wjp.fsf@gitster.siamese.dyndns.org> coming back
+   I have a slight suspicion that this may be $gmane/87202 coming back
    and biting us (I seem to have said "let's run with this and see
    what happens" back then).
 

Documentation/RelNotes/2.7.0.txt

@@ -40,7 +40,7 @@ UI, Workflows & Features
 
  * "git interpret-trailers" can now run outside of a Git repository.
 
- * "git p4" learned to re-encode the pathname it uses to communicate
+ * "git p4" learned to reencode the pathname it uses to communicate
    with the p4 depot with a new option.
 
  * Give progress meter to "git filter-branch".

Documentation/RelNotes/2.7.3.txt

@@ -20,7 +20,7 @@ Fixes since v2.7.2
    tests.
 
  * "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a
-   rev, i.e. the object named by the pathname with wildcard
+   rev, i.e. the object named by the the pathname with wildcard
    characters in a tree object.
 
  * "git rev-parse --git-common-dir" used in the worktree feature

Documentation/RelNotes/2.8.0.txt

@@ -189,7 +189,7 @@ Performance, Internal Implementation, Development Support etc.
  * Some calls to strcpy(3) triggers a false warning from static
    analyzers that are less intelligent than humans, and reducing the
    number of these false hits helps us notice real issues.  A few
-   calls to strcpy(3) in a couple of programs that are already safe
+   calls to strcpy(3) in a couple of protrams that are already safe
    has been rewritten to avoid false warnings.
 
  * The "name_path" API was an attempt to reduce the need to construct

Documentation/RelNotes/2.8.3.txt

@@ -55,8 +55,8 @@ Fixes since v2.8.2
    This is necessary to use Git on Windows shared directories, and is
    already enabled for the MinGW and plain Windows builds.  It also
    has been used in Cygwin packaged versions of Git for quite a while.
-   See https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/
-   and https://lore.kernel.org/git/20150811100527.GW14466@dinwoodie.org/.
+   See http://thread.gmane.org/gmane.comp.version-control.git/291853
+   and http://thread.gmane.org/gmane.comp.version-control.git/275680.
 
  * "git replace -e" did not honour "core.editor" configuration.
 

Documentation/RelNotes/2.9.0.txt

@@ -368,7 +368,7 @@ notes for details).
    This is necessary to use Git on Windows shared directories, and is
    already enabled for the MinGW and plain Windows builds.  It also
    has been used in Cygwin packaged versions of Git for quite a while.
-   See https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/
+   See http://thread.gmane.org/gmane.comp.version-control.git/291853
 
  * "merge-octopus" strategy did not ensure that the index is clean
    when merge begins.

Documentation/RelNotes/2.9.3.txt

@@ -36,7 +36,7 @@ Fixes since v2.9.2
  * One part of "git am" had an oddball helper function that called
    stuff from outside "his" as opposed to calling what we have "ours",
    which was not gender-neutral and also inconsistent with the rest of
-   the system where outside stuff is usually called "theirs" in
+   the system where outside stuff is usuall called "theirs" in
    contrast to "ours".
 
  * The test framework learned a new helper test_match_signal to

Documentation/SubmittingPatches

@@ -142,25 +142,19 @@ archive, summarize the relevant points of the discussion.
 
 [[commit-reference]]
 If you want to reference a previous commit in the history of a stable
-branch, use the format "abbreviated hash (subject, date)", like this:
+branch, use the format "abbreviated sha1 (subject, date)",
+with the subject enclosed in a pair of double-quotes, like this:
 
 ....
-	Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30)
+	Commit f86a374 ("pack-bitmap.c: fix a memleak", 2015-03-30)
 	noticed that ...
 ....
 
 The "Copy commit summary" command of gitk can be used to obtain this
-format (with the subject enclosed in a pair of double-quotes), or this
-invocation of `git show`:
+format, or this invocation of `git show`:
 
 ....
-	git show -s --pretty=reference <commit>
-....
-
-or, on an older version of Git without support for --pretty=reference:
-
-....
-	git show -s --date=short --pretty='format:%h (%s, %ad)' <commit>
+	git show -s --date=short --pretty='format:%h ("%s", %ad)' <commit>
 ....
 
 [[git-tools]]

Documentation/config.txt

@@ -142,7 +142,7 @@ refer to linkgit:gitignore[5] for details. For convenience:
 
 `gitdir/i`::
 	This is the same as `gitdir` except that matching is done
-	case-insensitively (e.g. on case-insensitive file systems)
+	case-insensitively (e.g. on case-insensitive file sytems)
 
 `onbranch`::
 	The data that follows the keyword `onbranch:` is taken to be a

Documentation/config/add.txt

@@ -5,8 +5,3 @@ add.ignore-errors (deprecated)::
 	option of linkgit:git-add[1].  `add.ignore-errors` is deprecated,
 	as it does not follow the usual naming convention for configuration
 	variables.
-
-add.interactive.useBuiltin::
-	[EXPERIMENTAL] Set to `true` to use the experimental built-in
-	implementation of the interactive version of linkgit:git-add[1]
-	instead of the Perl script version. Is `false` by default.

Documentation/config/advice.txt

@@ -107,7 +107,4 @@ advice.*::
 		editor input from the user.
 	nestedTag::
 		Advice shown if a user attempts to recursively tag a tag object.
-	submoduleAlternateErrorStrategyDie:
-		Advice shown when a submodule.alternateErrorStrategy option
-		configured to "die" causes a fatal error.
 --

Documentation/config/core.txt

@@ -559,12 +559,6 @@ core.unsetenvvars::
 	Defaults to `PERL5LIB` to account for the fact that Git for
 	Windows insists on using its own Perl interpreter.
 
-core.restrictinheritedhandles::
-	Windows-only: override whether spawned processes inherit only standard
-	file handles (`stdin`, `stdout` and `stderr`) or all handles. Can be
-	`auto`, `true` or `false`. Defaults to `auto`, which means `true` on
-	Windows 7 and later, and `false` on older Windows versions.
-
 core.createObject::
 	You can set this to 'link', in which case a hardlink followed by
 	a delete of the source are used to make sure that object creation
@@ -599,14 +593,8 @@ core.multiPackIndex::
 	multi-pack-index design document].
 
 core.sparseCheckout::
-	Enable "sparse checkout" feature. See linkgit:git-sparse-checkout[1]
-	for more information.
-
-core.sparseCheckoutCone::
-	Enables the "cone mode" of the sparse checkout feature. When the
-	sparse-checkout file contains a limited set of patterns, then this
-	mode provides significant performance advantages. See
-	linkgit:git-sparse-checkout[1] for more information.
+	Enable "sparse checkout" feature. See section "Sparse checkout" in
+	linkgit:git-read-tree[1] for more information.
 
 core.abbrev::
 	Set the length object names are abbreviated to.  If

Documentation/config/format.txt

@@ -36,12 +36,6 @@ format.subjectPrefix::
 	The default for format-patch is to output files with the '[PATCH]'
 	subject prefix. Use this variable to change that prefix.
 
-format.coverFromDescription::
-	The default mode for format-patch to determine which parts of
-	the cover letter will be populated using the branch's
-	description. See the `--cover-from-description` option in
-	linkgit:git-format-patch[1].
-
 format.signature::
 	The default for format-patch is to output a signature containing
 	the Git version number. Use this variable to change that default.
@@ -106,20 +100,4 @@ If one wishes to use the ref `ref/notes/true`, please use that literal
 instead.
 +
 This configuration can be specified multiple times in order to allow
-multiple notes refs to be included. In that case, it will behave
-similarly to multiple `--[no-]notes[=]` options passed in. That is, a
-value of `true` will show the default notes, a value of `<ref>` will
-also show notes from that notes ref and a value of `false` will negate
-previous configurations and not show notes.
-+
-For example,
-+
-------------
-[format]
-	notes = true
-	notes = foo
-	notes = false
-	notes = bar
-------------
-+
-will only show notes from `refs/notes/bar`.
+multiple notes refs to be included.

Documentation/config/submodule.txt

@@ -79,6 +79,4 @@ submodule.alternateLocation::
 submodule.alternateErrorStrategy::
 	Specifies how to treat errors with the alternates for a submodule
 	as computed via `submodule.alternateLocation`. Possible values are
-	`ignore`, `info`, `die`. Default is `die`. Note that if set to `ignore`
-	or `info`, and if there is an error with the computed alternate, the
-	clone proceeds as if no alternate was specified.
+	`ignore`, `info`, `die`. Default is `die`.

Documentation/config/tag.txt

@@ -13,7 +13,7 @@ tag.gpgSign::
 	Use of this option when running in an automated script can
 	result in a large number of tags being signed. It is therefore
 	convenient to use an agent to avoid typing your gpg passphrase
-	several times. Note that this option doesn't affect tag signing
+	several times. Note that this option doesn't affects tag signing
 	behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options.
 
 tar.umask::

Documentation/diff-format.txt

@@ -61,7 +61,7 @@ Possible status letters are:
 - R: renaming of a file
 - T: change in the type of the file
 - U: file is unmerged (you must complete the merge before it can
-  be committed)
+be committed)
 - X: "unknown" change type (most probably a bug, please report it)
 
 Status letters C and R are always followed by a score (denoting the

Documentation/fetch-options.txt

@@ -92,10 +92,6 @@ ifndef::git-pull[]
 	Run `git gc --auto` at the end to perform garbage collection
 	if needed. This is enabled by default.
 
---[no-]write-commit-graph::
-	Write a commit-graph after fetching. This overrides the config
-	setting `fetch.writeCommitGraph`.
-
 -p::
 --prune::
 	Before fetching, remove any remote-tracking references that no

Documentation/git-add.txt

@@ -11,8 +11,7 @@ SYNOPSIS
 'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p]
 	  [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]]
 	  [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
-	  [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]]
-	  [--] [<pathspec>...]
+	  [--chmod=(+|-)x] [--] [<pathspec>...]
 
 DESCRIPTION
 -----------
@@ -188,19 +187,6 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files.
 	bit is only changed in the index, the files on disk are left
 	unchanged.
 
---pathspec-from-file=<file>::
-	Pathspec is passed in `<file>` instead of commandline args. If
-	`<file>` is exactly `-` then standard input is used. Pathspec
-	elements are separated by LF or CR/LF. Pathspec elements can be
-	quoted as explained for the configuration variable `core.quotePath`
-	(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
-	global `--literal-pathspecs`.
-
---pathspec-file-nul::
-	Only meaningful with `--pathspec-from-file`. Pathspec elements are
-	separated with NUL character and all other characters are taken
-	literally (including newlines and quotes).
-
 \--::
 	This option can be used to separate command-line options from
 	the list of files, (useful when filenames might be mistaken

Documentation/git-am.txt

@@ -177,7 +177,7 @@ default.   You can use `--no-utf8` to override this.
 	untouched.
 
 --show-current-patch::
-	Show the entire e-mail message "git am" has stopped at, because
+	Show the patch being applied when "git am" is stopped because
 	of conflicts.
 
 DISCUSSION

Documentation/git-bisect-lk2009.txt

@@ -158,7 +158,7 @@ Test suites are very nice. But when they are used alone, they are
 supposed to be used so that all the tests are checked after each
 commit. This means that they are not very efficient, because many
 tests are run for no interesting result, and they suffer from
-combinatorial explosion.
+combinational explosion.
 
 In fact the problem is that big software often has many different
 configuration options and that each test case should pass for each
@@ -1350,9 +1350,9 @@ References
 - [[[1]]] https://www.nist.gov/sites/default/files/documents/director/planning/report02-3.pdf['The Economic Impacts of Inadequate Infratructure for Software Testing'.  Nist Planning Report 02-3], see Executive Summary and Chapter 8.
 - [[[2]]] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html['Code Conventions for the Java Programming Language'. Sun Microsystems.]
 - [[[3]]] https://en.wikipedia.org/wiki/Software_maintenance['Software maintenance'. Wikipedia.]
-- [[[4]]] https://lore.kernel.org/git/7vps5xsbwp.fsf_-_@assigned-by-dhcp.cox.net/[Junio C Hamano. 'Automated bisect success story'.]
+- [[[4]]] https://public-inbox.org/git/7vps5xsbwp.fsf_-_@assigned-by-dhcp.cox.net/[Junio C Hamano. 'Automated bisect success story'.]
 - [[[5]]] https://lwn.net/Articles/317154/[Christian Couder. 'Fully automated bisecting with "git bisect run"'. LWN.net.]
 - [[[6]]] https://lwn.net/Articles/277872/[Jonathan Corbet. 'Bisection divides users and developers'. LWN.net.]
-- [[[7]]] https://lore.kernel.org/lkml/20071207113734.GA14598@elte.hu/[Ingo Molnar. 'Re: BUG 2.6.23-rc3 can't see sd partitions on Alpha'. Linux-kernel mailing list.]
+- [[[7]]] http://marc.info/?l=linux-kernel&m=119702753411680&w=2[Ingo Molnar. 'Re: BUG 2.6.23-rc3 can't see sd partitions on Alpha'. Linux-kernel mailing list.]
 - [[[8]]] https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html[Junio C Hamano and the git-list. 'git-bisect(1) Manual Page'. Linux Kernel Archives.]
 - [[[9]]] https://github.com/Ealdwulf/bbchop[Ealdwulf. 'bbchop'. GitHub.]

Documentation/git-bisect.txt

@@ -413,7 +413,7 @@ $ cat ~/test.sh
 
 # tweak the working tree by merging the hot-fix branch
 # and then attempt a build
-if	git merge --no-commit --no-ff hot-fix &&
+if	git merge --no-commit hot-fix &&
 	make
 then
 	# run project specific test and report its status

Documentation/git-bundle.txt

@@ -9,8 +9,8 @@ git-bundle - Move objects and refs by archive
 SYNOPSIS
 --------
 [verse]
-'git bundle' create [-q | --quiet | --progress | --all-progress] [--all-progress-implied] <file> <git-rev-list-args>
-'git bundle' verify [-q | --quiet] <file>
+'git bundle' create <file> <git-rev-list-args>
+'git bundle' verify <file>
 'git bundle' list-heads <file> [<refname>...]
 'git bundle' unbundle <file> [<refname>...]
 
@@ -20,14 +20,11 @@ DESCRIPTION
 Some workflows require that one or more branches of development on one
 machine be replicated on another machine, but the two machines cannot
 be directly connected, and therefore the interactive Git protocols (git,
-ssh, http) cannot be used.
-
-The 'git bundle' command packages objects and references in an archive
-at the originating machine, which can then be imported into another
-repository using 'git fetch', 'git pull', or 'git clone',
-after moving the archive by some means (e.g., by sneakernet).
-
-As no
+ssh, http) cannot be used.  This command provides support for
+'git fetch' and 'git pull' to operate by packaging objects and references
+in an archive at the originating machine, then importing those into
+another repository using 'git fetch' and 'git pull'
+after moving the archive by some means (e.g., by sneakernet).  As no
 direct connection between the repositories exists, the user must specify a
 basis for the bundle that is held by the destination repository: the
 bundle assumes that all objects in the basis are already in the
@@ -36,11 +33,9 @@ destination repository.
 OPTIONS
 -------
 
-create [options] <file> <git-rev-list-args>::
+create <file>::
 	Used to create a bundle named 'file'.  This requires the
-	'<git-rev-list-args>' arguments to define the bundle contents.
-	'options' contains the options specific to the 'git bundle create'
-	subcommand.
+	'git-rev-list-args' arguments to define the bundle contents.
 
 verify <file>::
 	Used to check that a bundle file is valid and will apply
@@ -80,33 +75,6 @@ unbundle <file>::
 	necessarily everything in the pack (in this case, 'git bundle' acts
 	like 'git fetch-pack').
 
---progress::
-	Progress status is reported on the standard error stream
-	by default when it is attached to a terminal, unless -q
-	is specified. This flag forces progress status even if
-	the standard error stream is not directed to a terminal.
-
---all-progress::
-	When --stdout is specified then progress report is
-	displayed during the object count and compression phases
-	but inhibited during the write-out phase. The reason is
-	that in some cases the output stream is directly linked
-	to another command which may wish to display progress
-	status of its own as it processes incoming pack data.
-	This flag is like --progress except that it forces progress
-	report for the write-out phase as well even if --stdout is
-	used.
-
---all-progress-implied::
-	This is used to imply --all-progress whenever progress display
-	is activated.  Unlike --all-progress this flag doesn't actually
-	force any progress display by itself.
-
--q::
---quiet::
-	This flag makes the command not to report its progress
-	on the standard error stream.
-
 SPECIFYING REFERENCES
 ---------------------
 
@@ -124,14 +92,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.
 
-`git clone` can use any bundle created without negative refspecs
-(e.g., `new`, but not `old..new`).
-If you want to match `git clone --mirror`, which would include your
-refs such as `refs/remotes/*`, use `--all`.
-If you want to provide the same set of refs that a clone directly
-from the source repository would get, use `--branches --tags` for
-the `<git-rev-list-args>`.
-
 EXAMPLES
 --------
 

Documentation/git-check-attr.txt

@@ -32,7 +32,7 @@ OPTIONS
 	instead of from the command-line.
 
 -z::
-	The output format is modified to be machine-parsable.
+	The output format is modified to be machine-parseable.
 	If `--stdin` is also given, input paths are separated
 	with a NUL character instead of a linefeed character.
 

Documentation/git-check-ignore.txt

@@ -39,7 +39,7 @@ OPTIONS
 	instead of from the command-line.
 
 -z::
-	The output format is modified to be machine-parsable (see
+	The output format is modified to be machine-parseable (see
 	below).  If `--stdin` is also given, input paths are separated
 	with a NUL character instead of a linefeed character.
 

Documentation/git-checkout.txt

@@ -12,14 +12,14 @@ 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' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
+'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
+'git checkout' [<tree-ish>] [--] <pathspec>...
+'git checkout' (-p|--patch) [<tree-ish>] [--] [<paths>...]
 
 DESCRIPTION
 -----------
 Updates files in the working tree to match the version in the index
-or the specified tree.  If no pathspec was given, 'git checkout' will
+or the specified tree.  If no paths are given, 'git checkout' will
 also update `HEAD` to set the specified branch as the current
 branch.
 
@@ -79,14 +79,13 @@ be used to detach `HEAD` at the tip of the branch (`git checkout
 +
 Omitting `<branch>` detaches `HEAD` at the tip of the current branch.
 
-'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' [<tree-ish>] [--] <pathspec>...::
 
-	Overwrite the contents of the files that match the pathspec.
-	When the `<tree-ish>` (most often a commit) is not given,
-	overwrite working tree with the contents in the index.
-	When the `<tree-ish>` is given, overwrite both the index and
-	the working tree with the contents at the `<tree-ish>`.
+	Overwrite paths in the working tree by replacing with the
+	contents in the index or in the `<tree-ish>` (most often a
+	commit).  When a `<tree-ish>` is given, the paths that
+	match the `<pathspec>` are updated both in the index and in
+	the working tree.
 +
 The index may contain unmerged entries because of a previous failed merge.
 By default, if you try to check out such an entry from the index, the
@@ -97,10 +96,12 @@ using `--ours` or `--theirs`.  With `-m`, changes made to the working tree
 file can be discarded to re-create the original conflicted merge result.
 
 'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]::
-	This is similar to the previous mode, but lets you use the
-	interactive interface to show the "diff" output and choose which
-	hunks to use in the result.  See below for the description of
-	`--patch` option.
+	This is similar to the "check out paths to the working tree
+	from either the index or from a tree-ish" mode described
+	above, but lets you use the interactive interface to show
+	the "diff" output and choose which hunks to use in the
+	result.  See below for the description of `--patch` option.
+
 
 OPTIONS
 -------
@@ -308,19 +309,6 @@ Note that this option uses the no overlay mode by default (see also
 	working tree, but not in `<tree-ish>` are removed, to make them
 	match `<tree-ish>` exactly.
 
---pathspec-from-file=<file>::
-	Pathspec is passed in `<file>` instead of commandline args. If
-	`<file>` is exactly `-` then standard input is used. Pathspec
-	elements are separated by LF or CR/LF. Pathspec elements can be
-	quoted as explained for the configuration variable `core.quotePath`
-	(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
-	global `--literal-pathspecs`.
-
---pathspec-file-nul::
-	Only meaningful with `--pathspec-from-file`. Pathspec elements are
-	separated with NUL character and all other characters are taken
-	literally (including newlines and quotes).
-
 <branch>::
 	Branch to checkout; if it refers to a branch (i.e., a name that,
 	when prepended with "refs/heads/", is a valid ref), then that
@@ -351,13 +339,7 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
 	Tree to checkout from (when paths are given). If not specified,
 	the index will be used.
 
-\--::
-	Do not interpret any more arguments as options.
 
-<pathspec>...::
-	Limits the paths affected by the operation.
-+
-For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
 
 DETACHED HEAD
 -------------

Documentation/git-clone.txt

@@ -15,7 +15,7 @@ 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>] [--] <repository>
 	  [<directory>]
 
 DESCRIPTION
@@ -156,12 +156,6 @@ objects from the source repository into a pack in the cloned repository.
 	used, neither remote-tracking branches nor the related
 	configuration variables are created.
 
---sparse::
-	Initialize the sparse-checkout file so the working
-	directory starts with only the files in the root
-	of the repository. The sparse-checkout file can be
-	modified to grow the working directory as needed.
-
 --mirror::
 	Set up a mirror of the source repository.  This implies `--bare`.
 	Compared to `--bare`, `--mirror` not only maps local branches of the
@@ -268,9 +262,9 @@ or `--mirror` is given)
 	All submodules which are cloned will be shallow with a depth of 1.
 
 --[no-]remote-submodules::
-	All submodules which are cloned will use the status of the submodule's
+	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
+	superproject’s recorded SHA-1. Equivalent to passing `--remote` to
 	`git submodule update`.
 
 --separate-git-dir=<git dir>::

Documentation/git-commit-graph.txt

@@ -9,6 +9,7 @@ git-commit-graph - Write and verify Git commit-graph files
 SYNOPSIS
 --------
 [verse]
+'git commit-graph read' [--object-dir <dir>]
 'git commit-graph verify' [--object-dir <dir>] [--shallow] [--[no-]progress]
 'git commit-graph write' <options> [--object-dir <dir>] [--[no-]progress]
 
@@ -73,6 +74,11 @@ Finally, if `--expire-time=<datetime>` is not specified, let `datetime`
 be the current time. After writing the split commit-graph, delete all
 unused commit-graph whose modified times are older than `datetime`.
 
+'read'::
+
+Read the commit-graph file and output basic details about it.
+Used for debugging purposes.
+
 'verify'::
 
 Read the commit-graph file and verify its contents against the object
@@ -112,6 +118,12 @@ $ git show-ref -s | git commit-graph write --stdin-commits
 $ git rev-parse HEAD | git commit-graph write --stdin-commits --append
 ------------------------------------------------
 
+* Read basic information from the commit-graph file.
++
+------------------------------------------------
+$ git commit-graph read
+------------------------------------------------
+
 
 GIT
 ---

Documentation/git-commit.txt

@@ -13,8 +13,7 @@ SYNOPSIS
 	   [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
 	   [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
 	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
-	   [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
-	   [-S[<keyid>]] [--] [<pathspec>...]
+	   [-i | -o] [-S[<keyid>]] [--] [<file>...]
 
 DESCRIPTION
 -----------
@@ -279,19 +278,6 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
 	already been staged. If used together with `--allow-empty`
 	paths are also not required, and an empty commit will be created.
 
---pathspec-from-file=<file>::
-	Pathspec is passed in `<file>` instead of commandline args. If
-	`<file>` is exactly `-` then standard input is used. Pathspec
-	elements are separated by LF or CR/LF. Pathspec elements can be
-	quoted as explained for the configuration variable `core.quotePath`
-	(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
-	global `--literal-pathspecs`.
-
---pathspec-file-nul::
-	Only meaningful with `--pathspec-from-file`. Pathspec elements are
-	separated with NUL character and all other characters are taken
-	literally (including newlines and quotes).
-
 -u[<mode>]::
 --untracked-files[=<mode>]::
 	Show untracked files.
@@ -359,13 +345,12 @@ changes to tracked files.
 \--::
 	Do not interpret any more arguments as options.
 
-<pathspec>...::
-	When pathspec is given on the command line, commit the contents of
-	the files that match the pathspec without recording the changes
-	already added to the index. The contents of these files are also
-	staged for the next commit on top of what have been staged before.
-+
-For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
+<file>...::
+	When files are given on the command line, the command
+	commits the contents of the named files, without
+	recording the changes already staged.  The contents of
+	these files are also staged for the next commit on top
+	of what have been staged before.
 
 :git-commit: 1
 include::date-formats.txt[]

Documentation/git-credential.txt

@@ -19,7 +19,8 @@ from system-specific helpers, as well as prompting the user for
 usernames and passwords. The git-credential command exposes this
 interface to scripts which may want to retrieve, store, or prompt for
 credentials in the same manner as Git. The design of this scriptable
-interface models the internal C API; see credential.h for more
+interface models the internal C API; see
+link:technical/api-credentials.html[the Git credential API] for more
 background on the concepts.
 
 git-credential takes an "action" option on the command-line (one of

Documentation/git-cvsserver.txt

@@ -294,7 +294,7 @@ In `dbDriver` and `dbUser` you can use the following variables:
 	Git directory name
 %g::
 	Git directory name, where all characters except for
-	alphanumeric ones, `.`, and `-` are replaced with
+	alpha-numeric ones, `.`, and `-` are replaced with
 	`_` (this should make it easier to use the directory
 	name in a filename if wanted)
 %m::

Documentation/git-diff.txt

@@ -36,7 +36,7 @@ two blob objects, or changes between two files on disk.
 	running the command in a working tree controlled by Git and
 	at least one of the paths points outside the working tree,
 	or when running the command outside a working tree
-	controlled by Git. This form implies `--exit-code`.
+	controlled by Git.
 
 'git diff' [<options>] --cached [<commit>] [--] [<path>...]::
 

Documentation/git-fast-export.txt

@@ -142,7 +142,7 @@ by keeping the marks the same across runs.
 	Specify how to handle `encoding` header in commit objects.  When
 	asking to 'abort' (which is the default), this program will die
 	when encountering such a commit object.  With 'yes', the commit
-	message will be re-encoded into UTF-8.  With 'no', the original
+	message will be reencoded into UTF-8.  With 'no', the original
 	encoding will be preserved.
 
 --refspec::

Documentation/git-filter-branch.txt

@@ -466,13 +466,13 @@ The performance of git-filter-branch is glacially slow; its design makes it
 impossible for a backward-compatible implementation to ever be fast:
 
 * In editing files, git-filter-branch by design checks out each and
-  every commit as it existed in the original repo.  If your repo has
-  10\^5 files and 10\^5 commits, but each commit only modifies 5
-  files, then git-filter-branch will make you do 10\^10 modifications,
-  despite only having (at most) 5*10^5 unique blobs.
+every commit as it existed in the original repo.  If your repo has 10\^5
+files and 10\^5 commits, but each commit only modifies 5 files, then
+git-filter-branch will make you do 10\^10 modifications, despite only
+having (at most) 5*10^5 unique blobs.
 
 * If you try and cheat and try to make git-filter-branch only work on
-  files modified in a commit, then two things happen
+files modified in a commit, then two things happen
 
   ** you run into problems with deletions whenever the user is simply
      trying to rename files (because attempting to delete files that
@@ -481,41 +481,39 @@ impossible for a backward-compatible implementation to ever be fast:
      user-provided shell)
 
   ** even if you succeed at the map-deletes-for-renames chicanery, you
-     still technically violate backward compatibility because users
-     are allowed to filter files in ways that depend upon topology of
-     commits instead of filtering solely based on file contents or
-     names (though this has not been observed in the wild).
+     still technically violate backward compatibility because users are
+     allowed to filter files in ways that depend upon topology of
+     commits instead of filtering solely based on file contents or names
+     (though this has not been observed in the wild).
 
 * Even if you don't need to edit files but only want to e.g. rename or
-  remove some and thus can avoid checking out each file (i.e. you can
-  use --index-filter), you still are passing shell snippets for your
-  filters.  This means that for every commit, you have to have a
-  prepared git repo where those filters can be run.  That's a
-  significant setup.
+remove some and thus can avoid checking out each file (i.e. you can use
+--index-filter), you still are passing shell snippets for your filters.
+This means that for every commit, you have to have a prepared git repo
+where those filters can be run.  That's a significant setup.
 
-* Further, several additional files are created or updated per commit
-  by git-filter-branch.  Some of these are for supporting the
-  convenience functions provided by git-filter-branch (such as map()),
-  while others are for keeping track of internal state (but could have
-  also been accessed by user filters; one of git-filter-branch's
-  regression tests does so).  This essentially amounts to using the
-  filesystem as an IPC mechanism between git-filter-branch and the
-  user-provided filters.  Disks tend to be a slow IPC mechanism, and
-  writing these files also effectively represents a forced
-  synchronization point between separate processes that we hit with
-  every commit.
+* Further, several additional files are created or updated per commit by
+git-filter-branch.  Some of these are for supporting the convenience
+functions provided by git-filter-branch (such as map()), while others
+are for keeping track of internal state (but could have also been
+accessed by user filters; one of git-filter-branch's regression tests
+does so).  This essentially amounts to using the filesystem as an IPC
+mechanism between git-filter-branch and the user-provided filters.
+Disks tend to be a slow IPC mechanism, and writing these files also
+effectively represents a forced synchronization point between separate
+processes that we hit with every commit.
 
 * The user-provided shell commands will likely involve a pipeline of
-  commands, resulting in the creation of many processes per commit.
-  Creating and running another process takes a widely varying amount
-  of time between operating systems, but on any platform it is very
-  slow relative to invoking a function.
+commands, resulting in the creation of many processes per commit.
+Creating and running another process takes a widely varying amount of
+time between operating systems, but on any platform it is very slow
+relative to invoking a function.
 
 * git-filter-branch itself is written in shell, which is kind of slow.
-  This is the one performance issue that could be backward-compatibly
-  fixed, but compared to the above problems that are intrinsic to the
-  design of git-filter-branch, the language of the tool itself is a
-  relatively minor issue.
+This is the one performance issue that could be backward-compatibly
+fixed, but compared to the above problems that are intrinsic to the
+design of git-filter-branch, the language of the tool itself is a
+relatively minor issue.
 
   ** Side note: Unfortunately, people tend to fixate on the
      written-in-shell aspect and periodically ask if git-filter-branch
@@ -536,7 +534,7 @@ repo-filter' also provides
 https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/filter-lamely[filter-lamely],
 a drop-in git-filter-branch replacement (with a few caveats).  While
 filter-lamely suffers from all the same safety issues as
-git-filter-branch, it at least ameliorates the performance issues a
+git-filter-branch, it at least ameloriates the performance issues a
 little.
 
 [[SAFETY]]
@@ -548,55 +546,51 @@ easily corrupt repos or end up with a mess worse than what you started
 with:
 
 * Someone can have a set of "working and tested filters" which they
-  document or provide to a coworker, who then runs them on a different
-  OS where the same commands are not working/tested (some examples in
-  the git-filter-branch manpage are also affected by this).
-  BSD vs. GNU userland differences can really bite.  If lucky, error
-  messages are spewed.  But just as likely, the commands either don't
-  do the filtering requested, or silently corrupt by making some
-  unwanted change.  The unwanted change may only affect a few commits,
-  so it's not necessarily obvious either.  (The fact that problems
-  won't necessarily be obvious means they are likely to go unnoticed
-  until the rewritten history is in use for quite a while, at which
-  point it's really hard to justify another flag-day for another
-  rewrite.)
+document or provide to a coworker, who then runs them on a different OS
+where the same commands are not working/tested (some examples in the
+git-filter-branch manpage are also affected by this).  BSD vs. GNU
+userland differences can really bite.  If lucky, error messages are
+spewed.  But just as likely, the commands either don't do the filtering
+requested, or silently corrupt by making some unwanted change.  The
+unwanted change may only affect a few commits, so it's not necessarily
+obvious either.  (The fact that problems won't necessarily be obvious
+means they are likely to go unnoticed until the rewritten history is in
+use for quite a while, at which point it's really hard to justify
+another flag-day for another rewrite.)
 
 * Filenames with spaces are often mishandled by shell snippets since
-  they cause problems for shell pipelines.  Not everyone is familiar
-  with find -print0, xargs -0, git-ls-files -z, etc.  Even people who
-  are familiar with these may assume such flags are not relevant
-  because someone else renamed any such files in their repo back
-  before the person doing the filtering joined the project.  And
-  often, even those familiar with handling arguments with spaces may
-  not do so just because they aren't in the mindset of thinking about
-  everything that could possibly go wrong.
+they cause problems for shell pipelines.  Not everyone is familiar with
+find -print0, xargs -0, git-ls-files -z, etc.  Even people who are
+familiar with these may assume such flags are not relevant because
+someone else renamed any such files in their repo back before the person
+doing the filtering joined the project.  And often, even those familiar
+with handling arguments with spaces may not do so just because they
+aren't in the mindset of thinking about everything that could possibly
+go wrong.
 
-* Non-ascii filenames can be silently removed despite being in a
-  desired directory.  Keeping only wanted paths is often done using
-  pipelines like `git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`.
-  ls-files will only quote filenames if needed, so folks may not
-  notice that one of the files didn't match the regex (at least not
-  until it's much too late).  Yes, someone who knows about
-  core.quotePath can avoid this (unless they have other special
-  characters like \t, \n, or "), and people who use ls-files -z with
-  something other than grep can avoid this, but that doesn't mean they
-  will.
+* Non-ascii filenames can be silently removed despite being in a desired
+directory.  Keeping only wanted paths is often done using pipelines like
+`git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`.  ls-files will
+only quote filenames if needed, so folks may not notice that one of the
+files didn't match the regex (at least not until it's much too late).
+Yes, someone who knows about core.quotePath can avoid this (unless they
+have other special characters like \t, \n, or "), and people who use
+ls-files -z with something other than grep can avoid this, but that
+doesn't mean they will.
 
-* Similarly, when moving files around, one can find that filenames
-  with non-ascii or special characters end up in a different
-  directory, one that includes a double quote character.  (This is
-  technically the same issue as above with quoting, but perhaps an
-  interesting different way that it can and has manifested as a
-  problem.)
+* Similarly, when moving files around, one can find that filenames with
+non-ascii or special characters end up in a different directory, one
+that includes a double quote character.  (This is technically the same
+issue as above with quoting, but perhaps an interesting different way
+that it can and has manifested as a problem.)
 
 * It's far too easy to accidentally mix up old and new history.  It's
-  still possible with any tool, but git-filter-branch almost
-  invites it.  If lucky, the only downside is users getting frustrated
-  that they don't know how to shrink their repo and remove the old
-  stuff.  If unlucky, they merge old and new history and end up with
-  multiple "copies" of each commit, some of which have unwanted or
-  sensitive files and others which don't.  This comes about in
-  multiple different ways:
+still possible with any tool, but git-filter-branch almost invites it.
+If lucky, the only downside is users getting frustrated that they don't
+know how to shrink their repo and remove the old stuff.  If unlucky,
+they merge old and new history and end up with multiple "copies" of each
+commit, some of which have unwanted or sensitive files and others which
+don't.  This comes about in multiple different ways:
 
   ** the default to only doing a partial history rewrite ('--all' is not
      the default and few examples show it)
@@ -615,8 +609,8 @@ with:
      "DISCUSSION" section of the git filter-repo manual page for more
      details.
 
-* Annotated tags can be accidentally converted to lightweight tags,
-  due to either of two issues:
+* Annotated tags can be accidentally converted to lightweight tags, due
+to either of two issues:
 
   ** Someone can do a history rewrite, realize they messed up, restore
      from the backups in refs/original/, and then redo their
@@ -629,74 +623,71 @@ with:
      restored from refs/original/ in a previously botched rewrite).
 
 * Any commit messages that specify an encoding will become corrupted
-  by the rewrite; git-filter-branch ignores the encoding, takes the
-  original bytes, and feeds it to commit-tree without telling it the
-  proper encoding.  (This happens whether or not --msg-filter is
-  used.)
+by the rewrite; git-filter-branch ignores the encoding, takes the original
+bytes, and feeds it to commit-tree without telling it the proper
+encoding.  (This happens whether or not --msg-filter is used.)
 
 * Commit messages (even if they are all UTF-8) by default become
-  corrupted due to not being updated -- any references to other commit
-  hashes in commit messages will now refer to no-longer-extant
-  commits.
+corrupted due to not being updated -- any references to other commit
+hashes in commit messages will now refer to no-longer-extant commits.
 
-* There are no facilities for helping users find what unwanted crud
-  they should delete, which means they are much more likely to have
-  incomplete or partial cleanups that sometimes result in confusion
-  and people wasting time trying to understand.  (For example, folks
-  tend to just look for big files to delete instead of big directories
-  or extensions, and once they do so, then sometime later folks using
-  the new repository who are going through history will notice a build
-  artifact directory that has some files but not others, or a cache of
-  dependencies (node_modules or similar) which couldn't have ever been
-  functional since it's missing some files.)
+* There are no facilities for helping users find what unwanted crud they
+should delete, which means they are much more likely to have incomplete
+or partial cleanups that sometimes result in confusion and people
+wasting time trying to understand.  (For example, folks tend to just
+look for big files to delete instead of big directories or extensions,
+and once they do so, then sometime later folks using the new repository
+who are going through history will notice a build artifact directory
+that has some files but not others, or a cache of dependencies
+(node_modules or similar) which couldn't have ever been functional since
+it's missing some files.)
 
 * If --prune-empty isn't specified, then the filtering process can
-  create hoards of confusing empty commits
+create hoards of confusing empty commits
 
 * If --prune-empty is specified, then intentionally placed empty
-  commits from before the filtering operation are also pruned instead
-  of just pruning commits that became empty due to filtering rules.
+commits from before the filtering operation are also pruned instead of
+just pruning commits that became empty due to filtering rules.
 
-* If --prune-empty is specified, sometimes empty commits are missed
-  and left around anyway (a somewhat rare bug, but it happens...)
+* If --prune empty is specified, sometimes empty commits are missed
+and left around anyway (a somewhat rare bug, but it happens...)
 
 * A minor issue, but users who have a goal to update all names and
-  emails in a repository may be led to --env-filter which will only
-  update authors and committers, missing taggers.
+emails in a repository may be led to --env-filter which will only update
+authors and committers, missing taggers.
 
 * If the user provides a --tag-name-filter that maps multiple tags to
-  the same name, no warning or error is provided; git-filter-branch
-  simply overwrites each tag in some undocumented pre-defined order
-  resulting in only one tag at the end.  (A git-filter-branch
-  regression test requires this surprising behavior.)
+the same name, no warning or error is provided; git-filter-branch simply
+overwrites each tag in some undocumented pre-defined order resulting in
+only one tag at the end.  (A git-filter-branch regression test requires
+this surprising behavior.)
 
 Also, the poor performance of git-filter-branch often leads to safety
 issues:
 
-* Coming up with the correct shell snippet to do the filtering you
-  want is sometimes difficult unless you're just doing a trivial
-  modification such as deleting a couple files.  Unfortunately, people
-  often learn if the snippet is right or wrong by trying it out, but
-  the rightness or wrongness can vary depending on special
-  circumstances (spaces in filenames, non-ascii filenames, funny
-  author names or emails, invalid timezones, presence of grafts or
-  replace objects, etc.), meaning they may have to wait a long time,
-  hit an error, then restart.  The performance of git-filter-branch is
-  so bad that this cycle is painful, reducing the time available to
-  carefully re-check (to say nothing about what it does to the
-  patience of the person doing the rewrite even if they do technically
-  have more time available).  This problem is extra compounded because
-  errors from broken filters may not be shown for a long time and/or
-  get lost in a sea of output.  Even worse, broken filters often just
-  result in silent incorrect rewrites.
+* Coming up with the correct shell snippet to do the filtering you want
+is sometimes difficult unless you're just doing a trivial modification
+such as deleting a couple files.  Unfortunately, people often learn if
+the snippet is right or wrong by trying it out, but the rightness or
+wrongness can vary depending on special circumstances (spaces in
+filenames, non-ascii filenames, funny author names or emails, invalid
+timezones, presence of grafts or replace objects, etc.), meaning they
+may have to wait a long time, hit an error, then restart.  The
+performance of git-filter-branch is so bad that this cycle is painful,
+reducing the time available to carefully re-check (to say nothing about
+what it does to the patience of the person doing the rewrite even if
+they do technically have more time available).  This problem is extra
+compounded because errors from broken filters may not be shown for a
+long time and/or get lost in a sea of output.  Even worse, broken
+filters often just result in silent incorrect rewrites.
 
-* To top it all off, even when users finally find working commands,
-  they naturally want to share them.  But they may be unaware that
-  their repo didn't have some special cases that someone else's does.
-  So, when someone else with a different repository runs the same
-  commands, they get hit by the problems above.  Or, the user just
-  runs commands that really were vetted for special cases, but they
-  run it on a different OS where it doesn't work, as noted above.
+* To top it all off, even when users finally find working commands, they
+naturally want to share them.  But they may be unaware that their repo
+didn't have some special cases that someone else's does.  So, when
+someone else with a different repository runs the same commands, they
+get hit by the problems above.  Or, the user just runs commands that
+really were vetted for special cases, but they run it on a different OS
+where it doesn't work, as noted above.
 
 GIT
 ---

Documentation/git-format-patch.txt

@@ -19,7 +19,6 @@ SYNOPSIS
 		   [--start-number <n>] [--numbered-files]
 		   [--in-reply-to=<message id>] [--suffix=.<sfx>]
 		   [--ignore-if-in-upstream]
-		   [--cover-from-description=<mode>]
 		   [--rfc] [--subject-prefix=<subject prefix>]
 		   [(--reroll-count|-v) <n>]
 		   [--to=<email>] [--cc=<email>]
@@ -173,26 +172,6 @@ will want to ensure that threading is disabled for `git send-email`.
 	patches being generated, and any patch that matches is
 	ignored.
 
---cover-from-description=<mode>::
-	Controls which parts of the cover letter will be automatically
-	populated using the branch's description.
-+
-If `<mode>` is `message` or `default`, the cover letter subject will be
-populated with placeholder text. The body of the cover letter will be
-populated with the branch's description. This is the default mode when
-no configuration nor command line option is specified.
-+
-If `<mode>` is `subject`, the first paragraph of the branch description will
-populate the cover letter subject. The remainder of the description will
-populate the body of the cover letter.
-+
-If `<mode>` is `auto`, if the first paragraph of the branch description
-is greater than 100 bytes, then the mode will be `message`, otherwise
-`subject` will be used.
-+
-If `<mode>` is `none`, both the cover letter subject and body will be
-populated with placeholder text.
-
 --subject-prefix=<subject prefix>::
 	Instead of the standard '[PATCH]' prefix in the subject
 	line, instead use '[<subject prefix>]'. This
@@ -333,12 +312,11 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
   Output an all-zero hash in each patch's From header instead
   of the hash of the commit.
 
---[no-]base[=<commit>]::
+--base=<commit>::
 	Record the base tree information to identify the state the
 	patch series applies to.  See the BASE TREE INFORMATION section
 	below for details. If <commit> is "auto", a base commit is
-	automatically chosen. The `--no-base` option overrides a
-	`format.useAutoBase` configuration.
+	automatically chosen.
 
 --root::
 	Treat the revision argument as a <revision range>, even if it
@@ -370,7 +348,6 @@ with configuration variables.
 	signOff = true
 	outputDirectory = <directory>
 	coverLetter = auto
-	coverFromDescription = auto
 ------------
 
 

Documentation/git-multi-pack-index.txt

@@ -9,7 +9,7 @@ git-multi-pack-index - Write and verify multi-pack-indexes
 SYNOPSIS
 --------
 [verse]
-'git multi-pack-index' [--object-dir=<dir>] [--[no-]progress] <subcommand>
+'git multi-pack-index' [--object-dir=<dir>] <subcommand>
 
 DESCRIPTION
 -----------
@@ -23,10 +23,6 @@ OPTIONS
 	`<dir>/packs/multi-pack-index` for the current MIDX file, and
 	`<dir>/packs` for the pack-files to index.
 
---[no-]progress::
-	Turn progress on/off explicitly. If neither is specified, progress is
-	shown if standard error is connected to a terminal.
-
 The following subcommands are available:
 
 write::

Documentation/git-notes.txt

@@ -10,7 +10,7 @@ SYNOPSIS
 [verse]
 'git notes' [list [<object>]]
 'git notes' add [-f] [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>]
-'git notes' copy [-f] ( --stdin | <from-object> [<to-object>] )
+'git notes' copy [-f] ( --stdin | <from-object> <to-object> )
 'git notes' append [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>]
 'git notes' edit [--allow-empty] [<object>]
 'git notes' show [<object>]
@@ -68,8 +68,8 @@ add::
 	subcommand).
 
 copy::
-	Copy the notes for the first object onto the second object (defaults to
-	HEAD). Abort if the second object already has notes, or if the first
+	Copy the notes for the first object onto the second object.
+	Abort if the second object already has notes, or if the first
 	object has none (use -f to overwrite existing notes to the
 	second object). This subcommand is equivalent to:
 	`git notes add [-f] -C $(git notes list <from-object>) <to-object>`

Documentation/git-range-diff.txt

@@ -57,10 +57,6 @@ to revert to color all lines according to the outer diff markers
 	See the ``Algorithm`` section below for an explanation why this is
 	needed.
 
---[no-]notes[=<ref>]::
-	This flag is passed to the `git log` program
-	(see linkgit:git-log[1]) that generates the patches.
-
 <range1> <range2>::
 	Compare the commits specified by the two ranges, where
 	`<range1>` is considered an older version of `<range2>`.
@@ -79,7 +75,7 @@ to revert to color all lines according to the outer diff markers
 linkgit:git-diff[1]), most notably the `--color=[<when>]` and
 `--no-color` options. These options are used when generating the "diff
 between patches", i.e. to compare the author, commit message and diff of
-corresponding old/new commits. There is currently no means to tweak most of the
+corresponding old/new commits. There is currently no means to tweak the
 diff options passed to `git log` when generating those patches.
 
 OUTPUT STABILITY
@@ -246,7 +242,7 @@ corresponding.
 
 The overall time needed to compute this algorithm is the time needed to
 compute n+m commit diffs and then n*m diffs of patches, plus the time
-needed to compute the least-cost assignment between n and m diffs. Git
+needed to compute the least-cost assigment between n and m diffs. Git
 uses an implementation of the Jonker-Volgenant algorithm to solve the
 assignment problem, which has cubic runtime complexity. The matching
 found in this case will look like this: