Revert "Jch"

Documentation/config.adoc

@@ -146,48 +146,6 @@ refer to linkgit:gitignore[5] for details. For convenience:
 	This is the same as `gitdir` except that matching is done
 	case-insensitively (e.g. on case-insensitive file systems)
 
-`worktree`::
-	The data that follows the keyword `worktree` and a colon is used as a
-	glob pattern. If the working directory of the current worktree matches
-	the pattern, the include condition is met.
-+
-The worktree location is the path where files are checked out (as returned
-by `git rev-parse --show-toplevel`). This is different from `gitdir`, which
-matches the `.git` directory path. In a linked worktree, the worktree path
-is the directory where that worktree's files are located, not the main
-repository's `.git` directory.
-+
-The pattern can contain standard globbing wildcards and two additional
-ones, `**/` and `/**`, that can match multiple path components. Please
-refer to linkgit:gitignore[5] for details. For convenience:
-
- * If the pattern starts with `~/`, `~` will be substituted with the
-   content of the environment variable `HOME`.
-
- * If the pattern starts with `./`, it is replaced with the directory
-   containing the current config file.
-
- * If the pattern does not start with either `~/`, `./` or `/`, `**/`
-   will be automatically prepended. For example, the pattern `foo/bar`
-   becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
-
- * If the pattern ends with `/`, `**` will be automatically added. For
-   example, the pattern `foo/` becomes `foo/**`. In other words, it
-   matches "foo" and everything inside, recursively.
-+
-This condition will never match in a bare repository (which has no worktree).
-+
-This is useful when you need to use different `user.name`, `user.email`, or
-GPG keys in different worktrees of the same repository. While
-`extensions.worktreeConfig` also allows per-worktree configuration, it
-requires changes inside each repository. This condition can be set in the
-user's global configuration file (e.g. `~/.config/git/config`) and applies
-to multiple repositories at once.
-
-`worktree/i`::
-	This is the same as `worktree` except that matching is done
-	case-insensitively (e.g. on case-insensitive file systems)
-
 `onbranch`::
 	The data that follows the keyword `onbranch` and a colon is taken to be a
 	pattern with standard globbing wildcards and two additional
@@ -286,14 +244,6 @@ Example
 [includeIf "gitdir:~/to/group/"]
 	path = /path/to/foo.inc
 
-; include if the worktree is at /path/to/project-build
-[includeIf "worktree:/path/to/project-build"]
-	path = build-config.inc
-
-; include for all worktrees inside /path/to/group
-[includeIf "worktree:/path/to/group/"]
-	path = group-config.inc
-
 ; relative paths are always relative to the including
 ; file (if the condition is true); their location is not
 ; affected by the condition

Documentation/config/remote.adoc

@@ -107,46 +107,6 @@ priority configuration file (e.g. `.git/config` in a repository) to clear
 the values inherited from a lower priority configuration files (e.g.
 `$HOME/.gitconfig`).
 
-remote.<name>.negotiationRestrict::
-	When negotiating with this remote during `git fetch` and `git push`,
-	restrict the commits advertised as "have" lines to only those
-	reachable from refs matching the given patterns.  This multi-valued
-	config option behaves like `--negotiation-restrict` on the command
-	line.
-+
-Each value is either an exact ref name (e.g. `refs/heads/release`) or a
-glob pattern (e.g. `refs/heads/release/*`).  The pattern syntax is the
-same as for `--negotiation-restrict`.
-+
-These config values are used as defaults for the `--negotiation-restrict`
-command-line option.  If `--negotiation-restrict` (or its synonym
-`--negotiation-tip`) is specified on the command line, then the config
-values are not used.
-
-remote.<name>.negotiationRequire::
-	When negotiating with this remote during `git fetch` and `git push`,
-	the client advertises a list of commits that exist locally.  In
-	repos with many references, this list of "haves" can be truncated.
-	Depending on data shape, dropping certain references may be
-	expensive.  This multi-valued config option specifies ref patterns
-	whose tips should always be sent as "have" commits during fetch
-	negotiation with this remote.
-+
-Each value is either an exact ref name (e.g. `refs/heads/release`) or a
-glob pattern (e.g. `refs/heads/release/*`).  The pattern syntax is the same
-as for `--negotiation-restrict`.
-+
-These config values are used as defaults for the `--negotiation-require`
-command-line option.  If `--negotiation-require` is specified on the
-command line, then the config values are not used.
-+
-This option is additive with the normal negotiation process: the
-negotiation algorithm still runs and advertises its own selected commits,
-but the refs matching `remote.<name>.negotiationRequire` are sent
-unconditionally on top of those heuristically selected commits.  This
-option is also used during push negotiation when `push.negotiate` is
-enabled.
-
 remote.<name>.followRemoteHEAD::
 	How linkgit:git-fetch[1] should handle updates to `remotes/<name>/HEAD`
 	when fetching using the configured refspecs of a remote.

