diff --git a/GIT-VERSION-FILE b/GIT-VERSION-FILE
index 6e884bfddf38d9e88b85ddb9e24f3045f07365b4..a55b4a298738108ba9ca8f46c72a8ab8c2c82e57 100644
--- a/GIT-VERSION-FILE
+++ b/GIT-VERSION-FILE
@@ -1 +1 @@
-GIT_VERSION = 2.23.0
+GIT_VERSION = 2.24.0
diff --git a/en/config.txt b/en/config.txt
index e3f5bc3396d0c7502f16eed989220c8e2010bcc1..f50f1b4128ceda08513d1e4f7b1fe95aa1134d95 100644
--- a/en/config.txt
+++ b/en/config.txt
@@ -178,47 +178,49 @@ to either specify only the realpath version, or both versions.
 Example
 ~~~~~~~
 
-	# Core variables
-	[core]
-		; Don't trust file modes
-		filemode = false
-
-	# Our diff algorithm
-	[diff]
-		external = /usr/local/bin/diff-wrapper
-		renames = true
-
-	[branch "devel"]
-		remote = origin
-		merge = refs/heads/devel
-
-	# Proxy settings
-	[core]
-		gitProxy="ssh" for "kernel.org"
-		gitProxy=default-proxy ; for the rest
-
-	[include]
-		path = /path/to/foo.inc ; include by absolute path
-		path = foo.inc ; find "foo.inc" relative to the current file
-		path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
-
-	; include if $GIT_DIR is /path/to/foo/.git
-	[includeIf "gitdir:/path/to/foo/.git"]
-		path = /path/to/foo.inc
-
-	; include for all repositories inside /path/to/group
-	[includeIf "gitdir:/path/to/group/"]
-		path = /path/to/foo.inc
-
-	; include for all repositories inside $HOME/to/group
-	[includeIf "gitdir:~/to/group/"]
-		path = /path/to/foo.inc
-
-	; relative paths are always relative to the including
-	; file (if the condition is true); their location is not
-	; affected by the condition
-	[includeIf "gitdir:/path/to/group/"]
-		path = foo.inc
+----
+# Core variables
+[core]
+	; Don't trust file modes
+	filemode = false
+
+# Our diff algorithm
+[diff]
+	external = /usr/local/bin/diff-wrapper
+	renames = true
+
+[branch "devel"]
+	remote = origin
+	merge = refs/heads/devel
+
+# Proxy settings
+[core]
+	gitProxy="ssh" for "kernel.org"
+	gitProxy=default-proxy ; for the rest
+
+[include]
+	path = /path/to/foo.inc ; include by absolute path
+	path = foo.inc ; find "foo.inc" relative to the current file
+	path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
+
+; include if $GIT_DIR is /path/to/foo/.git
+[includeIf "gitdir:/path/to/foo/.git"]
+	path = /path/to/foo.inc
+
+; include for all repositories inside /path/to/group
+[includeIf "gitdir:/path/to/group/"]
+	path = /path/to/foo.inc
+
+; include for all repositories inside $HOME/to/group
+[includeIf "gitdir:~/to/group/"]
+	path = /path/to/foo.inc
+
+; relative paths are always relative to the including
+; file (if the condition is true); their location is not
+; affected by the condition
+[includeIf "gitdir:/path/to/group/"]
+	path = foo.inc
+----
 
 	; include only if we are in a worktree where foo-branch is
 	; currently checked out
@@ -345,6 +347,8 @@ include::config/difftool.txt[]
 
 include::config/fastimport.txt[]
 
+include::config/feature.txt[]
+
 include::config/fetch.txt[]
 
 include::config/format.txt[]
diff --git a/en/diff-generate-patch.txt b/en/diff-generate-patch.txt
index f10ca410ad8a937e1acc62864c6b33b1db965ac4..e8ed6470fb3a64e2bf713c6a4ed98e9b9e04b4a9 100644
--- a/en/diff-generate-patch.txt
+++ b/en/diff-generate-patch.txt
@@ -1,11 +1,15 @@
-Generating patches with -p
---------------------------
-
-When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
-with a `-p` option, "git diff" without the `--raw` option, or
-"git log" with the "-p" option, they
-do not produce the output described above; instead they produce a
-patch file.  You can customize the creation of such patches via the
+Generating patch text with -p
+-----------------------------
+
+Running
+linkgit:git-diff[1],
+linkgit:git-log[1],
+linkgit:git-show[1],
+linkgit:git-diff-index[1],
+linkgit:git-diff-tree[1], or
+linkgit:git-diff-files[1]
+with the `-p` option produces patch text.
+You can customize the creation of patch text via the
 `GIT_EXTERNAL_DIFF` and the `GIT_DIFF_OPTS` environment variables.
 
 What the -p option produces is slightly different from the traditional
@@ -49,7 +53,7 @@ similarity index value of 100% is thus reserved for two equal
 files, while 100% dissimilarity means that no line from the old
 file made it into the new one.
 +
-The index line includes the SHA-1 checksum before and after the change.
+The index line includes the blob object names before and after the change.
 The <mode> is included if the file mode does not change; otherwise,
 separate lines indicate the old and the new mode.
 
@@ -70,7 +74,7 @@ separate lines indicate the old and the new mode.
       rename to a
 
 
-combined diff format
+Combined diff format
 --------------------
 
 Any diff-generating command can take the `-c` or `--cc` option to
@@ -80,7 +84,7 @@ linkgit:git-show[1]. Note also that you can give the `-m` option to any
 of these commands to force generation of diffs with individual parents
 of a merge.
 
-A 'combined diff' format looks like this:
+A "combined diff" format looks like this:
 
 ------------
 diff --combined describe.c
@@ -113,11 +117,11 @@ index fabadb8,cc95eb0..4866510
 ------------
 
 1.   It is preceded with a "git diff" header, that looks like
-     this (when `-c` option is used):
+     this (when the `-c` option is used):
 
        diff --combined file
 +
-or like this (when `--cc` option is used):
+or like this (when the `--cc` option is used):
 
        diff --cc file
 
@@ -160,7 +164,7 @@ parents.
 4.   Chunk header format is modified to prevent people from
      accidentally feeding it to `patch -p1`. Combined diff format
      was created for review of merge commit changes, and was not
-     meant for apply. The change is similar to the change in the
+     meant to be applied. The change is similar to the change in the
      extended 'index' header:
 
        @@@ <from-file-range> <from-file-range> <to-file-range> @@@
diff --git a/en/diff-options.txt b/en/diff-options.txt
index 09faee3b44db2e78ba909d30c62ff105255c7832..350d0a2fb0925fb9c2d610cb1ba4c0d5ed5b5d3f 100644
--- a/en/diff-options.txt
+++ b/en/diff-options.txt
@@ -452,14 +452,14 @@ endif::git-format-patch[]
 	create. This serves two purposes:
 +
 It affects the way a change that amounts to a total rewrite of a file
-not as a series of deletion and insertion mixed together with a very
-few lines that happen to match textually as the context, but as a
-single deletion of everything old followed by a single insertion of
-everything new, and the number `m` controls this aspect of the -B
-option (defaults to 60%). `-B/70%` specifies that less than 30% of the
-original should remain in the result for Git to consider it a total
-rewrite (i.e. otherwise the resulting patch will be a series of
-deletion and insertion mixed together with context lines).
+does not appear as a series of deletion and insertion mixed together
+with a very few lines that happen to match textually as the context,
+but as a single deletion of everything old followed by a single
+insertion of everything new, and the number `m` controls this aspect
+of the -B option (defaults to 60%). `-B/70%` specifies that less than
+30% of the original should remain in the result for Git to consider it
+a total rewrite (i.e. otherwise the resulting patch will be a series
+of deletion and insertion mixed together with context lines).
 +
 When used with -M, a totally-rewritten file is also considered as the
 source of a rename (usually -M only considers a file that disappeared
diff --git a/en/fetch-options.txt b/en/fetch-options.txt
index 3c9b4f9e09515d99d32a3d6dfa6603ef3a6f23b6..43b9ff3bce218e986e9dabd57a0e7981ff59166a 100644
--- a/en/fetch-options.txt
+++ b/en/fetch-options.txt
@@ -160,15 +160,27 @@ ifndef::git-pull[]
 
 -j::
 --jobs=<n>::
-	Number of parallel children to be used for fetching submodules.
-	Each will fetch from different submodules, such that fetching many
-	submodules will be faster. By default submodules will be fetched
-	one at a time.
+	Number of parallel children to be used for all forms of fetching.
++
+If the `--multiple` option was specified, the different remotes will be fetched
+in parallel. If multiple submodules are fetched, they will be fetched in
+parallel. To control them independently, use the config settings
+`fetch.parallel` and `submodule.fetchJobs` (see linkgit:git-config[1]).
++
+Typically, parallel recursive and multi-remote fetches will be faster. By
+default fetches are performed sequentially, not in parallel.
 
 --no-recurse-submodules::
 	Disable recursive fetching of submodules (this has the same effect as
 	using the `--recurse-submodules=no` option).
 
+--set-upstream::
+	If the remote is fetched successfully, pull and add upstream
+	(tracking) reference, used by argument-less
+	linkgit:git-pull[1] and other commands. For more information,
+	see `branch.<name>.merge` and `branch.<name>.remote` in
+	linkgit:git-config[1].
+
 --submodule-prefix=<path>::
 	Prepend <path> to paths printed in informative messages
 	such as "Fetching submodule foo".  This option is used
diff --git a/en/git-clean.txt b/en/git-clean.txt
index 0028ff12d1dadb2abc7a50816ae6fa5807c82f46..a7f309dff5a327ba14b38b63b931060582c53c28 100644
--- a/en/git-clean.txt
+++ b/en/git-clean.txt
@@ -26,18 +26,20 @@ are affected.
 OPTIONS
 -------
 -d::
-	Remove untracked directories in addition to untracked files.
-	If an untracked directory is managed by a different Git
-	repository, it is not removed by default.  Use -f option twice
-	if you really want to remove such a directory.
+	Normally, when no <path> is specified, git clean will not
+	recurse into untracked directories to avoid removing too much.
+	Specify -d to have it recurse into such directories as well.
+	If any paths are specified, -d is irrelevant; all untracked
+	files matching the specified paths (with exceptions for nested
+	git directories mentioned under `--force`) will be removed.
 
 -f::
 --force::
 	If the Git configuration variable clean.requireForce is not set
 	to false, 'git clean' will refuse to delete files or directories
-	unless given -f, -n or -i. Git will refuse to delete directories
-	with .git sub directory or file unless a second -f
-	is given.
+	unless given -f or -i.  Git will refuse to modify untracked
+	nested git repositories (directories with a .git subdirectory)
+	unless a second -f is given.
 
 -i::
 --interactive::
diff --git a/en/git-commit.txt b/en/git-commit.txt
index 76281932847ba95197894a6b972ef3cb157a40ba..afa7b75a23dac0aed3884b7015da0357996b8ff3 100644
--- a/en/git-commit.txt
+++ b/en/git-commit.txt
@@ -282,18 +282,20 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
 --untracked-files[=<mode>]::
 	Show untracked files.
 +
+--
 The mode parameter is optional (defaults to 'all'), and is used to
 specify the handling of untracked files; when -u is not used, the
 default is 'normal', i.e. show untracked files and directories.
-+
+
 The possible options are:
-+
+
 	- 'no'     - Show no untracked files
 	- 'normal' - Shows untracked files and directories
 	- 'all'    - Also shows individual files in untracked directories.
-+
+
 The default can be changed using the status.showUntrackedFiles
 configuration variable documented in linkgit:git-config[1].
+--
 
 -v::
 --verbose::
diff --git a/en/git-config.txt b/en/git-config.txt
index ff9310f9588a4a13028d1d4182a056262e1079d4..899e92a1c93c1a8adec0b0830a84eccc7915b73d 100644
--- a/en/git-config.txt
+++ b/en/git-config.txt
@@ -339,33 +339,35 @@ EXAMPLES
 
 Given a .git/config like this:
 
-	#
-	# This is the config file, and
-	# a '#' or ';' character indicates
-	# a comment
-	#
-
-	; core variables
-	[core]
-		; Don't trust file modes
-		filemode = false
-
-	; Our diff algorithm
-	[diff]
-		external = /usr/local/bin/diff-wrapper
-		renames = true
-
-	; Proxy settings
-	[core]
-		gitproxy=proxy-command for kernel.org
-		gitproxy=default-proxy ; for all the rest
-
-	; HTTP
-	[http]
-		sslVerify
-	[http "https://weak.example.com"]
-		sslVerify = false
-		cookieFile = /tmp/cookie.txt
+------------
+#
+# This is the config file, and
+# a '#' or ';' character indicates
+# a comment
+#
+
+; core variables
+[core]
+	; Don't trust file modes
+	filemode = false
+
+; Our diff algorithm
+[diff]
+	external = /usr/local/bin/diff-wrapper
+	renames = true
+
+; Proxy settings
+[core]
+	gitproxy=proxy-command for kernel.org
+	gitproxy=default-proxy ; for all the rest
+
+; HTTP
+[http]
+	sslVerify
+[http "https://weak.example.com"]
+	sslVerify = false
+	cookieFile = /tmp/cookie.txt
+------------
 
 you can set the filemode to true with
 
diff --git a/en/git-fast-export.txt b/en/git-fast-export.txt
index cc940eb9ada3ce65bd3e57af73da59b77c99acbc..37634bffd1b1de2320fbb4df871c5ce089df8dc1 100644
--- a/en/git-fast-export.txt
+++ b/en/git-fast-export.txt
@@ -17,9 +17,9 @@ This program dumps the given revisions in a form suitable to be piped
 into 'git fast-import'.
 
 You can use it as a human-readable bundle replacement (see
-linkgit:git-bundle[1]), or as a kind of an interactive
-'git filter-branch'.
-
+linkgit:git-bundle[1]), or as a format that can be edited before being
+fed to 'git fast-import' in order to do history rewrites (an ability
+relied on by tools like 'git filter-repo').
 
 OPTIONS
 -------
@@ -75,11 +75,20 @@ produced incorrect results if you gave these options.
 	Before processing any input, load the marks specified in
 	<file>.  The input file must exist, must be readable, and
 	must use the same format as produced by --export-marks.
+
+--mark-tags::
+	In addition to labelling blobs and commits with mark ids, also
+	label tags.  This is useful in conjunction with
+	`--export-marks` and `--import-marks`, and is also useful (and
+	necessary) for exporting of nested tags.  It does not hurt
+	other cases and would be the default, but many fast-import
+	frontends are not prepared to accept tags with mark
+	identifiers.
 +
-Any commits that have already been marked will not be exported again.
-If the backend uses a similar --import-marks file, this allows for
-incremental bidirectional exporting of the repository by keeping the
-marks the same across runs.
+Any commits (or tags) that have already been marked will not be
+exported again.  If the backend uses a similar --import-marks file,
+this allows for incremental bidirectional exporting of the repository
+by keeping the marks the same across runs.
 
 --fake-missing-tagger::
 	Some old repositories have tags without a tagger.  The
diff --git a/en/git-fast-import.txt b/en/git-fast-import.txt
index fad327aecc1b91c0ed48df740c25fd444eb1431b..a3f1e0c5e4417d66b4a07269b0dbfff7626ad89b 100644
--- a/en/git-fast-import.txt
+++ b/en/git-fast-import.txt
@@ -337,6 +337,13 @@ and control the current import process.  More detailed discussion
 	`commit` command.  This command is optional and is not
 	needed to perform an import.
 
+`alias`::
+	Record that a mark refers to a given object without first
+	creating any new object.  Using --import-marks and referring
+	to missing marks will cause fast-import to fail, so aliases
+	can provide a way to set otherwise pruned commits to a valid
+	value (e.g. the nearest non-pruned ancestor).
+
 `checkpoint`::
 	Forces fast-import to close the current packfile, generate its
 	unique SHA-1 checksum and index, and start a new packfile.
@@ -391,7 +398,7 @@ change to the project.
 	('encoding' SP <encoding>)?
 	data
 	('from' SP <commit-ish> LF)?