Documentation/fetch-options.adoc

@@ -49,7 +49,6 @@ the current repository has the same history as the source repository.
 	`.git/shallow`. This option updates `.git/shallow` and accepts such
 	refs.
 
-`--negotiation-restrict=(<commit>|<glob>)`::
 `--negotiation-tip=(<commit>|<glob>)`::
 	By default, Git will report, to the server, commits reachable
 	from all local refs to find common commits in an attempt to
@@ -59,9 +58,6 @@ the current repository has the same history as the source repository.
 	local ref is likely to have commits in common with the
 	upstream ref being fetched.
 +
-`--negotiation-restrict` is the preferred name for this option;
-`--negotiation-tip` is accepted as a synonym.
-+
 This option may be specified more than once; if so, Git will report
 commits reachable from any of the given commits.
 +
@@ -73,29 +69,6 @@ See also the `fetch.negotiationAlgorithm` and `push.negotiate`
 configuration variables documented in linkgit:git-config[1], and the
 `--negotiate-only` option below.
 
-`--negotiation-require=<revision>`::
-	Ensure that the given ref tip is always sent as a "have" line
-	during fetch negotiation, regardless of what the negotiation
-	algorithm selects.  This is useful to guarantee that common
-	history reachable from specific refs is always considered, even
-	when `--negotiation-restrict` restricts the set of tips or when
-	the negotiation algorithm would otherwise skip them.
-+
-This option may be specified more than once; if so, each ref is sent
-unconditionally.
-+
-The argument may be an exact ref name (e.g. `refs/heads/release`) or a
-glob pattern (e.g. `refs/heads/release/{asterisk}`).  The pattern syntax
-is the same as for `--negotiation-restrict`.
-+
-If `--negotiation-restrict` is used, the have set is first restricted by
-that option and then increased to include the tips specified by
-`--negotiation-require`.
-+
-If this option is not specified on the command line, then any
-`remote.<name>.negotiationRequire` config values for the current remote
-are used instead.
-
 `--negotiate-only`::
 	Do not fetch anything from the server, and instead print the
 	ancestors of the provided `--negotiation-tip=` arguments,

Documentation/git-cat-file.adoc

@@ -174,11 +174,6 @@ flush::
 	since the beginning or since the last flush was issued. When `--buffer`
 	is used, no output will come until a `flush` is issued. When `--buffer`
 	is not used, commands are flushed each time without issuing `flush`.
-
-`mailmap (<bool>)`::
-	Enable or disable mailmap for subsequent commands. The `<bool>`
-	argument accepts the same boolean values as linkgit:git-config[1].
-	The mailmap data is read upon the first use and only once.
 --
 +
 

Documentation/git-push.adoc