-	('merge' SP <commit-ish> LF)?
+	('merge' SP <commit-ish> LF)*
 	(filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
 	LF?
 ....
@@ -774,6 +781,7 @@ lightweight (non-annotated) tags see the `reset` command below.
 
 ....
 	'tag' SP <name> LF
+	mark?
 	'from' SP <commit-ish> LF
 	original-oid?
 	'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
@@ -913,6 +921,21 @@ a data chunk which does not have an LF as its last byte.
 +
 The `LF` after `<delim> LF` is optional (it used to be required).
 
+`alias`
+~~~~~~~
+Record that a mark refers to a given object without first creating any
+new object.
+
+....
+	'alias' LF
+	mark
+	'to' SP <commit-ish> LF
+	LF?
+....
+
+For a detailed description of `<commit-ish>` see above under `from`.
+
+
 `checkpoint`
 ~~~~~~~~~~~~
 Forces fast-import to close the current packfile, start a new one, and to
diff --git a/en/git-filter-branch.txt b/en/git-filter-branch.txt
index 6b53dd7e06a2cd68f35de19679b4f04c3a189be9..5876598852f7b883241d8f9e4efc359b8aab3089 100644
--- a/en/git-filter-branch.txt
+++ b/en/git-filter-branch.txt
@@ -16,6 +16,19 @@ SYNOPSIS
 	[--original <namespace>] [-d <directory>] [-f | --force]
 	[--state-branch <branch>] [--] [<rev-list options>...]
 
+WARNING
+-------
+'git filter-branch' has a plethora of pitfalls that can produce non-obvious
+manglings of the intended history rewrite (and can leave you with little
+time to investigate such problems since it has such abysmal performance).
+These safety and performance issues cannot be backward compatibly fixed and
+as such, its use is not recommended.  Please use an alternative history
+filtering tool such as https://github.com/newren/git-filter-repo/[git
+filter-repo].  If you still need to use 'git filter-branch', please
+carefully read <<SAFETY>> (and <<PERFORMANCE>>) to learn about the land
+mines of filter-branch, and then vigilantly avoid as many of the hazards
+listed there as reasonably possible.
+
 DESCRIPTION
 -----------
 Lets you rewrite Git revision history by rewriting the branches mentioned
@@ -445,36 +458,236 @@ warned.
   (or if your git-gc is not new enough to support arguments to
   `--prune`, use `git repack -ad; git prune` instead).
 