@@ -18,28 +18,17 @@ git push [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n
 
 DESCRIPTION
 -----------
-Updates one or more branches, tags, or other references in one or more
-remote repositories from your local repository, and sends all necessary
-data that isn't already on the remote.
+
+Updates one or more branches, tags, or other references in a remote
+repository from your local repository, and sends all necessary data
+that isn't already on the remote.
 
 The simplest way to push is `git push <remote> <branch>`.
 `git push origin main` will push the local `main` branch to the `main`
 branch on the remote named `origin`.
 
-You can also push to multiple remotes at once by using a remote group.
-A remote group is a named list of remotes configured via `remotes.<name>`
-in your git config:
-
-	$ git config remotes.all-remotes "origin gitlab backup"
-
-Then `git push all-remotes` will push to `origin`, `gitlab`, and
-`backup` in turn, as if you had run `git push` against each one
-individually.  Each remote is pushed independently using its own
-push mapping configuration. There is a `remotes.<group>` entry in
-the configuration file. (See linkgit:git-config[1]).
-
-The `<repository>` argument defaults to the upstream for the current
-branch, or `origin` if there's no configured upstream.
+The `<repository>` argument defaults to the upstream for the current branch,
+or `origin` if there's no configured upstream.
 
 To decide which branches, tags, or other refs to push, Git uses
 (in order of precedence):
@@ -66,10 +55,8 @@ OPTIONS
 _<repository>_::
 	The "remote" repository that is the destination of a push
 	operation.  This parameter can be either a URL
-	(see the section <<URLS,GIT URLS>> below), the name
-	of a remote (see the section <<REMOTES,REMOTES>> below),
-	or the name of a remote group
-	(see the section <<REMOTE-GROUPS,REMOTE GROUPS>> below).
+	(see the section <<URLS,GIT URLS>> below) or the name
+	of a remote (see the section <<REMOTES,REMOTES>> below).
 
 `<refspec>...`::
 	Specify what destination ref to update with what source object.
@@ -443,50 +430,6 @@ further recursion will occur. In this case, `only` is treated as `on-demand`.
 
 include::urls-remotes.adoc[]
 
-[[REMOTE-GROUPS]]
-REMOTE GROUPS
--------------
-
-A remote group is a named list of remotes configured via `remotes.<name>`
-in your git config:
-
-	$ git config remotes.all-remotes "r1 r2 r3"
-
-When a group name is given as the `<repository>` argument, the push is
-performed to each member remote in turn.  The defining principle is:
-
-	git push <options> all-remotes <args>
-
-is exactly equivalent to:
-
-	git push <options> r1 <args>
-	git push <options> r2 <args>
-	...
-	git push <options> rN <args>
-
-where r1, r2, ..., rN are the members of `all-remotes`.  No special
-behaviour is added or removed — the group is purely a shorthand for
-running the same push command against each member remote individually.
-
-The behaviour upon failure depends on the kind of error encountered:
-
-If a member remote rejects the push, for example due to a
-non-fast-forward update, force needed but not given, an existing tag,
-or a server-side hook refusing a ref, Git reports the error and continues
-pushing to the remaining remotes in the group. The overall exit code is
-non-zero if any member push fails.
-
-If a member remote cannot be contacted at all, for example because the
-repository does not exist, authentication fails, or the network is
-unreachable, the push stops at that point and the remaining remotes
-are not attempted.
-
-This means the user is responsible for ensuring that the sequence of
-individual pushes makes sense. If `git push r1`` would fail for a given
-set of options and arguments, then `git push all-remotes` will fail in
-the same way when it reaches r1. The group push does not do anything
-special to make a failing individual push succeed.
-
 OUTPUT
 ------
 

Documentation/git-repack.adoc

@@ -45,8 +45,8 @@ other objects in that pack they already have locally.
 +
 Promisor packfiles are repacked separately: if there are packfiles that
 have an associated ".promisor" file, these packfiles will be repacked
-into another separate pack, and a ".promisor" file corresponding to the
-new separate pack will be written (with arbitrary contents).
+into another separate pack, and an empty ".promisor" file corresponding
+to the new separate pack will be written.
 
 -A::
 	Same as `-a`, unless `-d` is used.  Then any unreachable

Makefile

@@ -1100,7 +1100,6 @@ LIB_OBJS += archive-tar.o
 LIB_OBJS += archive-zip.o
 LIB_OBJS += archive.o
 LIB_OBJS += attr.o
-LIB_OBJS += autocorrect.o
 LIB_OBJS += base85.o
 LIB_OBJS += bisect.o
 LIB_OBJS += blame.o