-NOTES
------
-
-git-filter-branch allows you to make complex shell-scripted rewrites
-of your Git history, but you probably don't need this flexibility if
-you're simply _removing unwanted data_ like large files or passwords.
-For those operations you may want to consider
-http://rtyley.github.io/bfg-repo-cleaner/[The BFG Repo-Cleaner],
-a JVM-based alternative to git-filter-branch, typically at least
-10-50x faster for those use-cases, and with quite different
-characteristics:
-
-* Any particular version of a file is cleaned exactly _once_. The BFG,
-  unlike git-filter-branch, does not give you the opportunity to
-  handle a file differently based on where or when it was committed
-  within your history. This constraint gives the core performance
-  benefit of The BFG, and is well-suited to the task of cleansing bad
-  data - you don't care _where_ the bad data is, you just want it
-  _gone_.
-
-* By default The BFG takes full advantage of multi-core machines,
-  cleansing commit file-trees in parallel. git-filter-branch cleans
-  commits sequentially (i.e. in a single-threaded manner), though it
-  _is_ possible to write filters that include their own parallelism,
-  in the scripts executed against each commit.
-
-* The http://rtyley.github.io/bfg-repo-cleaner/#examples[command options]
-  are much more restrictive than git-filter branch, and dedicated just
-  to the tasks of removing unwanted data- e.g:
-  `--strip-blobs-bigger-than 1M`.
+[[PERFORMANCE]]
+PERFORMANCE
+-----------
+
+The performance of git-filter-branch is glacially slow; its design makes it
+impossible for a backward-compatible implementation to ever be fast:
+
+* In editing files, git-filter-branch by design checks out each and
+every commit as it existed in the original repo.  If your repo has 10\^5
+files and 10\^5 commits, but each commit only modifies 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
+
+  ** you run into problems with deletions whenever the user is simply
+     trying to rename files (because attempting to delete files that
+     don't exist looks like a no-op; it takes some chicanery to remap
+     deletes across file renames when the renames happen via arbitrary
+     user-provided shell)
+
+  ** even if you succeed at the map-deletes-for-renames chicanery, you
+     still technically violate backward compatibility because users are
+     allowed to filter files in ways that depend upon topology of
+     commits instead of filtering solely based on file contents or names
+     (though this has not been observed in the wild).
+
+* Even if you don't need to edit files but only want to e.g. rename or
+remove some and thus can avoid checking out each file (i.e. you can use
+--index-filter), you still are passing shell snippets for your filters.
+This means that for every commit, you have to have a prepared git repo
+where those filters can be run.  That's a significant setup.
+
+* Further, several additional files are created or updated per commit by
+git-filter-branch.  Some of these are for supporting the convenience
+functions provided by git-filter-branch (such as map()), while others
+are for keeping track of internal state (but could have also been
+accessed by user filters; one of git-filter-branch's regression tests
+does so).  This essentially amounts to using the filesystem as an IPC
+mechanism between git-filter-branch and the user-provided filters.
+Disks tend to be a slow IPC mechanism, and writing these files also
+effectively represents a forced synchronization point between separate
+processes that we hit with every commit.
+
+* The user-provided shell commands will likely involve a pipeline of
+commands, resulting in the creation of many processes per commit.
+Creating and running another process takes a widely varying amount of
+time between operating systems, but on any platform it is very slow
+relative to invoking a function.
+
+* git-filter-branch itself is written in shell, which is kind of slow.
+This is the one performance issue that could be backward-compatibly
+fixed, but compared to the above problems that are intrinsic to the
+design of git-filter-branch, the language of the tool itself is a
+relatively minor issue.
+
+  ** Side note: Unfortunately, people tend to fixate on the
+     written-in-shell aspect and periodically ask if git-filter-branch
+     could be rewritten in another language to fix the performance
+     issues.  Not only does that ignore the bigger intrinsic problems
+     with the design, it'd help less than you'd expect: if
+     git-filter-branch itself were not shell, then the convenience
+     functions (map(), skip_commit(), etc) and the `--setup` argument
+     could no longer be executed once at the beginning of the program
+     but would instead need to be prepended to every user filter (and
+     thus re-executed with every commit).
+
+The https://github.com/newren/git-filter-repo/[git filter-repo] tool is
+an alternative to git-filter-branch which does not suffer from these
+performance problems or the safety problems (mentioned below). For those
+with existing tooling which relies upon git-filter-branch, 'git
+repo-filter' also provides
+https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/filter-lamely[filter-lamely],
+a drop-in git-filter-branch replacement (with a few caveats).  While
+filter-lamely suffers from all the same safety issues as
+git-filter-branch, it at least ameloriates the performance issues a
+little.
+
+[[SAFETY]]
+SAFETY
+------
+
+git-filter-branch is riddled with gotchas resulting in various ways to
+easily corrupt repos or end up with a mess worse than what you started
+with:
+
+* Someone can have a set of "working and tested filters" which they
+document or provide to a coworker, who then runs them on a different OS
+where the same commands are not working/tested (some examples in the
+git-filter-branch manpage are also affected by this).  BSD vs. GNU
+userland differences can really bite.  If lucky, error messages are
+spewed.  But just as likely, the commands either don't do the filtering
+requested, or silently corrupt by making some unwanted change.  The
+unwanted change may only affect a few commits, so it's not necessarily
+obvious either.  (The fact that problems won't necessarily be obvious
+means they are likely to go unnoticed until the rewritten history is in
+use for quite a while, at which point it's really hard to justify
+another flag-day for another rewrite.)
+
+* Filenames with spaces are often mishandled by shell snippets since
+they cause problems for shell pipelines.  Not everyone is familiar with
+find -print0, xargs -0, git-ls-files -z, etc.  Even people who are
+familiar with these may assume such flags are not relevant because
+someone else renamed any such files in their repo back before the person
+doing the filtering joined the project.  And often, even those familiar
+with handling arguments with spaces may not do so just because they
+aren't in the mindset of thinking about everything that could possibly
+go wrong.
+
+* Non-ascii filenames can be silently removed despite being in a desired
+directory.  Keeping only wanted paths is often done using pipelines like
+`git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`.  ls-files will
+only quote filenames if needed, so folks may not notice that one of the
+files didn't match the regex (at least not until it's much too late).
+Yes, someone who knows about core.quotePath can avoid this (unless they
+have other special characters like \t, \n, or "), and people who use
+ls-files -z with something other than grep can avoid this, but that
+doesn't mean they will.
+
+* Similarly, when moving files around, one can find that filenames with
+non-ascii or special characters end up in a different directory, one
+that includes a double quote character.  (This is technically the same
+issue as above with quoting, but perhaps an interesting different way
+that it can and has manifested as a problem.)
+
+* It's far too easy to accidentally mix up old and new history.  It's
+still possible with any tool, but git-filter-branch almost invites it.
+If lucky, the only downside is users getting frustrated that they don't
+know how to shrink their repo and remove the old stuff.  If unlucky,
+they merge old and new history and end up with multiple "copies" of each
+commit, some of which have unwanted or sensitive files and others which
+don't.  This comes about in multiple different ways:
+
+  ** the default to only doing a partial history rewrite ('--all' is not
+     the default and few examples show it)
+
+  ** the fact that there's no automatic post-run cleanup
+
+  ** the fact that --tag-name-filter (when used to rename tags) doesn't
+     remove the old tags but just adds new ones with the new name
+
+  ** the fact that little educational information is provided to inform
+     users of the ramifications of a rewrite and how to avoid mixing old
+     and new history.  For example, this man page discusses how users
+     need to understand that they need to rebase their changes for all
+     their branches on top of new history (or delete and reclone), but
+     that's only one of multiple concerns to consider.  See the
+     "DISCUSSION" section of the git filter-repo manual page for more
+     details.
+
+* Annotated tags can be accidentally converted to lightweight tags, due
+to either of two issues:
+
+  ** Someone can do a history rewrite, realize they messed up, restore
+     from the backups in refs/original/, and then redo their
+     git-filter-branch command.  (The backup in refs/original/ is not a
+     real backup; it dereferences tags first.)
+
+  ** Running git-filter-branch with either --tags or --all in your
+     <rev-list options>.  In order to retain annotated tags as
+     annotated, you must use --tag-name-filter (and must not have
+     restored from refs/original/ in a previously botched rewrite).
+
+* Any commit messages that specify an encoding will become corrupted
+by the rewrite; git-filter-branch ignores the encoding, takes the original
+bytes, and feeds it to commit-tree without telling it the proper
+encoding.  (This happens whether or not --msg-filter is used.)
+
+* Commit messages (even if they are all UTF-8) by default become
+corrupted due to not being updated -- any references to other commit
+hashes in commit messages will now refer to no-longer-extant commits.
+
+* There are no facilities for helping users find what unwanted crud they
+should delete, which means they are much more likely to have incomplete
+or partial cleanups that sometimes result in confusion and people
+wasting time trying to understand.  (For example, folks tend to just
+look for big files to delete instead of big directories or extensions,
+and once they do so, then sometime later folks using the new repository
+who are going through history will notice a build artifact directory
+that has some files but not others, or a cache of dependencies
+(node_modules or similar) which couldn't have ever been functional since
+it's missing some files.)
+
+* If --prune-empty isn't specified, then the filtering process can
+create hoards of confusing empty commits
+
+* If --prune-empty is specified, then intentionally placed empty
+commits from before the filtering operation are also pruned instead of
+just pruning commits that became empty due to filtering rules.
+
+* If --prune empty is specified, sometimes empty commits are missed
+and left around anyway (a somewhat rare bug, but it happens...)
+
+* A minor issue, but users who have a goal to update all names and
+emails in a repository may be led to --env-filter which will only update
+authors and committers, missing taggers.
+
+* If the user provides a --tag-name-filter that maps multiple tags to
+the same name, no warning or error is provided; git-filter-branch simply
+overwrites each tag in some undocumented pre-defined order resulting in
+only one tag at the end.  (A git-filter-branch regression test requires
+this surprising behavior.)
+
+Also, the poor performance of git-filter-branch often leads to safety
+issues:
+
+* Coming up with the correct shell snippet to do the filtering you want
+is sometimes difficult unless you're just doing a trivial modification
+such as deleting a couple files.  Unfortunately, people often learn if
+the snippet is right or wrong by trying it out, but the rightness or
+wrongness can vary depending on special circumstances (spaces in
+filenames, non-ascii filenames, funny author names or emails, invalid
+timezones, presence of grafts or replace objects, etc.), meaning they
+may have to wait a long time, hit an error, then restart.  The
+performance of git-filter-branch is so bad that this cycle is painful,
+reducing the time available to carefully re-check (to say nothing about
+what it does to the patience of the person doing the rewrite even if
+they do technically have more time available).  This problem is extra
+compounded because errors from broken filters may not be shown for a
+long time and/or get lost in a sea of output.  Even worse, broken
+filters often just result in silent incorrect rewrites.
+
+* To top it all off, even when users finally find working commands, they
+naturally want to share them.  But they may be unaware that their repo
+didn't have some special cases that someone else's does.  So, when
+someone else with a different repository runs the same commands, they
+get hit by the problems above.  Or, the user just runs commands that
+really were vetted for special cases, but they run it on a different OS
+where it doesn't work, as noted above.
 
 GIT
 ---
diff --git a/en/git-format-patch.txt b/en/git-format-patch.txt
index b9b97e63aec5e73e7c5607c19661639a256dc1ed..2035d4d5d53df801186ee7a713a51634d6ac9fd9 100644
--- a/en/git-format-patch.txt
+++ b/en/git-format-patch.txt
@@ -17,9 +17,9 @@ SYNOPSIS
 		   [--signature-file=<file>]
 		   [-n | --numbered | -N | --no-numbered]
 		   [--start-number <n>] [--numbered-files]
-		   [--in-reply-to=Message-Id] [--suffix=.<sfx>]
+		   [--in-reply-to=<message id>] [--suffix=.<sfx>]
 		   [--ignore-if-in-upstream]
-		   [--rfc] [--subject-prefix=Subject-Prefix]
+		   [--rfc] [--subject-prefix=<subject prefix>]
 		   [(--reroll-count|-v) <n>]
 		   [--to=<email>] [--cc=<email>]
 		   [--[no-]cover-letter] [--quiet]
@@ -66,7 +66,8 @@ they are created in the current working directory. The default path
 can be set with the `format.outputDirectory` configuration option.
 The `-o` option takes precedence over `format.outputDirectory`.
 To store patches in the current working directory even when
-`format.outputDirectory` points elsewhere, use `-o .`.
+`format.outputDirectory` points elsewhere, use `-o .`. All directory
+components will be created.
 
 By default, the subject of a single patch is "[PATCH] " followed by
 the concatenation of lines from the commit message up to the first blank
@@ -159,9 +160,9 @@ Beware that the default for 'git send-email' is to thread emails
 itself.  If you want `git format-patch` to take care of threading, you
 will want to ensure that threading is disabled for `git send-email`.
 
---in-reply-to=Message-Id::
+--in-reply-to=<message id>::
 	Make the first mail (or all the mails with `--no-thread`) appear as a
-	reply to the given Message-Id, which avoids breaking threads to
+	reply to the given <message id>, which avoids breaking threads to
 	provide a new patch series.
 
 --ignore-if-in-upstream::
@@ -171,9 +172,9 @@ will want to ensure that threading is disabled for `git send-email`.
 	patches being generated, and any patch that matches is
 	ignored.
 
---subject-prefix=<Subject-Prefix>::
+--subject-prefix=<subject prefix>::
 	Instead of the standard '[PATCH]' prefix in the subject
-	line, instead use '[<Subject-Prefix>]'. This
+	line, instead use '[<subject prefix>]'. This
 	allows for useful naming of a patch series, and can be
 	combined with the `--numbered` option.
 
@@ -314,7 +315,8 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
 --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.
+	below for details. If <commit> is "auto", a base commit is
+	automatically chosen.
 
 --root::
 	Treat the revision argument as a <revision range>, even if it
@@ -330,8 +332,9 @@ CONFIGURATION
 -------------
 You can specify extra mail header lines to be added to each message,
 defaults for the subject prefix and file suffix, number patches when
-outputting more than one patch, add "To" or "Cc:" headers, configure
-attachments, and sign off patches with configuration variables.
+outputting more than one patch, add "To:" or "Cc:" headers, configure
+attachments, change the patch output directory, and sign off patches
+with configuration variables.
 
 ------------
 [format]
@@ -343,7 +346,8 @@ attachments, and sign off patches with configuration variables.
 	cc = <email>
 	attach [ = mime-boundary-string ]
 	signOff = true
-	coverletter = auto
+	outputDirectory = <directory>
+	coverLetter = auto
 ------------
 
 
diff --git a/en/git-gc.txt b/en/git-gc.txt
index 247f765604b0c17b01970d6c1df19687fa1847d2..0c114ad1ca26181776032c3cde957230f23aa602 100644
--- a/en/git-gc.txt
+++ b/en/git-gc.txt
@@ -115,15 +115,14 @@ NOTES
 -----
 
 'git gc' tries very hard not to delete objects that are referenced
-anywhere in your repository. In
-particular, it will keep not only objects referenced by your current set
-of branches and tags, but also objects referenced by the index,
-remote-tracking branches, refs saved by 'git filter-branch' in
-refs/original/, reflogs (which may reference commits in branches
-that were later amended or rewound), and anything else in the refs/* namespace.
-If you are expecting some objects to be deleted and they aren't, check
-all of those locations and decide whether it makes sense in your case to
-remove those references.
+anywhere in your repository. In particular, it will keep not only
+objects referenced by your current set of branches and tags, but also
+objects referenced by the index, remote-tracking branches, notes saved
+by 'git notes' under refs/notes/, reflogs (which may reference commits
+in branches that were later amended or rewound), and anything else in
+the refs/* namespace.  If you are expecting some objects to be deleted
+and they aren't, check all of those locations and decide whether it
+makes sense in your case to remove those references.
 
 On the other hand, when 'git gc' runs concurrently with another process,
 there is a risk of it deleting an object that the other process is using
diff --git a/en/git-grep.txt b/en/git-grep.txt
index 2d27969057fd241922173d286a048e495b74bff0..c89fb569e35855e79a43ee3cde784df5b7cb269c 100644
--- a/en/git-grep.txt
+++ b/en/git-grep.txt
@@ -271,6 +271,23 @@ providing this option will cause it to die.
 
 -f <file>::
 	Read patterns from <file>, one per line.
++
+Passing the pattern via <file> allows for providing a search pattern
+containing a \0.
++
+Not all pattern types support patterns containing \0. Git will error
+out if a given pattern type can't support such a pattern. The
+`--perl-regexp` pattern type when compiled against the PCRE v2 backend
+has the widest support for these types of patterns.
++
+In versions of Git before 2.23.0 patterns containing \0 would be
+silently considered fixed. This was never documented, there were also
+odd and undocumented interactions between e.g. non-ASCII patterns
+containing \0 and `--ignore-case`.
++
+In future versions we may learn to support patterns containing \0 for
+more search backends, until then we'll die when the pattern type in
+question doesn't support them.
 
 -e::
 	The next parameter is the pattern. This option has to be
diff --git a/en/git-gui.txt b/en/git-gui.txt
index 5f93f8003d1dfa43b6fab00253a206e47839efda..c9d7e96214f4eee1308c5c4d9f3791b9310acf29 100644
--- a/en/git-gui.txt
+++ b/en/git-gui.txt
@@ -112,15 +112,9 @@ Other
 versions are distributed as part of the Git suite for the convenience
 of end users.
 
-A 'git gui' development repository can be obtained from:
+The official repository of the 'git gui' project can be found at:
 
-  git clone git://repo.or.cz/git-gui.git
-
-or
-
-  git clone http://repo.or.cz/r/git-gui.git
-
-or browsed online at http://repo.or.cz/w/git-gui.git/[].
+  https://github.com/prati0100/git-gui.git/
 
 GIT
 ---
diff --git a/en/git-ls-remote.txt b/en/git-ls-remote.txt
index 0b057cbb100c4a3013b3836f40bb065ebee0b8bd..a2ea1fd687e532447328cd919499569ff5d9abfa 100644
--- a/en/git-ls-remote.txt
+++ b/en/git-ls-remote.txt
@@ -92,21 +92,23 @@ OPTIONS
 EXAMPLES
 --------
 
-	$ git ls-remote --tags ./.
-	d6602ec5194c87b0fc87103ca4d67251c76f233a	refs/tags/v0.99
-	f25a265a342aed6041ab0cc484224d9ca54b6f41	refs/tags/v0.99.1
-	7ceca275d047c90c0c7d5afb13ab97efdf51bd6e	refs/tags/v0.99.3
-	c5db5456ae3b0873fc659c19fafdde22313cc441	refs/tags/v0.99.2
-	0918385dbd9656cab0d1d81ba7453d49bbc16250	refs/tags/junio-gpg-pub
-	$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
-	5fe978a5381f1fbad26a80e682ddd2a401966740	refs/heads/master
-	c781a84b5204fb294c9ccc79f8b3baceeb32c061	refs/heads/pu
-	$ git remote add korg http://www.kernel.org/pub/scm/git/git.git
-	$ git ls-remote --tags korg v\*
-	d6602ec5194c87b0fc87103ca4d67251c76f233a	refs/tags/v0.99
-	f25a265a342aed6041ab0cc484224d9ca54b6f41	refs/tags/v0.99.1
-	c5db5456ae3b0873fc659c19fafdde22313cc441	refs/tags/v0.99.2
-	7ceca275d047c90c0c7d5afb13ab97efdf51bd6e	refs/tags/v0.99.3
+----
+$ git ls-remote --tags ./.
+d6602ec5194c87b0fc87103ca4d67251c76f233a	refs/tags/v0.99
+f25a265a342aed6041ab0cc484224d9ca54b6f41	refs/tags/v0.99.1
+7ceca275d047c90c0c7d5afb13ab97efdf51bd6e	refs/tags/v0.99.3
+c5db5456ae3b0873fc659c19fafdde22313cc441	refs/tags/v0.99.2
+0918385dbd9656cab0d1d81ba7453d49bbc16250	refs/tags/junio-gpg-pub
+$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
+5fe978a5381f1fbad26a80e682ddd2a401966740	refs/heads/master
+c781a84b5204fb294c9ccc79f8b3baceeb32c061	refs/heads/pu
+$ git remote add korg http://www.kernel.org/pub/scm/git/git.git
+$ git ls-remote --tags korg v\*
+d6602ec5194c87b0fc87103ca4d67251c76f233a	refs/tags/v0.99
+f25a265a342aed6041ab0cc484224d9ca54b6f41	refs/tags/v0.99.1
+c5db5456ae3b0873fc659c19fafdde22313cc441	refs/tags/v0.99.2
+7ceca275d047c90c0c7d5afb13ab97efdf51bd6e	refs/tags/v0.99.3
+----
 
 SEE ALSO
 --------
diff --git a/en/git-merge-base.txt b/en/git-merge-base.txt
index 261d5c1164547cc0ce423935107f178afd6956b0..2d944e0851f6a8e295bf8d8e0aac14725e1b4326 100644
--- a/en/git-merge-base.txt
+++ b/en/git-merge-base.txt
@@ -80,9 +80,11 @@ which is reachable from both 'A' and 'B' through the parent relationship.
 
 For example, with this topology:
 
-	         o---o---o---B
-	        /
-	---o---1---o---o---o---A
+....
+	 o---o---o---B
+	/
+---o---1---o---o---o---A
+....
 
 the merge base between 'A' and 'B' is '1'.
 
@@ -90,21 +92,25 @@ Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the
 merge base between 'A' and a hypothetical commit 'M', which is a merge
 between 'B' and 'C'.  For example, with this topology:
 
-	       o---o---o---o---C
-	      /
-	     /   o---o---o---B
-	    /   /
-	---2---1---o---o---o---A
+....
+       o---o---o---o---C
+      /
+     /   o---o---o---B
+    /   /
+---2---1---o---o---o---A
+....
 
 the result of `git merge-base A B C` is '1'.  This is because the
 equivalent topology with a merge commit 'M' between 'B' and 'C' is:
 
 
-	       o---o---o---o---o
-	      /                 \
-	     /   o---o---o---o---M
-	    /   /
-	---2---1---o---o---o---A
+....
+       o---o---o---o---o
+      /                 \
+     /   o---o---o---o---M
+    /   /
+---2---1---o---o---o---A
+....
 
 and the result of `git merge-base A M` is '1'.  Commit '2' is also a
 common ancestor between 'A' and 'M', but '1' is a better common ancestor,
@@ -116,11 +122,13 @@ the best common ancestor of all commits.
 When the history involves criss-cross merges, there can be more than one
 'best' common ancestor for two commits.  For example, with this topology:
 
-	---1---o---A
-	    \ /
-	     X
-	    / \
-	---2---o---o---B
+....
+---1---o---A
+    \ /
+     X
+    / \
+---2---o---o---B
+....
 
 both '1' and '2' are merge-bases of A and B.  Neither one is better than
 the other (both are 'best' merge bases).  When the `--all` option is not given,
@@ -131,18 +139,22 @@ and B is (or at least used to be) to compute the merge base between
 A and B, and check if it is the same as A, in which case, A is an
 ancestor of B.  You will see this idiom used often in older scripts.
 
-	A=$(git rev-parse --verify A)
-	if test "$A" = "$(git merge-base A B)"
-	then
-		... A is an ancestor of B ...
-	fi
+....
+A=$(git rev-parse --verify A)
+if test "$A" = "$(git merge-base A B)"
+then
+	... A is an ancestor of B ...
+fi
+....
 
 In modern git, you can say this in a more direct way:
 
-	if git merge-base --is-ancestor A B
-	then
-		... A is an ancestor of B ...
-	fi
+....
+if git merge-base --is-ancestor A B
+then
+	... A is an ancestor of B ...
+fi
+....
 
 instead.
 
@@ -154,13 +166,15 @@ topic origin/master`, the history of remote-tracking branch
 `origin/master` may have been rewound and rebuilt, leading to a
 history of this shape:
 
-	                 o---B2
-	                /
-	---o---o---B1--o---o---o---B (origin/master)
-	        \
-	         B0
-	          \
-	           D0---D1---D (topic)
+....
+		 o---B2
+		/
+---o---o---B1--o---o---o---B (origin/master)
+	\
+	 B0
+	  \
+	   D0---D1---D (topic)
+....
 
 where `origin/master` used to point at commits B0, B1, B2 and now it
 points at B, and your `topic` branch was started on top of it back
@@ -193,13 +207,15 @@ will find B0, and
 will replay D0, D1 and D on top of B to create a new history of this
 shape:
 
-			 o---B2
-			/
-	---o---o---B1--o---o---o---B (origin/master)
-		\                   \
-		 B0                  D0'--D1'--D' (topic - updated)
-		  \
-		   D0---D1---D (topic - old)
+....
+		 o---B2
+		/
+---o---o---B1--o---o---o---B (origin/master)
+	\                   \
+	 B0                  D0'--D1'--D' (topic - updated)
+	  \
+	   D0---D1---D (topic - old)
+....
 
 A caveat is that older reflog entries in your repository may be
 expired by `git gc`.  If B0 no longer appears in the reflog of the
diff --git a/en/git-merge-index.txt b/en/git-merge-index.txt
index 02676fb39197d8c4ae33b3d6aa3e8fa27b8e3350..2ab84a91e5388ac5caf4a5f1e4725f4f58c9f499 100644
--- a/en/git-merge-index.txt
+++ b/en/git-merge-index.txt
@@ -54,20 +54,24 @@ original is first. But the argument order to the 3-way merge program
 
 Examples:
 
-  torvalds@ppc970:~/merge-test> git merge-index cat MM
-  This is MM from the original tree.			# original
-  This is modified MM in the branch A.			# merge1
-  This is modified MM in the branch B.			# merge2
-  This is modified MM in the branch B.			# current contents
+----
+torvalds@ppc970:~/merge-test> git merge-index cat MM
+This is MM from the original tree.		# original
+This is modified MM in the branch A.		# merge1
+This is modified MM in the branch B.		# merge2
+This is modified MM in the branch B.		# current contents
+----
 
 or
 
-  torvalds@ppc970:~/merge-test> git merge-index cat AA MM
-  cat: : No such file or directory
-  This is added AA in the branch A.
-  This is added AA in the branch B.
-  This is added AA in the branch B.
-  fatal: merge program failed
+----
+torvalds@ppc970:~/merge-test> git merge-index cat AA MM
+cat: : No such file or directory
+This is added AA in the branch A.
+This is added AA in the branch B.
+This is added AA in the branch B.
+fatal: merge program failed
+----
 
 where the latter example shows how 'git merge-index' will stop trying to
 merge once anything has returned an error (i.e., `cat` returned an error
diff --git a/en/git-merge.txt b/en/git-merge.txt
index 01fd52dc7063802226bf4f7205a2a1aab697bc67..092529c619e29cfa1c0959358d4671ff1cba1144 100644
--- a/en/git-merge.txt
+++ b/en/git-merge.txt
@@ -10,7 +10,7 @@ SYNOPSIS
 --------
 [verse]
 'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
-	[-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
+	[--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
 	[--[no-]allow-unrelated-histories]
 	[--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [<commit>...]
 'git merge' (--continue | --abort | --quit)
diff --git a/en/git-rebase.txt b/en/git-rebase.txt
index 6156609cf7149ccf5c1f79df2d9807cdbcc609ba..639a4179d18e4d154f30351aaa4f3b3c79c48c1e 100644
--- a/en/git-rebase.txt
+++ b/en/git-rebase.txt
@@ -8,8 +8,8 @@ git-rebase - Reapply commits on top of another base tip
 SYNOPSIS
 --------
 [verse]
-'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
-	[<upstream> [<branch>]]
+'git rebase' [-i | --interactive] [<options>] [--exec <cmd>]
+	[--onto <newbase> | --keep-base] [<upstream> [<branch>]]
 'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
 	--root [<branch>]
 'git rebase' (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch)
@@ -217,6 +217,24 @@ As a special case, you may use "A\...B" as a shortcut for the
 merge base of A and B if there is exactly one merge base. You can
 leave out at most one of A and B, in which case it defaults to HEAD.
 
+--keep-base::
+	Set the starting point at which to create the new commits to the
+	merge base of <upstream> <branch>. Running
+	'git rebase --keep-base <upstream> <branch>' is equivalent to
+	running 'git rebase --onto <upstream>... <upstream>'.
++
+This option is useful in the case where one is developing a feature on
+top of an upstream branch. While the feature is being worked on, the
+upstream branch may advance and it may not be the best idea to keep
+rebasing on top of the upstream but to keep the base commit as-is.
++
+Although both this option and --fork-point find the merge base between
+<upstream> and <branch>, this option uses the merge base as the _starting
+point_ on which new commits will be created, whereas --fork-point uses
+the merge base to determine the _set of commits_ which will be rebased.
++
+See also INCOMPATIBLE OPTIONS below.
+
 <upstream>::
 	Upstream branch to compare against.  May be any valid commit,
 	not just an existing branch name. Defaults to the configured
@@ -369,6 +387,10 @@ ends up being empty, the <upstream> will be used as a fallback.
 +
 If either <upstream> or --root is given on the command line, then the
 default is `--no-fork-point`, otherwise the default is `--fork-point`.
++
+If your branch was based on <upstream> but <upstream> was rewound and
+your branch contains commits which were dropped, this option can be used
+with `--keep-base` in order to drop those commits from your branch.
 
 --ignore-whitespace::
 --whitespace=<option>::
@@ -543,8 +565,8 @@ In addition, the following pairs of options are incompatible:
  * --preserve-merges and --interactive
  * --preserve-merges and --signoff
  * --preserve-merges and --rebase-merges
- * --rebase-merges and --strategy
- * --rebase-merges and --strategy-option
+ * --keep-base and --onto
+ * --keep-base and --root
 
 BEHAVIORAL DIFFERENCES
 -----------------------
@@ -832,7 +854,8 @@ Hard case: The changes are not the same.::
 	This happens if the 'subsystem' rebase had conflicts, or used
 	`--interactive` to omit, edit, squash, or fixup commits; or
 	if the upstream used one of `commit --amend`, `reset`, or
-	`filter-branch`.
+	a full history rewriting command like
+	https://github.com/newren/git-filter-repo[`filter-repo`].
 
 
 The easy case
@@ -870,7 +893,7 @@ NOTE: While an "easy case recovery" sometimes appears to be successful
       --interactive` will be **resurrected**!
 
 The idea is to manually tell 'git rebase' "where the old 'subsystem'
-ended and your 'topic' began", that is, what the old merge-base
+ended and your 'topic' began", that is, what the old merge base
 between them was.  You will have to find a way to name the last commit
 of the old 'subsystem', for example:
 
diff --git a/en/git-receive-pack.txt b/en/git-receive-pack.txt
index dedf97efbb2282a15abfee41926afd893e59955c..25702ed73072f7375a08294a024e076862a5a170 100644
--- a/en/git-receive-pack.txt
+++ b/en/git-receive-pack.txt
@@ -165,29 +165,31 @@ ref listing the commits pushed to the repository, and logs the push
 certificates of signed pushes with good signatures to a logger
 service:
 
-	#!/bin/sh
-	# mail out commit update information.
-	while read oval nval ref
-	do
-		if expr "$oval" : '0*$' >/dev/null
-		then
-			echo "Created a new ref, with the following commits:"
-			git rev-list --pretty "$nval"
-		else
-			echo "New commits:"
-			git rev-list --pretty "$nval" "^$oval"
-		fi |
-		mail -s "Changes to ref $ref" commit-list@mydomain
-	done
-	# log signed push certificate, if any
-	if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
+----
+#!/bin/sh
+# mail out commit update information.
+while read oval nval ref
+do
+	if expr "$oval" : '0*$' >/dev/null
 	then
-		(
-			echo expected nonce is ${GIT_PUSH_NONCE}
-			git cat-file blob ${GIT_PUSH_CERT}
-		) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
-	fi
-	exit 0
+		echo "Created a new ref, with the following commits:"
+		git rev-list --pretty "$nval"
+	else
+		echo "New commits:"
+		git rev-list --pretty "$nval" "^$oval"
+	fi |
+	mail -s "Changes to ref $ref" commit-list@mydomain
+done
+# log signed push certificate, if any
+if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
+then
+	(
+		echo expected nonce is ${GIT_PUSH_NONCE}
+		git cat-file blob ${GIT_PUSH_CERT}
+	) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
+fi
+exit 0
+----
 
 The exit code from this hook invocation is ignored, however a
 non-zero exit code will generate an error message.
@@ -212,8 +214,10 @@ anyway.
 This hook can be used, for example, to run `git update-server-info`
 if the repository is packed and is served via a dumb transport.
 
-	#!/bin/sh
-	exec git update-server-info
+----
+#!/bin/sh
+exec git update-server-info
+----
 
 
 QUARANTINE ENVIRONMENT
diff --git a/en/git-replace.txt b/en/git-replace.txt
index 246dc9943c223d34c72d7b90f40ee8f523b7d77e..f271d758c38230410165238de266db7de2d73f71 100644
--- a/en/git-replace.txt
+++ b/en/git-replace.txt
@@ -123,10 +123,10 @@ The following format are available:
 CREATING REPLACEMENT OBJECTS
 ----------------------------
 
-linkgit:git-filter-branch[1], linkgit:git-hash-object[1] and
-linkgit:git-rebase[1], among other git commands, can be used to create
-replacement objects from existing objects. The `--edit` option can
-also be used with 'git replace' to create a replacement object by
+linkgit:git-hash-object[1], linkgit:git-rebase[1], and
+https://github.com/newren/git-filter-repo[git-filter-repo], among other git commands, can be used to
+create replacement objects from existing objects. The `--edit` option
+can also be used with 'git replace' to create a replacement object by
 editing an existing object.
 
 If you want to replace many blobs, trees or commits that are part of a
@@ -148,13 +148,13 @@ pending objects.
 SEE ALSO
 --------
 linkgit:git-hash-object[1]
-linkgit:git-filter-branch[1]
 linkgit:git-rebase[1]
 linkgit:git-tag[1]
 linkgit:git-branch[1]
 linkgit:git-commit[1]
 linkgit:git-var[1]
 linkgit:git[1]
+https://github.com/newren/git-filter-repo[git-filter-repo]
 
 GIT
 ---
diff --git a/en/git-rev-list.txt b/en/git-rev-list.txt
index 9392760b25411c889d53114fd55886cc7e3fb679..025c9114365682cab4feb345c3a69beb5900d299 100644
--- a/en/git-rev-list.txt
+++ b/en/git-rev-list.txt
@@ -9,59 +9,7 @@ git-rev-list - Lists commit objects in reverse chronological order
 SYNOPSIS
 --------
 [verse]
-'git rev-list' [ --max-count=<number> ]
-	     [ --skip=<number> ]
-	     [ --max-age=<timestamp> ]
-	     [ --min-age=<timestamp> ]
-	     [ --sparse ]
-	     [ --merges ]
-	     [ --no-merges ]
-	     [ --min-parents=<number> ]
-	     [ --no-min-parents ]
-	     [ --max-parents=<number> ]
-	     [ --no-max-parents ]
-	     [ --first-parent ]
-	     [ --remove-empty ]
-	     [ --full-history ]
-	     [ --not ]
-	     [ --all ]
-	     [ --branches[=<pattern>] ]
-	     [ --tags[=<pattern>] ]
-	     [ --remotes[=<pattern>] ]
-	     [ --glob=<glob-pattern> ]
-	     [ --ignore-missing ]
-	     [ --stdin ]
-	     [ --quiet ]
-	     [ --topo-order ]
-	     [ --parents ]
-	     [ --timestamp ]
-	     [ --left-right ]
-	     [ --left-only ]
-	     [ --right-only ]
-	     [ --cherry-mark ]
-	     [ --cherry-pick ]
-	     [ --encoding=<encoding> ]
-	     [ --(author|committer|grep)=<pattern> ]
-	     [ --regexp-ignore-case | -i ]
-	     [ --extended-regexp | -E ]
-	     [ --fixed-strings | -F ]
-	     [ --date=<format>]
-	     [ [ --objects | --objects-edge | --objects-edge-aggressive ]
-	       [ --unpacked ]
-	       [ --object-names | --no-object-names ]
-	       [ --filter=<filter-spec> [ --filter-print-omitted ] ] ]
-	     [ --missing=<missing-action> ]
-	     [ --pretty | --header ]
-	     [ --bisect ]
-	     [ --bisect-vars ]
-	     [ --bisect-all ]
-	     [ --merge ]
-	     [ --reverse ]
-	     [ --walk-reflogs ]
-	     [ --no-walk ] [ --do-walk ]
-	     [ --count ]
-	     [ --use-bitmap-index ]
-	     <commit>... [ \-- <paths>... ]
+'git rev-list' [<options>] <commit>... [[--] <path>...]
 
 DESCRIPTION
 -----------
diff --git a/en/git-send-email.txt b/en/git-send-email.txt
index d93e5d0f58f0602e0cd0da7bfd6ce11f49b110d6..0a69810147e451d7cac290020f009631b1da9e46 100644
--- a/en/git-send-email.txt
+++ b/en/git-send-email.txt
@@ -486,11 +486,13 @@ Use gmail as the smtp server
 To use 'git send-email' to send your patches through the GMail SMTP server,
 edit ~/.gitconfig to specify your account settings:
 
-	[sendemail]
-		smtpEncryption = tls
-		smtpServer = smtp.gmail.com
-		smtpUser = yourname@gmail.com
-		smtpServerPort = 587
+----
+[sendemail]
+	smtpEncryption = tls
+	smtpServer = smtp.gmail.com
+	smtpUser = yourname@gmail.com
+	smtpServerPort = 587
+----
 
 If you have multifactor authentication setup on your gmail account, you will
 need to generate an app-specific password for use with 'git send-email'. Visit
diff --git a/en/git-stash.txt b/en/git-stash.txt
index 8fbe12c66c823bce8756eaf3c836d5e8f0f7a340..53e1a1205d3088ed83300df89a02216dd46e556f 100644
--- a/en/git-stash.txt
+++ b/en/git-stash.txt
@@ -87,8 +87,9 @@ The `--patch` option implies `--keep-index`.  You can use
 save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]::
 
 	This option is deprecated in favour of 'git stash push'.  It
-	differs from "stash push" in that it cannot take pathspecs,
-	and any non-option arguments form the message.
+	differs from "stash push" in that it cannot take pathspecs.
+	Instead, all non-option arguments are concatenated to form the stash
+	message.
 
 list [<options>]::
 
diff --git a/en/git-status.txt b/en/git-status.txt
index d4e8f24f0c86a6998a6190d5c5bfa542c1ef0f4f..7731b45f078e92e01df48d47d9f9abf9d1d931c1 100644
--- a/en/git-status.txt
+++ b/en/git-status.txt
@@ -59,16 +59,17 @@ This is optional and defaults to the original version 'v1' format.
 --untracked-files[=<mode>]::
 	Show untracked files.
 +
+--
 The mode parameter is used to specify the handling of untracked files.
 It is optional: it defaults to 'all', and if specified, it must be
 stuck to the option (e.g. `-uno`, but not `-u no`).
-+
+
 The possible options are:
-+
+
 	- 'no'     - Show no untracked files.
 	- 'normal' - Shows untracked files and directories.
 	- 'all'    - Also shows individual files in untracked directories.
-+
+
 When `-u` option is not used, untracked files and directories are
 shown (i.e. the same as specifying `normal`), to help you avoid
 forgetting to add newly created files.  Because it takes extra work
@@ -78,9 +79,10 @@ Consider enabling untracked cache and split index if supported (see
 `git update-index --untracked-cache` and `git update-index
 --split-index`), Otherwise you can use `no` to have `git status`
 return more quickly without showing untracked files.
-+
+
 The default can be changed using the status.showUntrackedFiles
 configuration variable documented in linkgit:git-config[1].
+--
 
 --ignore-submodules[=<when>]::
 	Ignore changes to submodules when looking for changes. <when> can be
@@ -100,11 +102,12 @@ configuration variable documented in linkgit:git-config[1].
 --ignored[=<mode>]::
 	Show ignored files as well.
 +
+--
 The mode parameter is used to specify the handling of ignored files.
 It is optional: it defaults to 'traditional'.
-+
+
 The possible options are:
-+
+
 	- 'traditional' - Shows ignored files and directories, unless
 			  --untracked-files=all is specified, in which case
 			  individual files in ignored directories are
@@ -112,12 +115,13 @@ The possible options are:
 	- 'no'	        - Show no ignored files.
 	- 'matching'    - Shows ignored files and directories matching an
 			  ignore pattern.
-+
+
 When 'matching' mode is specified, paths that explicitly match an
 ignored pattern are shown. If a directory matches an ignore pattern,
 then it is shown, but not paths contained in the ignored directory. If
 a directory does not match an ignore pattern, but all contents are
 ignored, then the directory is not shown, but all contents are shown.
+--
 
 -z::
 	Terminate entries with NUL, instead of LF.  This implies
diff --git a/en/git-submodule.txt b/en/git-submodule.txt
index 0ed5c24dc1ce553d0b0ac90d49fcf161a3320474..1f46380af2d49360802dfa579d4b51b6e1fbaeda 100644
--- a/en/git-submodule.txt
+++ b/en/git-submodule.txt
@@ -173,7 +173,8 @@ submodule with the `--init` option.
 If `--recursive` is specified, this command will recurse into the
 registered submodules, and update any nested submodules within.
 --
-set-branch ((-d|--default)|(-b|--branch <branch>)) [--] <path>::
+set-branch (-b|--branch) <branch> [--] <path>::
+set-branch (-d|--default) [--] <path>::
 	Sets the default remote tracking branch for the submodule. The
 	`--branch` option allows the remote branch to be specified. The
 	`--default` option removes the submodule.<name>.branch configuration
diff --git a/en/git-svn.txt b/en/git-svn.txt
index 30711625fdec5ef4a46233b27fcd562a56e773e3..53774f5b642550a6d29b32fc748a06f08c05f711 100644
--- a/en/git-svn.txt
+++ b/en/git-svn.txt
@@ -769,11 +769,11 @@ option for (hopefully) obvious reasons.
 +
 This option is NOT recommended as it makes it difficult to track down
 old references to SVN revision numbers in existing documentation, bug
-reports and archives.  If you plan to eventually migrate from SVN to Git
-and are certain about dropping SVN history, consider
-linkgit:git-filter-branch[1] instead.  filter-branch also allows
-reformatting of metadata for ease-of-reading and rewriting authorship
-info for non-"svn.authorsFile" users.
+reports, and archives.  If you plan to eventually migrate from SVN to
+Git and are certain about dropping SVN history, consider
+https://github.com/newren/git-filter-repo[git-filter-repo] instead.
+filter-repo also allows reformatting of metadata for ease-of-reading
+and rewriting authorship info for non-"svn.authorsFile" users.
 
 svn.useSvmProps::
 svn-remote.<name>.useSvmProps::
diff --git a/en/merge-options.txt b/en/merge-options.txt
index 79a00d2a4abd6f7191f2639185e199fa85f6289b..59b8ff1e51a5e173c208d1c8cd7fab71dcf37a2e 100644
--- a/en/merge-options.txt
+++ b/en/merge-options.txt
@@ -40,20 +40,24 @@ set to `no` at the beginning of them.
 	case of a merge conflict.
 
 --ff::
-	When the merge resolves as a fast-forward, only update the branch
-	pointer, without creating a merge commit.  This is the default
-	behavior.
-
 --no-ff::
-	Create a merge commit even when the merge resolves as a
-	fast-forward.  This is the default behaviour when merging an
-	annotated (and possibly signed) tag that is not stored in
-	its natural place in 'refs/tags/' hierarchy.
-
 --ff-only::
-	Refuse to merge and exit with a non-zero status unless the
-	current `HEAD` is already up to date or the merge can be
-	resolved as a fast-forward.
+	Specifies how a merge is handled when the merged-in history is
+	already a descendant of the current history.  `--ff` is the
+	default unless merging an annotated (and possibly signed) tag
+	that is not stored in its natural place in the `refs/tags/`
+	hierarchy, in which case `--no-ff` is assumed.
++
+With `--ff`, when possible resolve the merge as a fast-forward (only
+update the branch pointer to match the merged branch; do not create a
+merge commit).  When not possible (when the merged-in history is not a
+descendant of the current history), create a merge commit.
++
+With `--no-ff`, create a merge commit in all cases, even when the merge
+could instead be resolved as a fast-forward.
++
+With `--ff-only`, resolve the merge as a fast-forward when possible.
+When not possible, refuse to merge and exit with a non-zero status.
 
 -S[<keyid>]::
 --gpg-sign[=<keyid>]::
@@ -105,6 +109,10 @@ option can be used to override --squash.
 +
 With --squash, --commit is not allowed, and will fail.
 
+--no-verify::
+	This option bypasses the pre-merge and commit-msg hooks.
+	See also linkgit:githooks[5].
+
 -s <strategy>::
 --strategy=<strategy>::
 	Use the given merge strategy; can be supplied more than
diff --git a/en/pretty-formats.txt b/en/pretty-formats.txt
index 079598307a3897d913de030a4737ce2e43c1810d..b87e2e83e6d01de371f2f880f3f77fade22b45eb 100644
--- a/en/pretty-formats.txt
+++ b/en/pretty-formats.txt
@@ -208,7 +208,7 @@ endif::git-rev-list[]
 '%GP':: show the fingerprint of the primary key whose subkey was used
 	to sign a signed commit
 '%gD':: reflog selector, e.g., `refs/stash@{1}` or `refs/stash@{2
-	minutes ago`}; the format follows the rules described for the
+	minutes ago}`; the format follows the rules described for the
 	`-g` option. The portion before the `@` is the refname as
 	given on the command line (so `git log -g refs/heads/master`
 	would yield `refs/heads/master@{0}`).
diff --git a/en/rev-list-options.txt b/en/rev-list-options.txt
index bb1251c0364dc71880f6e63db7c6116ed859b90f..90ff9e2bea2e2fd0caf4744ed4e5c5e59f4c1243 100644
--- a/en/rev-list-options.txt
+++ b/en/rev-list-options.txt
@@ -756,6 +756,22 @@ explicitly-given commit or tree.
 Note that the form '--filter=sparse:path=<path>' that wants to read
 from an arbitrary path on the filesystem has been dropped for security
 reasons.
++
+Multiple '--filter=' flags can be specified to combine filters. Only
+objects which are accepted by every filter are included.
++
+The form '--filter=combine:<filter1>+<filter2>+...<filterN>' can also be
+used to combined several filters, but this is harder than just repeating
+the '--filter' flag and is usually not necessary. Filters are joined by
+'{plus}' and individual filters are %-encoded (i.e. URL-encoded).
+Besides the '{plus}' and '%' characters, the following characters are
+reserved and also must be encoded: `~!@#$^&*()[]{}\;",<>?`+&#39;&#96;+
+as well as all characters with ASCII code &lt;= `0x20`, which includes
+space and newline.
++
+Other arbitrary characters can also be encoded. For instance,
+'combine:tree:3+blob:none' and 'combine:tree%3A3+blob%3Anone' are
+equivalent.
 
 --no-filter::
 	Turn off any previous `--filter=` argument.