Git 2.30.9

Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

.gitattributes

@@ -6,7 +6,6 @@
 *.pm eol=lf diff=perl
 *.py eol=lf diff=python
 *.bat eol=crlf
-CODE_OF_CONDUCT.md -whitespace
 /Documentation/**/*.txt eol=lf
 /command-list.txt eol=lf
 /GIT-VERSION-GEN eol=lf

.github/workflows/main.yml

@@ -186,11 +186,6 @@ jobs:
         ## Unzip and remove the artifact
         unzip artifacts.zip
         rm artifacts.zip
-    - name: initialize vcpkg
-      uses: actions/checkout@v2
-      with:
-        repository: 'microsoft/vcpkg'
-        path: 'compat/vcbuild/vcpkg'
     - name: download vcpkg artifacts
       shell: powershell
       run: |
@@ -287,14 +282,14 @@ jobs:
             pool: ubuntu-latest
           - jobname: linux-gcc
             cc: gcc
-            pool: ubuntu-latest
+            pool: ubuntu-20.04
           - jobname: osx-clang
             cc: clang
             pool: macos-latest
           - jobname: osx-gcc
             cc: gcc
             pool: macos-latest
-          - jobname: linux-gcc-default
+          - jobname: GETTEXT_POISON
             cc: gcc
             pool: ubuntu-latest
     env:
@@ -345,7 +340,7 @@ jobs:
     if: needs.ci-config.outputs.enabled == 'yes'
     env:
       jobname: StaticAnalysis
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-22.04
     steps:
     - uses: actions/checkout@v1
     - run: ci/install-dependencies.sh

.gitignore

@@ -33,7 +33,6 @@
 /git-check-mailmap
 /git-check-ref-format
 /git-checkout
-/git-checkout--worker
 /git-checkout-index
 /git-cherry
 /git-cherry-pick
@@ -163,7 +162,6 @@
 /git-stripspace
 /git-submodule
 /git-submodule--helper
-/git-subtree
 /git-svn
 /git-switch
 /git-symbolic-ref

.mailmap

@@ -220,7 +220,6 @@ Philipp A. Hartmann <pah@qo.cx> <ph@sorgh.de>
 Philippe Bruhat <book@cpan.org>
 Ralf Thielow <ralf.thielow@gmail.com> <ralf.thielow@googlemail.com>
 Ramsay Jones <ramsay@ramsayjones.plus.com> <ramsay@ramsay1.demon.co.uk>
-Ramkumar Ramachandra <r@artagnon.com> <artagnon@gmail.com>
 Randall S. Becker <randall.becker@nexbridge.ca> <rsbecker@nexbridge.com>
 René Scharfe <l.s.r@web.de> <rene.scharfe@lsrfire.ath.cx>
 René Scharfe <l.s.r@web.de> Rene Scharfe

.travis.yml

@@ -16,7 +16,7 @@ compiler:
 
 matrix:
   include:
-    - env: jobname=linux-gcc-default
+    - env: jobname=GETTEXT_POISON
       os: linux
       compiler:
       addons:

CODE_OF_CONDUCT.md

@@ -8,64 +8,73 @@ this code of conduct may be banned from the community.
 
 ## Our Pledge
 
-We as members, contributors, and leaders pledge to make participation in our
+In the interest of fostering an open and welcoming environment, we as
-community a harassment-free experience for everyone, regardless of age, body
+contributors and maintainers pledge to make participation in our project and
-size, visible or invisible disability, ethnicity, sex characteristics, gender
+our community a harassment-free experience for everyone, regardless of age,
-identity and expression, level of experience, education, socio-economic status,
+body size, disability, ethnicity, sex characteristics, gender identity and
-nationality, personal appearance, race, religion, or sexual identity
+expression, level of experience, education, socio-economic status,
-and orientation.
+nationality, personal appearance, race, religion, or sexual identity and
-
+orientation.
-We pledge to act and interact in ways that contribute to an open, welcoming,
-diverse, inclusive, and healthy community.
 
 ## Our Standards
 
-Examples of behavior that contributes to a positive environment for our
+Examples of behavior that contributes to creating a positive environment
-community include:
+include:
 
-* Demonstrating empathy and kindness toward other people
+* Using welcoming and inclusive language
-* Being respectful of differing opinions, viewpoints, and experiences
+* Being respectful of differing viewpoints and experiences
-* Giving and gracefully accepting constructive feedback
+* Gracefully accepting constructive criticism
-* Accepting responsibility and apologizing to those affected by our mistakes,
+* Focusing on what is best for the community
-  and learning from the experience
+* Showing empathy towards other community members
-* Focusing on what is best not just for us as individuals, but for the
-  overall community
 
-Examples of unacceptable behavior include:
+Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery, and sexual attention or
+* The use of sexualized language or imagery and unwelcome sexual attention or
-  advances of any kind
+  advances
-* Trolling, insulting or derogatory comments, and personal or political attacks
+* Trolling, insulting/derogatory comments, and personal or political attacks
 * Public or private harassment
-* Publishing others' private information, such as a physical or email
+* Publishing others' private information, such as a physical or electronic
-  address, without their explicit permission
+  address, without explicit permission
 * Other conduct which could reasonably be considered inappropriate in a
   professional setting
 
-## Enforcement Responsibilities
+## Our Responsibilities
 
-Community leaders are responsible for clarifying and enforcing our standards of
+Project maintainers are responsible for clarifying the standards of acceptable
-acceptable behavior and will take appropriate and fair corrective action in
+behavior and are expected to take appropriate and fair corrective action in
-response to any behavior that they deem inappropriate, threatening, offensive,
+response to any instances of unacceptable behavior.
-or harmful.
 
-Community leaders have the right and responsibility to remove, edit, or reject
+Project maintainers have the right and responsibility to remove, edit, or
-comments, commits, code, wiki edits, issues, and other contributions that are
+reject comments, commits, code, wiki edits, issues, and other contributions
-not aligned to this Code of Conduct, and will communicate reasons for moderation
+that are not aligned to this Code of Conduct, or to ban temporarily or
-decisions when appropriate.
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
 
 ## Scope
 
-This Code of Conduct applies within all community spaces, and also applies when
+This Code of Conduct applies within all project spaces, and it also applies
-an individual is officially representing the community in public spaces.
+when an individual is representing the project or its community in public
-Examples of representing our community include using an official e-mail address,
+spaces. Examples of representing a project or community include using an
-posting via an official social media account, or acting as an appointed
+official project e-mail address, posting via an official social media account,
-representative at an online or offline event.
+or acting as an appointed representative at an online or offline event.
+Representation of a project may be further defined and clarified by project
+maintainers.
 
 ## Enforcement
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported to the community leaders responsible for enforcement at
+reported by contacting the project team at git@sfconservancy.org. All
+complaints will be reviewed and investigated and will result in a response
+that is deemed necessary and appropriate to the circumstances. The project
+team is obligated to maintain confidentiality with regard to the reporter of
+an incident. Further details of specific enforcement policies may be posted
+separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+The project leadership team can be contacted by email as a whole at
 git@sfconservancy.org, or individually:
 
   - Ævar Arnfjörð Bjarmason <avarab@gmail.com>
@@ -73,73 +82,12 @@ git@sfconservancy.org, or individually:
   - Jeff King <peff@peff.net>
   - Junio C Hamano <gitster@pobox.com>
 
-All complaints will be reviewed and investigated promptly and fairly.
-
-All community leaders are obligated to respect the privacy and security of the
-reporter of any incident.
-
-## Enforcement Guidelines
-
-Community leaders will follow these Community Impact Guidelines in determining
-the consequences for any action they deem in violation of this Code of Conduct:
-
-### 1. Correction
-
-**Community Impact**: Use of inappropriate language or other behavior deemed
-unprofessional or unwelcome in the community.
-
-**Consequence**: A private, written warning from community leaders, providing
-clarity around the nature of the violation and an explanation of why the
-behavior was inappropriate. A public apology may be requested.
-
-### 2. Warning
-
-**Community Impact**: A violation through a single incident or series
-of actions.
-
-**Consequence**: A warning with consequences for continued behavior. No
-interaction with the people involved, including unsolicited interaction with
-those enforcing the Code of Conduct, for a specified period of time. This
-includes avoiding interactions in community spaces as well as external channels
-like social media. Violating these terms may lead to a temporary or
-permanent ban.
-
-### 3. Temporary Ban
-
-**Community Impact**: A serious violation of community standards, including
-sustained inappropriate behavior.
-
-**Consequence**: A temporary ban from any sort of interaction or public
-communication with the community for a specified period of time. No public or
-private interaction with the people involved, including unsolicited interaction
-with those enforcing the Code of Conduct, is allowed during this period.
-Violating these terms may lead to a permanent ban.
-
-### 4. Permanent Ban
-
-**Community Impact**: Demonstrating a pattern of violation of community
-standards, including sustained inappropriate behavior,  harassment of an
-individual, or aggression toward or disparagement of classes of individuals.
-
-**Consequence**: A permanent ban from any sort of public interaction within
-the community.
-
 ## Attribution
 
 This Code of Conduct is adapted from the [Contributor Covenant][homepage],
-version 2.0, available at
+version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
-[https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0].
-
-Community Impact Guidelines were inspired by 
-[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
-
-For answers to common questions about this code of conduct, see the FAQ at
-[https://www.contributor-covenant.org/faq][FAQ]. Translations are available 
-at [https://www.contributor-covenant.org/translations][translations].
 
 [homepage]: https://www.contributor-covenant.org
-[v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html
-[Mozilla CoC]: https://github.com/mozilla/diversity
-[FAQ]: https://www.contributor-covenant.org/faq
-[translations]: https://www.contributor-covenant.org/translations
 
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

Documentation/CodingGuidelines

@@ -175,11 +175,6 @@ For shell scripts specifically (not exhaustive):
 
    does not have such a problem.
 
- - Even though "local" is not part of POSIX, we make heavy use of it
-   in our test suite.  We do not use it in scripted Porcelains, and
-   hopefully nobody starts using "local" before they are reimplemented
-   in C ;-)
-
 
 For C programs:
 
@@ -503,12 +498,7 @@ Error Messages
 
  - Do not end error messages with a full stop.
 
- - Do not capitalize the first word, only because it is the first word
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
-   in the message ("unable to open %s", not "Unable to open %s").  But
-   "SHA-3 not supported" is fine, because the reason the first word is
-   capitalized is not because it is at the beginning of the sentence,
-   but because the word would be spelled in capital letters even when
-   it appeared in the middle of the sentence.
 
  - Say what the error is first ("cannot open %s", not "%s: cannot open")
 

Documentation/Makefile

@@ -2,8 +2,6 @@
 MAN1_TXT =
 MAN5_TXT =
 MAN7_TXT =
-HOWTO_TXT =
-DOC_DEP_TXT =
 TECH_DOCS =
 ARTICLES =
 SP_ARTICLES =
@@ -23,7 +21,6 @@ MAN1_TXT += gitweb.txt
 MAN5_TXT += gitattributes.txt
 MAN5_TXT += githooks.txt
 MAN5_TXT += gitignore.txt
-MAN5_TXT += gitmailmap.txt
 MAN5_TXT += gitmodules.txt
 MAN5_TXT += gitrepository-layout.txt
 MAN5_TXT += gitweb.conf.txt
@@ -44,11 +41,6 @@ MAN7_TXT += gittutorial-2.txt
 MAN7_TXT += gittutorial.txt
 MAN7_TXT += gitworkflows.txt
 
-HOWTO_TXT += $(wildcard howto/*.txt)
-
-DOC_DEP_TXT += $(wildcard *.txt)
-DOC_DEP_TXT += $(wildcard config/*.txt)
-
 ifdef MAN_FILTER
 MAN_TXT = $(filter $(MAN_FILTER),$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT))
 else
@@ -83,7 +75,6 @@ SP_ARTICLES += howto/rebuild-from-update-hook
 SP_ARTICLES += howto/rebase-from-internal-branch
 SP_ARTICLES += howto/keep-canonical-history-correct
 SP_ARTICLES += howto/maintain-git
-SP_ARTICLES += howto/coordinate-embargoed-releases
 API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
 SP_ARTICLES += $(API_DOCS)
 
@@ -98,7 +89,6 @@ TECH_DOCS += technical/multi-pack-index
 TECH_DOCS += technical/pack-format
 TECH_DOCS += technical/pack-heuristics
 TECH_DOCS += technical/pack-protocol
-TECH_DOCS += technical/parallel-checkout
 TECH_DOCS += technical/partial-clone
 TECH_DOCS += technical/protocol-capabilities
 TECH_DOCS += technical/protocol-common
@@ -293,7 +283,7 @@ docdep_prereqs = \
 	mergetools-list.made $(mergetools_txt) \
 	cmd-list.made $(cmds_txt)
 
-doc.dep : $(docdep_prereqs) $(DOC_DEP_TXT) build-docdep.perl
+doc.dep : $(docdep_prereqs) $(wildcard *.txt) $(wildcard config/*.txt) build-docdep.perl
 	$(QUIET_GEN)$(RM) $@+ $@ && \
 	$(PERL_PATH) ./build-docdep.perl >$@+ $(QUIET_STDERR) && \
 	mv $@+ $@
@@ -436,9 +426,9 @@ $(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
 	$(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+ && \
 	mv $@+ $@
 
-howto-index.txt: howto-index.sh $(HOWTO_TXT)
+howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
 	$(QUIET_GEN)$(RM) $@+ $@ && \
-	'$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(HOWTO_TXT)) >$@+ && \
+	'$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(wildcard howto/*.txt)) >$@+ && \
 	mv $@+ $@
 
 $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
@@ -447,7 +437,7 @@ $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
 WEBDOC_DEST = /pub/software/scm/git/docs
 
 howto/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../
-$(patsubst %.txt,%.html,$(HOWTO_TXT)): %.html : %.txt GIT-ASCIIDOCFLAGS
+$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt GIT-ASCIIDOCFLAGS
 	$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
 	sed -e '1,/^$$/d' $< | \
 	$(TXT_TO_HTML) - >$@+ && \
@@ -479,13 +469,7 @@ print-man1:
 	@for i in $(MAN1_TXT); do echo $$i; done
 
 lint-docs::
-	$(QUIET_LINT)$(PERL_PATH) lint-gitlink.perl \
+	$(QUIET_LINT)$(PERL_PATH) lint-gitlink.perl
-		$(HOWTO_TXT) $(DOC_DEP_TXT) \
-		--section=1 $(MAN1_TXT) \
-		--section=5 $(MAN5_TXT) \
-		--section=7 $(MAN7_TXT); \
-	$(PERL_PATH) lint-man-end-blurb.perl $(MAN_TXT); \
-	$(PERL_PATH) lint-man-section-order.perl $(MAN_TXT);
 
 ifeq ($(wildcard po/Makefile),po/Makefile)
 doc-l10n install-l10n::

Documentation/MyFirstContribution.txt

@@ -664,7 +664,7 @@ mention the right animal somewhere:
 ----
 test_expect_success 'runs correctly with no args and good output' '
 	git psuh >actual &&
-	grep Pony actual
+	test_i18ngrep Pony actual
 '
 ----
 

Documentation/RelNotes/2.30.3.txt

@@ -0,0 +1,24 @@
+Git v2.30.2 Release Notes
+=========================
+
+This release addresses the security issue CVE-2022-24765.
+
+Fixes since v2.30.2
+-------------------
+
+ * Build fix on Windows.
+
+ * Fix `GIT_CEILING_DIRECTORIES` with Windows-style root directories.
+
+ * CVE-2022-24765:
+   On multi-user machines, Git users might find themselves
+   unexpectedly in a Git worktree, e.g. when another user created a
+   repository in `C:\.git`, in a mounted network drive or in a
+   scratch space. Merely having a Git-aware prompt that runs `git
+   status` (or `git diff`) and navigating to a directory which is
+   supposedly not a Git worktree, or opening such a directory in an
+   editor or IDE such as VS Code or Atom, will potentially run
+   commands defined by that other user.
+
+Credit for finding this vulnerability goes to 俞晨东; The fix was
+authored by Johannes Schindelin.

Documentation/RelNotes/2.30.4.txt

@@ -0,0 +1,21 @@
+Git v2.30.4 Release Notes
+=========================
+
+This release contains minor fix-ups for the changes that went into
+Git 2.30.3, which was made to address CVE-2022-24765.
+
+ * The code that was meant to parse the new `safe.directory`
+   configuration variable was not checking what configuration
+   variable was being fed to it, which has been corrected.
+
+ * '*' can be used as the value for the `safe.directory` variable to
+   signal that the user considers that any directory is safe.
+
+
+
+Derrick Stolee (2):
+      t0033: add tests for safe.directory
+      setup: opt-out of check with safe.directory=*
+
+Matheus Valadares (1):
+      setup: fix safe.directory key not being checked

Documentation/RelNotes/2.30.5.txt

@@ -0,0 +1,12 @@
+Git v2.30.5 Release Notes
+=========================
+
+This release contains minor fix-ups for the changes that went into
+Git 2.30.3 and 2.30.4, addressing CVE-2022-29187.
+
+ * The safety check that verifies a safe ownership of the Git
+   worktree is now extended to also cover the ownership of the Git
+   directory (and the `.git` file, if there is any).
+
+Carlo Marcelo Arenas Belón (1):
+      setup: tighten ownership checks post CVE-2022-24765

Documentation/RelNotes/2.30.6.txt

@@ -0,0 +1,60 @@
+Git v2.30.6 Release Notes
+=========================
+
+This release addresses the security issues CVE-2022-39253 and
+CVE-2022-39260.
+
+Fixes since v2.30.5
+-------------------
+
+ * CVE-2022-39253:
+   When relying on the `--local` clone optimization, Git dereferences
+   symbolic links in the source repository before creating hardlinks
+   (or copies) of the dereferenced link in the destination repository.
+   This can lead to surprising behavior where arbitrary files are
+   present in a repository's `$GIT_DIR` when cloning from a malicious
+   repository.
+
+   Git will no longer dereference symbolic links via the `--local`
+   clone mechanism, and will instead refuse to clone repositories that
+   have symbolic links present in the `$GIT_DIR/objects` directory.
+
+   Additionally, the value of `protocol.file.allow` is changed to be
+   "user" by default.
+
+ * CVE-2022-39260:
+   An overly-long command string given to `git shell` can result in
+   overflow in `split_cmdline()`, leading to arbitrary heap writes and
+   remote code execution when `git shell` is exposed and the directory
+   `$HOME/git-shell-commands` exists.
+
+   `git shell` is taught to refuse interactive commands that are
+   longer than 4MiB in size. `split_cmdline()` is hardened to reject
+   inputs larger than 2GiB.
+
+Credit for finding CVE-2022-39253 goes to Cory Snider of Mirantis. The
+fix was authored by Taylor Blau, with help from Johannes Schindelin.
+
+Credit for finding CVE-2022-39260 goes to Kevin Backhouse of GitHub.
+The fix was authored by Kevin Backhouse, Jeff King, and Taylor Blau.
+
+
+Jeff King (2):
+      shell: add basic tests
+      shell: limit size of interactive commands
+
+Kevin Backhouse (1):
+      alias.c: reject too-long cmdline strings in split_cmdline()
+
+Taylor Blau (11):
+      builtin/clone.c: disallow `--local` clones with symlinks
+      t/lib-submodule-update.sh: allow local submodules
+      t/t1NNN: allow local submodules
+      t/2NNNN: allow local submodules
+      t/t3NNN: allow local submodules
+      t/t4NNN: allow local submodules
+      t/t5NNN: allow local submodules
+      t/t6NNN: allow local submodules
+      t/t7NNN: allow local submodules
+      t/t9NNN: allow local submodules
+      transport: make `protocol.file.allow` be "user" by default

Documentation/RelNotes/2.30.7.txt

@@ -0,0 +1,86 @@
+Git v2.30.7 Release Notes
+=========================
+
+This release addresses the security issues CVE-2022-41903 and
+CVE-2022-23521.
+
+
+Fixes since v2.30.6
+-------------------
+
+ * CVE-2022-41903:
+
+   git log has the ability to display commits using an arbitrary
+   format with its --format specifiers. This functionality is also
+   exposed to git archive via the export-subst gitattribute.
+
+   When processing the padding operators (e.g., %<(, %<|(, %>(,
+   %>>(, or %><( ), an integer overflow can occur in
+   pretty.c::format_and_pad_commit() where a size_t is improperly
+   stored as an int, and then added as an offset to a subsequent
+   memcpy() call.
+
+   This overflow can be triggered directly by a user running a
+   command which invokes the commit formatting machinery (e.g., git
+   log --format=...). It may also be triggered indirectly through
+   git archive via the export-subst mechanism, which expands format
+   specifiers inside of files within the repository during a git
+   archive.
+
+   This integer overflow can result in arbitrary heap writes, which
+   may result in remote code execution.
+
+* CVE-2022-23521:
+
+    gitattributes are a mechanism to allow defining attributes for
+    paths. These attributes can be defined by adding a `.gitattributes`
+    file to the repository, which contains a set of file patterns and
+    the attributes that should be set for paths matching this pattern.
+
+    When parsing gitattributes, multiple integer overflows can occur
+    when there is a huge number of path patterns, a huge number of
+    attributes for a single pattern, or when the declared attribute
+    names are huge.
+
+    These overflows can be triggered via a crafted `.gitattributes` file
+    that may be part of the commit history. Git silently splits lines
+    longer than 2KB when parsing gitattributes from a file, but not when
+    parsing them from the index. Consequentially, the failure mode
+    depends on whether the file exists in the working tree, the index or
+    both.
+
+    This integer overflow can result in arbitrary heap reads and writes,
+    which may result in remote code execution.
+
+Credit for finding CVE-2022-41903 goes to Joern Schneeweisz of GitLab.
+An initial fix was authored by Markus Vervier of X41 D-Sec. Credit for
+finding CVE-2022-23521 goes to Markus Vervier and Eric Sesterhenn of X41
+D-Sec. This work was sponsored by OSTIF.
+
+The proposed fixes have been polished and extended to cover additional
+findings by Patrick Steinhardt of GitLab, with help from others on the
+Git security mailing list.
+
+Patrick Steinhardt (21):
+      attr: fix overflow when upserting attribute with overly long name
+      attr: fix out-of-bounds read with huge attribute names
+      attr: fix integer overflow when parsing huge attribute names
+      attr: fix out-of-bounds write when parsing huge number of attributes
+      attr: fix out-of-bounds read with unreasonable amount of patterns
+      attr: fix integer overflow with more than INT_MAX macros
+      attr: harden allocation against integer overflows
+      attr: fix silently splitting up lines longer than 2048 bytes
+      attr: ignore attribute lines exceeding 2048 bytes
+      attr: ignore overly large gitattributes files
+      pretty: fix out-of-bounds write caused by integer overflow
+      pretty: fix out-of-bounds read when left-flushing with stealing
+      pretty: fix out-of-bounds read when parsing invalid padding format
+      pretty: fix adding linefeed when placeholder is not expanded
+      pretty: fix integer overflow in wrapping format
+      utf8: fix truncated string lengths in `utf8_strnwidth()`
+      utf8: fix returning negative string width
+      utf8: fix overflow when returning string width
+      utf8: fix checking for glyph width in `strbuf_utf8_replace()`
+      utf8: refactor `strbuf_utf8_replace` to not rely on preallocated buffer
+      pretty: restrict input lengths for padding and wrapping formats
+

Documentation/RelNotes/2.30.8.txt

@@ -0,0 +1,52 @@
+Git v2.30.8 Release Notes
+=========================
+
+This release addresses the security issues CVE-2023-22490 and
+CVE-2023-23946.
+
+
+Fixes since v2.30.7
+-------------------
+
+ * CVE-2023-22490:
+
+   Using a specially-crafted repository, Git can be tricked into using
+   its local clone optimization even when using a non-local transport.
+   Though Git will abort local clones whose source $GIT_DIR/objects
+   directory contains symbolic links (c.f., CVE-2022-39253), the objects
+   directory itself may still be a symbolic link.
+
+   These two may be combined to include arbitrary files based on known
+   paths on the victim's filesystem within the malicious repository's
+   working copy, allowing for data exfiltration in a similar manner as
+   CVE-2022-39253.
+
+ * CVE-2023-23946:
+
+   By feeding a crafted input to "git apply", a path outside the
+   working tree can be overwritten as the user who is running "git
+   apply".
+
+ * A mismatched type in `attr.c::read_attr_from_index()` which could
+   cause Git to errantly reject attributes on Windows and 32-bit Linux
+   has been corrected.
+
+Credit for finding CVE-2023-22490 goes to yvvdwf, and the fix was
+developed by Taylor Blau, with additional help from others on the
+Git security mailing list.
+
+Credit for finding CVE-2023-23946 goes to Joern Schneeweisz, and the
+fix was developed by Patrick Steinhardt.
+
+
+Johannes Schindelin (1):
+      attr: adjust a mismatched data type
+
+Patrick Steinhardt (1):
+      apply: fix writing behind newly created symbolic links
+
+Taylor Blau (3):
+      t5619: demonstrate clone_local() with ambiguous transport
+      clone: delay picking a transport until after get_repo_path()
+      dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS
+

Documentation/RelNotes/2.30.9.txt

@@ -0,0 +1,43 @@
+Git v2.30.9 Release Notes
+=========================
+
+This release addresses the security issues CVE-2023-25652,
+CVE-2023-25815, and CVE-2023-29007.
+
+
+Fixes since v2.30.8
+-------------------
+
+ * CVE-2023-25652:
+
+   By feeding specially crafted input to `git apply --reject`, a
+   path outside the working tree can be overwritten with partially
+   controlled contents (corresponding to the rejected hunk(s) from
+   the given patch).
+
+ * CVE-2023-25815:
+
+   When Git is compiled with runtime prefix support and runs without
+   translated messages, it still used the gettext machinery to
+   display messages, which subsequently potentially looked for
+   translated messages in unexpected places. This allowed for
+   malicious placement of crafted messages.
+
+ * CVE-2023-29007:
+
+   When renaming or deleting a section from a configuration file,
+   certain malicious configuration values may be misinterpreted as
+   the beginning of a new configuration section, leading to arbitrary
+   configuration injection.
+
+Credit for finding CVE-2023-25652 goes to Ry0taK, and the fix was
+developed by Taylor Blau, Junio C Hamano and Johannes Schindelin,
+with the help of Linus Torvalds.
+
+Credit for finding CVE-2023-25815 goes to Maxime Escourbiac and
+Yassine BENGANA of Michelin, and the fix was developed by Johannes
+Schindelin.
+
+Credit for finding CVE-2023-29007 goes to André Baptista and Vítor Pinho
+of Ethiack, and the fix was developed by Taylor Blau, and Johannes
+Schindelin, with help from Jeff King, and Patrick Steinhardt.

Documentation/RelNotes/2.31.0.txt

@@ -1,365 +0,0 @@
-Git 2.31 Release Notes
-======================
-
-Updates since v2.30
--------------------
-
-Backward incompatible and other important changes
-
- * The "pack-redundant" command, which has been left stale with almost
-   unusable performance issues, now warns loudly when it gets used, as
-   we no longer want to recommend its use (instead just "repack -d"
-   instead).
-
- * The development community has adopted Contributor Covenant v2.0 to
-   update from v1.4 that we have been using.
-
- * The support for deprecated PCRE1 library has been dropped.
-
- * Fixes for CVE-2021-21300 in Git 2.30.2 (and earlier) is included.
-
-
-UI, Workflows & Features
-
- * The "--format=%(trailers)" mechanism gets enhanced to make it
-   easier to design output for machine consumption.
-
- * When a user does not tell "git pull" to use rebase or merge, the
-   command gives a loud message telling a user to choose between
-   rebase or merge but creates a merge anyway, forcing users who would
-   want to rebase to redo the operation.  Fix an early part of this
-   problem by tightening the condition to give the message---there is
-   no reason to stop or force the user to choose between rebase or
-   merge if the history fast-forwards.
-
- * The configuration variable 'core.abbrev' can be set to 'no' to
-   force no abbreviation regardless of the hash algorithm.
-
- * "git rev-parse" can be explicitly told to give output as absolute
-   or relative path with the `--path-format=(absolute|relative)` option.
-
- * Bash completion (in contrib/) update to make it easier for
-   end-users to add completion for their custom "git" subcommands.
-
- * "git maintenance" learned to drive scheduled maintenance on
-   platforms whose native scheduling methods are not 'cron'.
-
- * After expiring a reflog and making a single commit, the reflog for
-   the branch would record a single entry that knows both @{0} and
-   @{1}, but we failed to answer "what commit were we on?", i.e. @{1}
-
- * "git bundle" learns "--stdin" option to read its refs from the
-   standard input.  Also, it now does not lose refs whey they point
-   at the same object.
-
- * "git log" learned a new "--diff-merges=<how>" option.
-
- * "git ls-files" can and does show multiple entries when the index is
-   unmerged, which is a source for confusion unless -s/-u option is in
-   use.  A new option --deduplicate has been introduced.
-
- * `git worktree list` now annotates worktrees as prunable, shows
-   locked and prunable attributes in --porcelain mode, and gained
-   a --verbose option.
-
- * "git clone" tries to locally check out the branch pointed at by
-   HEAD of the remote repository after it is done, but the protocol
-   did not convey the information necessary to do so when copying an
-   empty repository.  The protocol v2 learned how to do so.
-
- * There are other ways than ".." for a single token to denote a
-   "commit range", namely "<rev>^!" and "<rev>^-<n>", but "git
-   range-diff" did not understand them.
-
- * The "git range-diff" command learned "--(left|right)-only" option
-   to show only one side of the compared range.
-
- * "git mergetool" feeds three versions (base, local and remote) of
-   a conflicted path unmodified.  The command learned to optionally
-   prepare these files with unconflicted parts already resolved.
-
- * The .mailmap is documented to be read only from the root level of a
-   working tree, but a stray file in a bare repository also was read
-   by accident, which has been corrected.
-
- * "git maintenance" tool learned a new "pack-refs" maintenance task.
-
- * The error message given when a configuration variable that is
-   expected to have a boolean value has been improved.
-
- * Signed commits and tags now allow verification of objects, whose
-   two object names (one in SHA-1, the other in SHA-256) are both
-   signed.
-
- * "git rev-list" command learned "--disk-usage" option.
-
- * "git {diff,log} --{skip,rotate}-to=<path>" allows the user to
-   discard diff output for early paths or move them to the end of the
-   output.
-
- * "git difftool" learned "--skip-to=<path>" option to restart an
-   interrupted session from an arbitrary path.
-
- * "git grep" has been tweaked to be limited to the sparse checkout
-   paths.
-
- * "git rebase --[no-]fork-point" gained a configuration variable
-   rebase.forkPoint so that users do not have to keep specifying a
-   non-default setting.
-
-
-Performance, Internal Implementation, Development Support etc.
-
- * A 3-year old test that was not testing anything useful has been
-   corrected.
-
- * Retire more names with "sha1" in it.
-
- * The topological walk codepath is covered by new trace2 stats.
-
- * Update the Code-of-conduct to version 2.0 from the upstream (we've
-   been using version 1.4).
-
- * "git mktag" validates its input using its own rules before writing
-   a tag object---it has been updated to share the logic with "git
-   fsck".
-
- * Two new ways to feed configuration variable-value pairs via
-   environment variables have been introduced, and the way
-   GIT_CONFIG_PARAMETERS encodes variable/value pairs has been tweaked
-   to make it more robust.
-
- * Tests have been updated so that they do not to get affected by the
-   name of the default branch "git init" creates.
-
- * "git fetch" learns to treat ref updates atomically in all-or-none
-   fashion, just like "git push" does, with the new "--atomic" option.
-
- * The peel_ref() API has been replaced with peel_iterated_oid().
-
- * The .use_shell flag in struct child_process that is passed to
-   run_command() API has been clarified with a bit more documentation.
-
- * Document, clean-up and optimize the code around the cache-tree
-   extension in the index.
-
- * The ls-refs protocol operation has been optimized to narrow the
-   sub-hierarchy of refs/ it walks to produce response.
-
- * When removing many branches and tags, the code used to do so one
-   ref at a time.  There is another API it can use to delete multiple
-   refs, and it makes quite a lot of performance difference when the
-   refs are packed.
-
- * The "pack-objects" command needs to iterate over all the tags when
-   automatic tag following is enabled, but it actually iterated over
-   all refs and then discarded everything outside "refs/tags/"
-   hierarchy, which was quite wasteful.
-
- * A perf script was made more portable.
-
- * Our setting of GitHub CI test jobs were a bit too eager to give up
-   once there is even one failure found.  Tweak the knob to allow
-   other jobs keep running even when we see a failure, so that we can
-   find more failures in a single run.
-
- * We've carried compatibility codepaths for compilers without
-   variadic macros for quite some time, but the world may be ready for
-   them to be removed.  Force compilation failure on exotic platforms
-   where variadic macros are not available to find out who screams in
-   such a way that we can easily revert if it turns out that the world
-   is not yet ready.
-
- * Code clean-up to ensure our use of hashtables using object names as
-   keys use the "struct object_id" objects, not the raw hash values.
-
- * Lose the debugging aid that may have been useful in the past, but
-   no longer is, in the "grep" codepaths.
-
- * Some pretty-format specifiers do not need the data in commit object
-   (e.g. "%H"), but we were over-eager to load and parse it, which has
-   been made even lazier.
-
- * Get rid of "GETTEXT_POISON" support altogether, which may or may
-   not be controversial.
-
- * Introduce an on-disk file to record revindex for packdata, which
-   traditionally was always created on the fly and only in-core.
-
- * The commit-graph learned to use corrected commit dates instead of
-   the generation number to help topological revision traversal.
-
- * Piecemeal of rewrite of "git bisect" in C continues.
-
- * When a pager spawned by us exited, the trace log did not record its
-   exit status correctly, which has been corrected.
-
- * Removal of GIT_TEST_GETTEXT_POISON continues.
-
- * The code to implement "git merge-base --independent" was poorly
-   done and was kept from the very beginning of the feature.
-
- * Preliminary changes to fsmonitor integration.
-
- * Performance improvements for rename detection.
-
- * The common code to deal with "chunked file format" that is shared
-   by the multi-pack-index and commit-graph files have been factored
-   out, to help codepaths for both filetypes to become more robust.
-
- * The approach to "fsck" the incoming objects in "index-pack" is
-   attractive for performance reasons (we have them already in core,
-   inflated and ready to be inspected), but fundamentally cannot be
-   applied fully when we receive more than one pack stream, as a tree
-   object in one pack may refer to a blob object in another pack as
-   ".gitmodules", when we want to inspect blobs that are used as
-   ".gitmodules" file, for example.  Teach "index-pack" to emit
-   objects that must be inspected later and check them in the calling
-   "fetch-pack" process.
-
- * The logic to handle "trailer" related placeholders in the
-   "--format=" mechanisms in the "log" family and "for-each-ref"
-   family is getting unified.
-
- * Raise the buffer size used when writing the index file out from
-   (obviously too small) 8kB to (clearly sufficiently large) 128kB.
-
- * It is reported that open() on some platforms (e.g. macOS Big Sur)
-   can return EINTR even though our timers are set up with SA_RESTART.
-   A workaround has been implemented and enabled for macOS to rerun
-   open() transparently from the caller when this happens.
-
-
-Fixes since v2.30
------------------
-
- * Diagnose command line error of "git rebase" early.
-
- * Clean up option descriptions in "git cmd --help".
-
- * "git stash" did not work well in a sparsely checked out working
-   tree.
-
- * Some tests expect that "ls -l" output has either '-' or 'x' for
-   group executable bit, but setgid bit can be inherited from parent
-   directory and make these fields 'S' or 's' instead, causing test
-   failures.
-
- * "git for-each-repo --config=<var> <cmd>" should not run <cmd> for
-   any repository when the configuration variable <var> is not defined
-   even once.
-
- * Fix 2.29 regression where "git mergetool --tool-help" fails to list
-   all the available tools.
-
- * Fix for procedure to building CI test environment for mac.
-
- * The implementation of "git branch --sort" wrt the detached HEAD
-   display has always been hacky, which has been cleaned up.
-
- * Newline characters in the host and path part of git:// URL are
-   now forbidden.
-
- * "git diff" showed a submodule working tree with untracked cruft as
-   "Submodule commit <objectname>-dirty", but a natural expectation is
-   that the "-dirty" indicator would align with "git describe --dirty",
-   which does not consider having untracked files in the working tree
-   as source of dirtiness.  The inconsistency has been fixed.
-
- * When more than one commit with the same patch ID appears on one
-   side, "git log --cherry-pick A...B" did not exclude them all when a
-   commit with the same patch ID appears on the other side.  Now it
-   does.
-
- * Documentation for "git fsck" lost stale bits that has become
-   incorrect.
-
- * Doc fix for packfile URI feature.
-
- * When "git rebase -i" processes "fixup" insn, there is no reason to
-   clean up the commit log message, but we did the usual stripspace
-   processing.  This has been corrected.
-   (merge f7d42ceec5 js/rebase-i-commit-cleanup-fix later to maint).
-
- * Fix in passing custom args from "git clone" to "upload-pack" on the
-   other side.
-   (merge ad6b5fefbd jv/upload-pack-filter-spec-quotefix later to maint).
-
- * The command line completion (in contrib/) completed "git branch -d"
-   with branch names, but "git branch -D" offered tagnames in addition,
-   which has been corrected.  "git branch -M" had the same problem.
-   (merge 27dc071b9a jk/complete-branch-force-delete later to maint).
-
- * When commands are started from a subdirectory, they may have to
-   compare the path to the subdirectory (called prefix and found out
-   from $(pwd)) with the tracked paths.  On macOS, $(pwd) and
-   readdir() yield decomposed path, while the tracked paths are
-   usually normalized to the precomposed form, causing mismatch.  This
-   has been fixed by taking the same approach used to normalize the
-   command line arguments.
-   (merge 5c327502db tb/precompose-prefix-too later to maint).
-
- * Even though invocations of "die()" were logged to the trace2
-   system, "BUG()"s were not, which has been corrected.
-   (merge 0a9dde4a04 jt/trace2-BUG later to maint).
-
- * "git grep --untracked" is meant to be "let's ALSO find in these
-   files on the filesystem" when looking for matches in the working
-   tree files, and does not make any sense if the primary search is
-   done against the index, or the tree objects.  The "--cached" and
-   "--untracked" options have been marked as mutually incompatible.
-   (merge 0c5d83b248 mt/grep-cached-untracked later to maint).
-
- * Fix "git fsck --name-objects" which apparently has not been used by
-   anybody who is motivated enough to report breakage.
-   (merge e89f89361c js/fsck-name-objects-fix later to maint).
-
- * Avoid individual tests in t5411 from getting affected by each other
-   by forcing them to use separate output files during the test.
-   (merge 822ee894f6 jx/t5411-unique-filenames later to maint).
-
- * Test to make sure "git rev-parse one-thing one-thing" gives
-   the same thing twice (when one-thing is --since=X).
-   (merge a5cdca4520 ew/rev-parse-since-test later to maint).
-
- * When certain features (e.g. grafts) used in the repository are
-   incompatible with the use of the commit-graph, we used to silently
-   turned commit-graph off; we now tell the user what we are doing.
-   (merge c85eec7fc3 js/commit-graph-warning later to maint).
-
- * Objects that lost references can be pruned away, even when they
-   have notes attached to it (and these notes will become dangling,
-   which in turn can be pruned with "git notes prune").  This has been
-   clarified in the documentation.
-   (merge fa9ab027ba mz/doc-notes-are-not-anchors later to maint).
-
- * The error codepath around the "--temp/--prefix" feature of "git
-   checkout-index" has been improved.
-   (merge 3f7ba60350 mt/checkout-index-corner-cases later to maint).
-
- * The "git maintenance register" command had trouble registering bare
-   repositories, which had been corrected.
-
- * A handful of multi-word configuration variable names in
-   documentation that are spelled in all lowercase have been corrected
-   to use the more canonical camelCase.
-   (merge 7dd0eaa39c dl/doc-config-camelcase later to maint).
-
- * "git push $there --delete ''" should have been diagnosed as an
-   error, but instead turned into a matching push, which has been
-   corrected.
-   (merge 20e416409f jc/push-delete-nothing later to maint).
-
- * Test script modernization.
-   (merge 488acf15df sv/t7001-modernize later to maint).
-
- * An under-allocation for the untracked cache data has been corrected.
-   (merge 6347d649bc jh/untracked-cache-fix later to maint).
-
- * Other code cleanup, docfix, build fix, etc.
-   (merge e3f5da7e60 sg/t7800-difftool-robustify later to maint).
-   (merge 9d336655ba js/doc-proto-v2-response-end later to maint).
-   (merge 1b5b8cf072 jc/maint-column-doc-typofix later to maint).
-   (merge 3a837b58e3 cw/pack-config-doc later to maint).
-   (merge 01168a9d89 ug/doc-commit-approxidate later to maint).
-   (merge b865734760 js/params-vs-args later to maint).

Documentation/RelNotes/2.31.1.txt

@@ -1,27 +0,0 @@
-Git 2.31.1 Release Notes
-========================
-
-Fixes since v2.31
------------------
-
- * The fsmonitor interface read from its input without making sure
-   there is something to read from.  This bug is new in 2.31
-   timeframe.
-
- * The data structure used by fsmonitor interface was not properly
-   duplicated during an in-core merge, leading to use-after-free etc.
-
- * "git bisect" reimplemented more in C during 2.30 timeframe did not
-   take an annotated tag as a good/bad endpoint well.  This regression
-   has been corrected.
-
- * Fix macros that can silently inject unintended null-statements.
-
- * CALLOC_ARRAY() macro replaces many uses of xcalloc().
-
- * Update insn in Makefile comments to run fuzz-all target.
-
- * Fix a corner case bug in "git mv" on case insensitive systems,
-   which was introduced in 2.29 timeframe.
-
-Also contains various documentation updates and code clean-ups.

Documentation/RelNotes/2.32.0.txt

@@ -1,416 +0,0 @@
-Git 2.32 Release Notes
-======================
-
-Backward compatibility notes
-----------------------------
-
- * ".gitattributes", ".gitignore", and ".mailmap" files that are
-   symbolic links are ignored.
-
- * "git apply --3way" used to first attempt a straight application,
-   and only fell back to the 3-way merge algorithm when the stright
-   application failed.  Starting with this version, the command will
-   first try the 3-way merge algorithm and only when it fails (either
-   resulting with conflict or the base versions of blobs are missing),
-   falls back to the usual patch application.
-
-
-Updates since v2.31
--------------------
-
-UI, Workflows & Features
-
- * It does not make sense to make ".gitattributes", ".gitignore" and
-   ".mailmap" symlinks, as they are supposed to be usable from the
-   object store (think: bare repositories where HEAD:.mailmap etc. are
-   used).  When these files are symbolic links, we used to read the
-   contents of the files pointed by them by mistake, which has been
-   corrected.
-
- * "git stash show" learned to optionally show untracked part of the
-   stash.
-
- * "git log --format='...'" learned "%(describe)" placeholder.
-
- * "git repack" so far has been only capable of repacking everything
-   under the sun into a single pack (or split by size).  A cleverer
-   strategy to reduce the cost of repacking a repository has been
-   introduced.
-
- * The http codepath learned to let the credential layer to cache the
-   password used to unlock a certificate that has successfully been
-   used.
-
- * "git commit --fixup=<commit>", which was to tweak the changes made
-   to the contents while keeping the original log message intact,
-   learned "--fixup=(amend|reword):<commit>", that can be used to
-   tweak both the message and the contents, and only the message,
-   respectively.
-
- * "git send-email" learned to honor the core.hooksPath configuration.
-
- * "git format-patch -v<n>" learned to allow a reroll count that is
-   not an integer.
-
- * "git commit" learned "--trailer <key>[=<value>]" option; together
-   with the interpret-trailers command, this will make it easier to
-   support custom trailers.
-
- * "git clone --reject-shallow" option fails the clone as soon as we
-   notice that we are cloning from a shallow repository.
-
- * A configuration variable has been added to force tips of certain
-   refs to be given a reachability bitmap.
-
- * "gitweb" learned "e-mail privacy" feature to redact strings that
-   look like e-mail addresses on various pages.
-
- * "git apply --3way" has always been "to fall back to 3-way merge
-   only when straight application fails". Swap the order of falling
-   back so that 3-way is always attempted first (only when the option
-   is given, of course) and then straight patch application is used as
-   a fallback when it fails.
-
- * "git apply" now takes "--3way" and "--cached" at the same time, and
-   work and record results only in the index.
-
- * The command line completion (in contrib/) has learned that
-   CHERRY_PICK_HEAD is a possible pseudo-ref.
-
- * Userdiff patterns for "Scheme" has been added.
-
- * "git log" learned "--diff-merges=<style>" option, with an
-   associated configuration variable log.diffMerges.
-
- * "git log --format=..." placeholders learned %ah/%ch placeholders to
-   request the --date=human output.
-
- * Replace GIT_CONFIG_NOSYSTEM mechanism to decline from reading the
-   system-wide configuration file with GIT_CONFIG_SYSTEM that lets
-   users specify from which file to read the system-wide configuration
-   (setting it to an empty file would essentially be the same as
-   setting NOSYSTEM), and introduce GIT_CONFIG_GLOBAL to override the
-   per-user configuration in $HOME/.gitconfig.
-
- * "git add" and "git rm" learned not to touch those paths that are
-   outside of sparse checkout.
-
- * "git rev-list" learns the "--filter=object:type=<type>" option,
-   which can be used to exclude objects of the given kind from the
-   packfile generated by pack-objects.
-
- * The command line completion (in contrib/) for "git stash" has been
-   updated.
-
- * "git subtree" updates.
-
- * It is now documented that "format-patch" skips merges.
-
- * Options to "git pack-objects" that take numeric values like
-   --window and --depth should not accept negative values; the input
-   validation has been tightened.
-
- * The way the command line specified by the trailer.<token>.command
-   configuration variable receives the end-user supplied value was
-   both error prone and misleading.  An alternative to achieve the
-   same goal in a safer and more intuitive way has been added, as
-   the trailer.<token>.cmd configuration variable, to replace it.
-
- * "git add -i --dry-run" does not dry-run, which was surprising.  The
-   combination of options has taught to error out.
-
- * "git push" learns to discover common ancestor with the receiving
-   end over protocol v2.  This will hopefully make "git push" as
-   efficient as "git fetch" in avoiding objects from getting
-   transferred unnecessarily.
-
- * "git mailinfo" (hence "git am") learned the "--quoted-cr" option to
-   control how lines ending with CRLF wrapped in base64 or qp are
-   handled.
-
-
-Performance, Internal Implementation, Development Support etc.
-
- * Rename detection rework continues.
-
- * GIT_TEST_FAIL_PREREQS is a mechanism to skip test pieces with
-   prerequisites to catch broken tests that depend on the side effects
-   of optional pieces, but did not work at all when negative
-   prerequisites were involved.
-   (merge 27d578d904 jk/fail-prereq-testfix later to maint).
-
- * "git diff-index" codepath has been taught to trust fsmonitor status
-   to reduce number of lstat() calls.
-   (merge 7e5aa13d2c nk/diff-index-fsmonitor later to maint).
-
- * Reorganize Makefile to allow building git.o and other essential
-   objects without extra stuff needed only for testing.
-
- * Preparatory API changes for parallel checkout.
-
- * A simple IPC interface gets introduced to build services like
-   fsmonitor on top.
-
- * Fsck API clean-up.
-
- * SECURITY.md that is facing individual contributors and end users
-   has been introduced.  Also a procedure to follow when preparing
-   embargoed releases has been spelled out.
-   (merge 09420b7648 js/security-md later to maint).
-
- * Optimize "rev-list --use-bitmap-index --objects" corner case that
-   uses negative tags as the stopping points.
-
- * CMake update for vsbuild.
-
- * An on-disk reverse-index to map the in-pack location of an object
-   back to its object name across multiple packfiles is introduced.
-
- * Generate [ec]tags under $(QUIET_GEN).
-
- * Clean-up codepaths that implements "git send-email --validate"
-   option and improves the message from it.
-
- * The last remnant of gettext-poison has been removed.
-
- * The test framework has been taught to optionally turn the default
-   merge strategy to "ort" throughout the system where we use
-   three-way merges internally, like cherry-pick, rebase etc.,
-   primarily to enhance its test coverage (the strategy has been
-   available as an explicit "-s ort" choice).
-
- * A bit of code clean-up and a lot of test clean-up around userdiff
-   area.
-
- * Handling of "promisor packs" that allows certain objects to be
-   missing and lazily retrievable has been optimized (a bit).
-
- * When packet_write() fails, we gave an extra error message
-   unnecessarily, which has been corrected.
-
- * The checkout machinery has been taught to perform the actual
-   write-out of the files in parallel when able.
-
- * Show errno in the trace output in the error codepath that calls
-   read_raw_ref method.
-
- * Effort to make the command line completion (in contrib/) safe with
-   "set -u" continues.
-
- * Tweak a few tests for "log --format=..." that show timestamps in
-   various formats.
-
- * The reflog expiry machinery has been taught to emit trace events.
-
- * Over-the-wire protocol learns a new request type to ask for object
-   sizes given a list of object names.
-
-
-Fixes since v2.31
------------------
-
- * The fsmonitor interface read from its input without making sure
-   there is something to read from.  This bug is new in 2.31
-   timeframe.
-
- * The data structure used by fsmonitor interface was not properly
-   duplicated during an in-core merge, leading to use-after-free etc.
-
- * "git bisect" reimplemented more in C during 2.30 timeframe did not
-   take an annotated tag as a good/bad endpoint well.  This regression
-   has been corrected.
-
- * Fix macros that can silently inject unintended null-statements.
-
- * CALLOC_ARRAY() macro replaces many uses of xcalloc().
-
- * Update insn in Makefile comments to run fuzz-all target.
-
- * Fix a corner case bug in "git mv" on case insensitive systems,
-   which was introduced in 2.29 timeframe.
-
- * We had a code to diagnose and die cleanly when a required
-   clean/smudge filter is missing, but an assert before that
-   unnecessarily fired, hiding the end-user facing die() message.
-   (merge 6fab35f748 mt/cleanly-die-upon-missing-required-filter later to maint).
-
- * Update C code that sets a few configuration variables when a remote
-   is configured so that it spells configuration variable names in the
-   canonical camelCase.
-   (merge 0f1da600e6 ab/remote-write-config-in-camel-case later to maint).
-
- * A new configuration variable has been introduced to allow choosing
-   which version of the generation number gets used in the
-   commit-graph file.
-   (merge 702110aac6 ds/commit-graph-generation-config later to maint).
-
- * Perf test update to work better in secondary worktrees.
-   (merge 36e834abc1 jk/perf-in-worktrees later to maint).
-
- * Updates to memory allocation code around the use of pcre2 library.
-   (merge c1760352e0 ab/grep-pcre2-allocfix later to maint).
-
- * "git -c core.bare=false clone --bare ..." would have segfaulted,
-   which has been corrected.
-   (merge 75555676ad bc/clone-bare-with-conflicting-config later to maint).
-
- * When "git checkout" removes a path that does not exist in the
-   commit it is checking out, it wasn't careful enough not to follow
-   symbolic links, which has been corrected.
-   (merge fab78a0c3d mt/checkout-remove-nofollow later to maint).
-
- * A few option description strings started with capital letters,
-   which were corrected.
-   (merge 5ee90326dc cc/downcase-opt-help later to maint).
-
- * Plug or annotate remaining leaks that trigger while running the
-   very basic set of tests.
-   (merge 68ffe095a2 ah/plugleaks later to maint).
-
- * The hashwrite() API uses a buffering mechanism to avoid calling
-   write(2) too frequently. This logic has been refactored to be
-   easier to understand.
-   (merge ddaf1f62e3 ds/clarify-hashwrite later to maint).
-
- * "git cherry-pick/revert" with or without "--[no-]edit" did not spawn
-   the editor as expected (e.g. "revert --no-edit" after a conflict
-   still asked to edit the message), which has been corrected.
-   (merge 39edfd5cbc en/sequencer-edit-upon-conflict-fix later to maint).
-
- * "git daemon" has been tightened against systems that take backslash
-   as directory separator.
-   (merge 9a7f1ce8b7 rs/daemon-sanitize-dir-sep later to maint).
-
- * A NULL-dereference bug has been corrected in an error codepath in
-   "git for-each-ref", "git branch --list" etc.
-   (merge c685450880 jk/ref-filter-segfault-fix later to maint).
-
- * Streamline the codepath to fix the UTF-8 encoding issues in the
-   argv[] and the prefix on macOS.
-   (merge c7d0e61016 tb/precompose-prefix-simplify later to maint).
-
- * The command-line completion script (in contrib/) had a couple of
-   references that would have given a warning under the "-u" (nounset)
-   option.
-   (merge c5c0548d79 vs/completion-with-set-u later to maint).
-
- * When "git pack-objects" makes a literal copy of a part of existing
-   packfile using the reachability bitmaps, its update to the progress
-   meter was broken.
-   (merge 8e118e8490 jk/pack-objects-bitmap-progress-fix later to maint).
-
- * The dependencies for config-list.h and command-list.h were broken
-   when the former was split out of the latter, which has been
-   corrected.
-   (merge 56550ea718 sg/bugreport-fixes later to maint).
-
- * "git push --quiet --set-upstream" was not quiet when setting the
-   upstream branch configuration, which has been corrected.
-   (merge f3cce896a8 ow/push-quiet-set-upstream later to maint).
-
- * The prefetch task in "git maintenance" assumed that "git fetch"
-   from any remote would fetch all its local branches, which would
-   fetch too much if the user is interested in only a subset of
-   branches there.
-   (merge 32f67888d8 ds/maintenance-prefetch-fix later to maint).
-
- * Clarify that pathnames recorded in Git trees are most often (but
-   not necessarily) encoded in UTF-8.
-   (merge 9364bf465d ab/pathname-encoding-doc later to maint).
-
- * "git --config-env var=val cmd" weren't accepted (only
-   --config-env=var=val was).
-   (merge c331551ccf ps/config-env-option-with-separate-value later to maint).
-
- * When the reachability bitmap is in effect, the "do not lose
-   recently created objects and those that are reachable from them"
-   safety to protect us from races were disabled by mistake, which has
-   been corrected.
-   (merge 2ba582ba4c jk/prune-with-bitmap-fix later to maint).
-
- * Cygwin pathname handling fix.
-   (merge bccc37fdc7 ad/cygwin-no-backslashes-in-paths later to maint).
-
- * "git rebase --[no-]reschedule-failed-exec" did not work well with
-   its configuration variable, which has been corrected.
-   (merge e5b32bffd1 ab/rebase-no-reschedule-failed-exec later to maint).
-
- * Portability fix for command line completion script (in contrib/).
-   (merge f2acf763e2 si/zsh-complete-comment-fix later to maint).
-
- * "git repack -A -d" in a partial clone unnecessarily loosened
-   objects in promisor pack.
-
- * "git bisect skip" when custom words are used for new/old did not
-   work, which has been corrected.
-
- * A few variants of informational message "Already up-to-date" has
-   been rephrased.
-   (merge ad9322da03 js/merge-already-up-to-date-message-reword later to maint).
-
- * "git submodule update --quiet" did not propagate the quiet option
-   down to underlying "git fetch", which has been corrected.
-   (merge 62af4bdd42 nc/submodule-update-quiet later to maint).
-
- * Document that our test can use "local" keyword.
-   (merge a84fd3bcc6 jc/test-allows-local later to maint).
-
- * The word-diff mode has been taught to work better with a word
-   regexp that can match an empty string.
-   (merge 0324e8fc6b pw/word-diff-zero-width-matches later to maint).
-
- * "git p4" learned to find branch points more efficiently.
-   (merge 6b79818bfb jk/p4-locate-branch-point-optim later to maint).
-
- * When "git update-ref -d" removes a ref that is packed, it left
-   empty directories under $GIT_DIR/refs/ for
-   (merge 5f03e5126d wc/packed-ref-removal-cleanup later to maint).
-
- * "git clean" and "git ls-files -i" had confusion around working on
-   or showing ignored paths inside an ignored directory, which has
-   been corrected.
-   (merge b548f0f156 en/dir-traversal later to maint).
-
- * The handling of "%(push)" formatting element of "for-each-ref" and
-   friends was broken when the same codepath started handling
-   "%(push:<what>)", which has been corrected.
-   (merge 1e1c4c5eac zh/ref-filter-push-remote-fix later to maint).
-
- * The bash prompt script (in contrib/) did not work under "set -u".
-   (merge 5c0cbdb107 en/prompt-under-set-u later to maint).
-
- * The "chainlint" feature in the test framework is a handy way to
-   catch common mistakes in writing new tests, but tends to get
-   expensive.  An knob to selectively disable it has been introduced
-   to help running tests that the developer has not modified.
-   (merge 2d86a96220 jk/test-chainlint-softer later to maint).
-
- * The "rev-parse" command did not diagnose the lack of argument to
-   "--path-format" option, which was introduced in v2.31 era, which
-   has been corrected.
-   (merge 99fc555188 wm/rev-parse-path-format-wo-arg later to maint).
-
- * Other code cleanup, docfix, build fix, etc.
-   (merge f451960708 dl/cat-file-doc-cleanup later to maint).
-   (merge 12604a8d0c sv/t9801-test-path-is-file-cleanup later to maint).
-   (merge ea7e63921c jr/doc-ignore-typofix later to maint).
-   (merge 23c781f173 ps/update-ref-trans-hook-doc later to maint).
-   (merge 42efa1231a jk/filter-branch-sha256 later to maint).
-   (merge 4c8e3dca6e tb/push-simple-uses-branch-merge-config later to maint).
-   (merge 6534d436a2 bs/asciidoctor-installation-hints later to maint).
-   (merge 47957485b3 ab/read-tree later to maint).
-   (merge 2be927f3d1 ab/diff-no-index-tests later to maint).
-   (merge 76593c09bb ab/detox-gettext-tests later to maint).
-   (merge 28e29ee38b jc/doc-format-patch-clarify later to maint).
-   (merge fc12b6fdde fm/user-manual-use-preface later to maint).
-   (merge dba94e3a85 cc/test-helper-bloom-usage-fix later to maint).
-   (merge 61a7660516 hn/reftable-tables-doc-update later to maint).
-   (merge 81ed96a9b2 jt/fetch-pack-request-fix later to maint).
-   (merge 151b6c2dd7 jc/doc-do-not-capitalize-clarification later to maint).
-   (merge 9160068ac6 js/access-nul-emulation-on-windows later to maint).
-   (merge 7a14acdbe6 po/diff-patch-doc later to maint).
-   (merge f91371b948 pw/patience-diff-clean-up later to maint).
-   (merge 3a7f0908b6 mt/clean-clean later to maint).
-   (merge d4e2d15a8b ab/streaming-simplify later to maint).
-   (merge 0e59f7ad67 ah/merge-ort-i18n later to maint).
-   (merge e6f68f62e0 ls/typofix later to maint).

Documentation/SubmittingPatches

@@ -117,13 +117,10 @@ If in doubt which identifier to use, run `git log --no-merges` on the
 files you are modifying to see the current conventions.
 
 [[summary-section]]
-The title sentence after the "area:" prefix omits the full stop at the
+It's customary to start the remainder of the first line after "area: "
-end, and its first word is not capitalized unless there is a reason to
+with a lower-case letter. E.g. "doc: clarify...", not "doc:
-capitalize it other than because it is the first word in the sentence.
+Clarify...", or "githooks.txt: improve...", not "githooks.txt:
-E.g. "doc: clarify...", not "doc: Clarify...", or "githooks.txt:
+Improve...".
-improve...", not "githooks.txt: Improve...".  But "refs: HEAD is also
-treated as a ref" is correct, as we spell `HEAD` in all caps even when
-it appears in the middle of a sentence.
 
 [[meaningful-message]]
 The body should provide a meaningful commit message, which:

Documentation/blame-options.txt

@@ -1,6 +1,6 @@
 -b::
 	Show blank SHA-1 for boundary commits.  This can also
-	be controlled via the `blame.blankBoundary` config option.
+	be controlled via the `blame.blankboundary` config option.
 
 --root::
 	Do not treat root commits as boundaries.  This can also be

Documentation/config.txt

@@ -46,7 +46,7 @@ Subsection names are case sensitive and can contain any characters except
 newline and the null byte. Doublequote `"` and backslash can be included
 by escaping them as `\"` and `\\`, respectively. Backslashes preceding
 other characters are dropped when reading; for example, `\t` is read as
-`t` and `\0` is read as `0`. Section headers cannot span multiple lines.
+`t` and `\0` is read as `0` Section headers cannot span multiple lines.
 Variables may belong directly to a section or to a given subsection. You
 can have `[section]` if you have `[section "subsection"]`, but you don't
 need to.
@@ -398,8 +398,6 @@ include::config/interactive.txt[]
 
 include::config/log.txt[]
 
-include::config/lsrefs.txt[]
-
 include::config/mailinfo.txt[]
 
 include::config/mailmap.txt[]
@@ -440,6 +438,8 @@ include::config/rerere.txt[]
 
 include::config/reset.txt[]
 
+include::config/safe.txt[]
+
 include::config/sendemail.txt[]
 
 include::config/sequencer.txt[]

Documentation/config/advice.txt

@@ -119,8 +119,4 @@ advice.*::
 	addEmptyPathspec::
 		Advice shown if a user runs the add command without providing
 		the pathspec parameter.
-	updateSparsePath::
-		Advice shown when either linkgit:git-add[1] or linkgit:git-rm[1]
-		is asked to update index entries outside the current sparse
-		checkout.
 --

Documentation/config/checkout.txt

@@ -21,24 +21,3 @@ checkout.guess::
 	Provides the default value for the `--guess` or `--no-guess`
 	option in `git checkout` and `git switch`. See
 	linkgit:git-switch[1] and linkgit:git-checkout[1].
-
-checkout.workers::
-	The number of parallel workers to use when updating the working tree.
-	The default is one, i.e. sequential execution. If set to a value less
-	than one, Git will use as many workers as the number of logical cores
-	available. This setting and `checkout.thresholdForParallelism` affect
-	all commands that perform checkout. E.g. checkout, clone, reset,
-	sparse-checkout, etc.
-+
-Note: parallel checkout usually delivers better performance for repositories
-located on SSDs or over NFS. For repositories on spinning disks and/or machines
-with a small number of cores, the default sequential checkout often performs
-better. The size and compression level of a repository might also influence how
-well the parallel version performs.
-
-checkout.thresholdForParallelism::
-	When running parallel checkout with a small number of files, the cost
-	of subprocess spawning and inter-process communication might outweigh
-	the parallelization gains. This setting allows to define the minimum
-	number of files for which parallel checkout should be attempted. The
-	default is 100.

Documentation/config/clone.txt

@@ -2,7 +2,3 @@ clone.defaultRemoteName::
 	The name of the remote to create when cloning a repository.  Defaults to
 	`origin`, and can be overridden by passing the `--origin` command-line
 	option to linkgit:git-clone[1].
-
-clone.rejectShallow::
-	Reject to clone a repository if it is a shallow one, can be overridden by
-	passing option `--reject-shallow` in command line. See linkgit:git-clone[1]

Documentation/config/commitgraph.txt

@@ -1,9 +1,3 @@
-commitGraph.generationVersion::
-	Specifies the type of generation number version to use when writing
-	or reading the commit-graph file. If version 1 is specified, then
-	the corrected commit dates will not be written or read. Defaults to
-	2.
-
 commitGraph.maxNewFilters::
 	Specifies the default value for the `--max-new-filters` option of `git
 	commit-graph write` (c.f., linkgit:git-commit-graph[1]).

Documentation/config/core.txt

@@ -625,6 +625,4 @@ core.abbrev::
 	computed based on the approximate number of packed objects
 	in your repository, which hopefully is enough for
 	abbreviated object names to stay unique for some time.
-	If set to "no", no abbreviation is made and the object names
-	are shown in their full length.
 	The minimum length is 4.

Documentation/config/diff.txt

@@ -85,8 +85,6 @@ diff.ignoreSubmodules::
 	and 'git status' when `status.submoduleSummary` is set unless it is
 	overridden by using the --ignore-submodules command-line option.
 	The 'git submodule' commands are not affected by this setting.
-	By default this is set to untracked so that any untracked
-	submodules are ignored.
 
 diff.mnemonicPrefix::
 	If set, 'git diff' uses a prefix pair that is different from the

Documentation/config/index.txt

@@ -14,11 +14,6 @@ index.recordOffsetTable::
 	Defaults to 'true' if index.threads has been explicitly enabled,
 	'false' otherwise.
 
-index.sparse::
-	When enabled, write the index using sparse-directory entries. This
-	has no effect unless `core.sparseCheckout` and
-	`core.sparseCheckoutCone` are both enabled. Defaults to 'false'.
-
 index.threads::
 	Specifies the number of threads to spawn when loading the index.
 	This is meant to reduce index load time on multiprocessor machines.

Documentation/config/init.txt

@@ -4,4 +4,4 @@ init.templateDir::
 
 init.defaultBranch::
 	Allows overriding the default branch name e.g. when initializing
-	a new repository.
+	a new repository or when cloning an empty repository.

Documentation/config/log.txt

@@ -24,11 +24,6 @@ log.excludeDecoration::
 	the config option can be overridden by the `--decorate-refs`
 	option.
 
-log.diffMerges::
-	Set default diff format to be used for merge commits. See
-	`--diff-merges` in linkgit:git-log[1] for details.
-	Defaults to `separate`.
-
 log.follow::
 	If `true`, `git log` will act as if the `--follow` option was used when
 	a single <path> is given.  This has the same limitations as `--follow`,

Documentation/config/lsrefs.txt

@@ -1,9 +0,0 @@
-lsrefs.unborn::
-	May be "advertise" (the default), "allow", or "ignore". If "advertise",
-	the server will respond to the client sending "unborn" (as described in
-	protocol-v2.txt) and will advertise support for this feature during the
-	protocol v2 capability advertisement. "allow" is the same as
-	"advertise" except that the server will not advertise support for this
-	feature; this is useful for load-balanced servers that cannot be
-	updated atomically (for example), since the administrator could
-	configure "allow", then after a delay, configure "advertise".

Documentation/config/maintenance.txt

@@ -15,9 +15,8 @@ maintenance.strategy::
 * `none`: This default setting implies no task are run at any schedule.
 * `incremental`: This setting optimizes for performing small maintenance
   activities that do not delete any data. This does not schedule the `gc`
-  task, but runs the `prefetch` and `commit-graph` tasks hourly, the
+  task, but runs the `prefetch` and `commit-graph` tasks hourly and the
-  `loose-objects` and `incremental-repack` tasks daily, and the `pack-refs`
+  `loose-objects` and `incremental-repack` tasks daily.
-  task weekly.
 
 maintenance.<task>.enabled::
 	This boolean config option controls whether the maintenance task

Documentation/config/mergetool.txt

@@ -13,11 +13,6 @@ mergetool.<tool>.cmd::
 	merged; 'MERGED' contains the name of the file to which the merge
 	tool should write the results of a successful merge.
 
-mergetool.<tool>.hideResolved::
-	Allows the user to override the global `mergetool.hideResolved` value
-	for a specific tool. See `mergetool.hideResolved` for the full
-	description.
-
 mergetool.<tool>.trustExitCode::
 	For a custom merge command, specify whether the exit code of
 	the merge command can be used to determine whether the merge was
@@ -45,16 +40,6 @@ mergetool.meld.useAutoMerge::
 	value of `false` avoids using `--auto-merge` altogether, and is the
 	default value.
 
-mergetool.hideResolved::
-	During a merge Git will automatically resolve as many conflicts as
-	possible and write the 'MERGED' file containing conflict markers around
-	any conflicts that it cannot resolve; 'LOCAL' and 'REMOTE' normally
-	represent the versions of the file from before Git's conflict
-	resolution. This flag causes 'LOCAL' and 'REMOTE' to be overwriten so
-	that only the unresolved conflicts are presented to the merge tool. Can
-	be configured per-tool via the `mergetool.<tool>.hideResolved`
-	configuration variable. Defaults to `false`.
-
 mergetool.keepBackup::
 	After performing a merge, the original file with conflict markers
 	can be saved as a file with a `.orig` extension.  If this variable

Documentation/config/pack.txt

@@ -122,21 +122,6 @@ pack.useSparse::
 	commits contain certain types of direct renames. Default is
 	`true`.
 
-pack.preferBitmapTips::
-	When selecting which commits will receive bitmaps, prefer a
-	commit at the tip of any reference that is a suffix of any value
-	of this configuration over any other commits in the "selection
-	window".
-+
-Note that setting this configuration to `refs/foo` does not mean that
-the commits at the tips of `refs/foo/bar` and `refs/foo/baz` will
-necessarily be selected. This is because commits are selected for
-bitmaps from within a series of windows of variable length.
-+
-If a commit at the tip of any reference which is a suffix of any value
-of this configuration is seen in a window, it is immediately given
-preference over any other commit in that window.
-
 pack.writeBitmaps (deprecated)::
 	This is a deprecated synonym for `repack.writeBitmaps`.
 
@@ -148,10 +133,3 @@ pack.writeBitmapHashCache::
 	between an older, bitmapped pack and objects that have been
 	pushed since the last gc). The downside is that it consumes 4
 	bytes per object of disk space. Defaults to true.
-
-pack.writeReverseIndex::
-	When true, git will write a corresponding .rev file (see:
-	link:../technical/pack-format.html[Documentation/technical/pack-format.txt])
-	for each new packfile that it writes in all places except for
-	linkgit:git-fast-import[1] and in the bulk checkin mechanism.
-	Defaults to false.

Documentation/config/protocol.txt

@@ -1,10 +1,10 @@
 protocol.allow::
 	If set, provide a user defined default policy for all protocols which
 	don't explicitly have a policy (`protocol.<name>.allow`).  By default,
-	if unset, known-safe protocols (http, https, git, ssh, file) have a
+	if unset, known-safe protocols (http, https, git, ssh) have a
 	default policy of `always`, known-dangerous protocols (ext) have a
-	default policy of `never`, and all other protocols have a default
+	default policy of `never`, and all other protocols (including file)
-	policy of `user`.  Supported policies:
+	have a default policy of `user`.  Supported policies:
 +
 --
 

Documentation/config/push.txt

@@ -120,10 +120,3 @@ push.useForceIfIncludes::
 	`--force-if-includes` as an option to linkgit:git-push[1]
 	in the command line. Adding `--no-force-if-includes` at the
 	time of push overrides this configuration setting.
-
-push.negotiate::
-	If set to "true", attempt to reduce the size of the packfile
-	sent by rounds of negotiation in which the client and the
-	server attempt to find commits in common. If "false", Git will
-	rely solely on the server's ref advertisement to find commits
-	in common.

Documentation/config/rebase.txt

@@ -1,3 +1,10 @@
+rebase.useBuiltin::
+	Unused configuration variable. Used in Git versions 2.20 and
+	2.21 as an escape hatch to enable the legacy shellscript
+	implementation of rebase. Now the built-in rewrite of it in C
+	is always used. Setting this will emit a warning, to alert any
+	remaining users that setting this now does nothing.
+
 rebase.backend::
 	Default backend to use for rebasing.  Possible choices are
 	'apply' or 'merge'.  In the future, if the merge backend gains
@@ -61,6 +68,3 @@ rebase.rescheduleFailedExec::
 	Automatically reschedule `exec` commands that failed. This only makes
 	sense in interactive mode (or when an `--exec` option was provided).
 	This is the same as specifying the `--reschedule-failed-exec` option.
-
-rebase.forkPoint::
-	If set to false set `--no-fork-point` option by default.

Documentation/config/safe.txt

@@ -0,0 +1,42 @@
+safe.directory::
+	These config entries specify Git-tracked directories that are
+	considered safe even if they are owned by someone other than the
+	current user. By default, Git will refuse to even parse a Git
+	config of a repository owned by someone else, let alone run its
+	hooks, and this config setting allows users to specify exceptions,
+	e.g. for intentionally shared repositories (see the `--shared`
+	option in linkgit:git-init[1]).
++
+This is a multi-valued setting, i.e. you can add more than one directory
+via `git config --add`. To reset the list of safe directories (e.g. to
+override any such directories specified in the system config), add a
+`safe.directory` entry with an empty value.
++
+This config setting is only respected when specified in a system or global
+config, not when it is specified in a repository config or via the command
+line option `-c safe.directory=<path>`.
++
+The value of this setting is interpolated, i.e. `~/<path>` expands to a
+path relative to the home directory and `%(prefix)/<path>` expands to a
+path relative to Git's (runtime) prefix.
++
+To completely opt-out of this security check, set `safe.directory` to the
+string `*`. This will allow all repositories to be treated as if their
+directory was listed in the `safe.directory` list. If `safe.directory=*`
+is set in system config and you want to re-enable this protection, then
+initialize your list with an empty value before listing the repositories
+that you deem safe.
++
+As explained, Git only allows you to access repositories owned by
+yourself, i.e. the user who is running Git, by default.  When Git
+is running as 'root' in a non Windows platform that provides sudo,
+however, git checks the SUDO_UID environment variable that sudo creates
+and will allow access to the uid recorded as its value in addition to
+the id from 'root'.
+This is to make it easy to perform a common sequence during installation
+"make && sudo make install".  A git process running under 'sudo' runs as
+'root' but the 'sudo' command exports the environment variable to record
+which id the original user has.
+If that is not what you would prefer and want git to only trust
+repositories that are owned by root instead, then you can remove
+the `SUDO_UID` variable from root's environment before invoking git.

Documentation/config/stash.txt

@@ -5,11 +5,6 @@ stash.useBuiltin::
 	is always used. Setting this will emit a warning, to alert any
 	remaining users that setting this now does nothing.
 
-stash.showIncludeUntracked::
-	If this is set to true, the `git stash show` command will show
-	the untracked files of a stash entry.  Defaults to false. See
-	description of 'show' command in linkgit:git-stash[1].
-
 stash.showPatch::
 	If this is set to true, the `git stash show` command without an
 	option will show the stash entry in patch form.  Defaults to false.

Documentation/config/uploadpack.txt

@@ -59,16 +59,15 @@ uploadpack.allowFilter::
 
 uploadpackfilter.allow::
 	Provides a default value for unspecified object filters (see: the
-	below configuration variable). If set to `true`, this will also
+	below configuration variable).
-	enable all filters which get added in the future.
 	Defaults to `true`.
 
 uploadpackfilter.<filter>.allow::
 	Explicitly allow or ban the object filter corresponding to
 	`<filter>`, where `<filter>` may be one of: `blob:none`,
-	`blob:limit`, `object:type`, `tree`, `sparse:oid`, or `combine`.
+	`blob:limit`, `tree`, `sparse:oid`, or `combine`. If using
-	If using combined filters, both `combine` and all of the nested
+	combined filters, both `combine` and all of the nested filter
-	filter kinds must be allowed. Defaults to `uploadpackfilter.allow`.
+	kinds must be allowed. Defaults to `uploadpackfilter.allow`.
 
 uploadpackfilter.tree.maxDepth::
 	Only allow `--filter=tree:<n>` when `<n>` is no more than the value of

Documentation/date-formats.txt

@@ -1,7 +1,10 @@
 DATE FORMATS
 ------------
 
-The `GIT_AUTHOR_DATE` and `GIT_COMMITTER_DATE` environment variables
+The `GIT_AUTHOR_DATE`, `GIT_COMMITTER_DATE` environment variables
+ifdef::git-commit[]
+and the `--date` option
+endif::git-commit[]
 support the following date formats:
 
 Git internal format::
@@ -23,9 +26,3 @@ ISO 8601::
 +
 NOTE: In addition, the date part is accepted in the following formats:
 `YYYY.MM.DD`, `MM/DD/YYYY` and `DD.MM.YYYY`.
-
-ifdef::git-commit[]
-In addition to recognizing all date formats above, the `--date` option
-will also try to make sense of other, more human-centric date formats,
-such as relative dates like "yesterday" or "last Friday at noon".
-endif::git-commit[]

Documentation/diff-generate-patch.txt

@@ -11,7 +11,7 @@ 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
-(see linkgit:git[1]), and the `diff` attribute (see linkgit:gitattributes[5]).
+(see linkgit:git[1]).
 
 What the -p option produces is slightly different from the traditional
 diff format:
@@ -74,11 +74,6 @@ separate lines indicate the old and the new mode.
       rename from b
       rename to a
 
-5.  Hunk headers mention the name of the function to which the hunk
-    applies.  See "Defining a custom hunk-header" in
-    linkgit:gitattributes[5] for details of how to tailor to this to
-    specific languages.
-
 
 Combined diff format
 --------------------
@@ -86,9 +81,9 @@ Combined diff format
 Any diff-generating command can take the `-c` or `--cc` option to
 produce a 'combined diff' when showing a merge. This is the default
 format when showing merges with linkgit:git-diff[1] or
-linkgit:git-show[1]. Note also that you can give suitable
+linkgit:git-show[1]. Note also that you can give the `-m` option to any
-`--diff-merges` option to any of these commands to force generation of
+of these commands to force generation of diffs with individual parents
-diffs in specific format.
+of a merge.
 
 A "combined diff" format looks like this:
 

Documentation/diff-options.txt

@@ -33,64 +33,6 @@ endif::git-diff[]
 	show the patch by default, or to cancel the effect of `--patch`.
 endif::git-format-patch[]
 
-ifdef::git-log[]
---diff-merges=(off|none|on|first-parent|1|separate|m|combined|c|dense-combined|cc)::
---no-diff-merges::
-	Specify diff format to be used for merge commits. Default is
-	{diff-merges-default} unless `--first-parent` is in use, in which case
-	`first-parent` is the default.
-+
---diff-merges=(off|none):::
---no-diff-merges:::
-	Disable output of diffs for merge commits. Useful to override
-	implied value.
-+
---diff-merges=on:::
---diff-merges=m:::
--m:::
-	This option makes diff output for merge commits to be shown in
-	the default format. `-m` will produce the output only if `-p`
-	is given as well. The default format could be changed using
-	`log.diffMerges` configuration parameter, which default value
-	is `separate`.
-+
---diff-merges=first-parent:::
---diff-merges=1:::
-	This option makes merge commits show the full diff with
-	respect to the first parent only.
-+
---diff-merges=separate:::
-	This makes merge commits show the full diff with respect to
-	each of the parents. Separate log entry and diff is generated
-	for each parent.
-+
---diff-merges=combined:::
---diff-merges=c:::
--c:::
-	With this option, diff output for a merge commit shows the
-	differences from each of the parents to the merge result
-	simultaneously instead of showing pairwise diff between a
-	parent and the result one at a time. Furthermore, it lists
-	only files which were modified from all parents. `-c` implies
-	`-p`.
-+
---diff-merges=dense-combined:::
---diff-merges=cc:::
---cc:::
-	With this option the output produced by
-	`--diff-merges=combined` is further compressed by omitting
-	uninteresting hunks whose contents in the parents have only
-	two variants and the merge result picks one of them without
-	modification.  `--cc` implies `-p`.
-
---combined-all-paths::
-	This flag causes combined diffs (used for merge commits) to
-	list the name of the file from all parents.  It thus only has
-	effect when `--diff-merges=[dense-]combined` is in use, and
-	is likely only useful if filename changes are detected (i.e.
-	when either rename or copy detection have been requested).
-endif::git-log[]
-
 -U<n>::
 --unified=<n>::
 	Generate diffs with <n> lines of context instead of
@@ -300,14 +242,11 @@ explained for the configuration variable `core.quotePath` (see
 linkgit:git-config[1]).
 
 --name-only::
-	Show only names of changed files. The file names are often encoded in UTF-8.
+	Show only names of changed files.
-	For more information see the discussion about encoding in the linkgit:git-log[1]
-	manual page.
 
 --name-status::
 	Show only names and status of changed files. See the description
 	of the `--diff-filter` option on what the status letters mean.
-	Just like `--name-only` the file names are often encoded in UTF-8.
 
 --submodule[=<format>]::
 	Specify how differences in submodules are shown.  When specifying
@@ -710,14 +649,6 @@ matches a pattern if removing any number of the final pathname
 components matches the pattern.  For example, the pattern "`foo*bar`"
 matches "`fooasdfbar`" and "`foo/bar/baz/asdf`" but not "`foobarx`".
 
---skip-to=<file>::
---rotate-to=<file>::
-	Discard the files before the named <file> from the output
-	(i.e. 'skip to'), or move them to the end of the output
-	(i.e. 'rotate to').  These were invented primarily for use
-	of the `git difftool` command, and may not be very useful
-	otherwise.
-
 ifndef::git-format-patch[]
 -R::
 	Swap two inputs; that is, show differences from index or

Documentation/fetch-options.txt

@@ -7,10 +7,6 @@
 	existing contents of `.git/FETCH_HEAD`.  Without this
 	option old data in `.git/FETCH_HEAD` will be overwritten.
 
---atomic::
-	Use an atomic transaction to update local refs. Either all refs are
-	updated, or on error, no refs are updated.
-
 --depth=<depth>::
 	Limit fetching to the specified number of commits from the tip of
 	each remote branch history. If fetching to a 'shallow' repository
@@ -110,11 +106,6 @@ ifndef::git-pull[]
 	setting `fetch.writeCommitGraph`.
 endif::git-pull[]
 
---prefetch::
-	Modify the configured refspec to place all refs into the
-	`refs/prefetch/` namespace. See the `prefetch` task in
-	linkgit:git-maintenance[1].
-
 -p::
 --prune::
 	Before fetching, remove any remote-tracking references that no

Documentation/git-am.txt

@@ -15,7 +15,6 @@ SYNOPSIS
 	 [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
 	 [--exclude=<path>] [--include=<path>] [--reject] [-q | --quiet]
 	 [--[no-]scissors] [-S[<keyid>]] [--patch-format=<format>]
-	 [--quoted-cr=<action>]
 	 [(<mbox> | <Maildir>)...]
 'git am' (--continue | --skip | --abort | --quit | --show-current-patch[=(diff|raw)])
 
@@ -60,9 +59,6 @@ OPTIONS
 --no-scissors::
 	Ignore scissors lines (see linkgit:git-mailinfo[1]).
 
---quoted-cr=<action>::
-	This flag will be passed down to 'git mailinfo' (see linkgit:git-mailinfo[1]).
-
 -m::
 --message-id::
 	Pass the `-m` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]),
@@ -83,7 +79,7 @@ OPTIONS
 	Pass `-u` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
 	The proposed commit log message taken from the e-mail
 	is re-coded into UTF-8 encoding (configuration variable
-	`i18n.commitEncoding` can be used to specify project's
+	`i18n.commitencoding` can be used to specify project's
 	preferred encoding if it is not UTF-8).
 +
 This was optional in prior versions of git, but now it is the

Documentation/git-apply.txt

@@ -84,13 +84,12 @@ OPTIONS
 
 -3::
 --3way::
-	Attempt 3-way merge if the patch records the identity of blobs it is supposed
+	When the patch does not apply cleanly, fall back on 3-way merge if
-	to apply to and we have those blobs available locally, possibly leaving the
+	the patch records the identity of blobs it is supposed to apply to,
+	and we have those blobs available locally, possibly leaving the
 	conflict markers in the files in the working tree for the user to
-	resolve.  This option implies the `--index` option unless the
+	resolve.  This option implies the `--index` option, and is incompatible
-	`--cached` option is used, and is incompatible with the `--reject` option.
+	with the `--reject` and the `--cached` options.
-	When used with the `--cached` option, any conflicts are left at higher stages
-	in the cache.
 
 --build-fake-ancestor=<file>::
 	Newer 'git diff' output has embedded 'index information'

Documentation/git-blame.txt

@@ -226,7 +226,7 @@ commit commentary), a blame viewer will not care.
 MAPPING AUTHORS
 ---------------
 
-See linkgit:gitmailmap[5].
+include::mailmap.txt[]
 
 
 SEE ALSO

Documentation/git-branch.txt

@@ -78,8 +78,8 @@ renaming. If <newbranch> exists, -M must be used to force the rename
 to happen.
 
 The `-c` and `-C` options have the exact same semantics as `-m` and
-`-M`, except instead of the branch being renamed, it will be copied to a
+`-M`, except instead of the branch being renamed it along with its
-new name, along with its config and reflog.
+config and reflog will be copied to a new name.
 
 With a `-d` or `-D` option, `<branchname>` will be deleted.  You may
 specify more than one branch for deletion.  If the branch currently
@@ -153,7 +153,7 @@ OPTIONS
 --column[=<options>]::
 --no-column::
 	Display branch listing in columns. See configuration variable
-	`column.branch` for option syntax. `--column` and `--no-column`
+	column.branch for option syntax.`--column` and `--no-column`
 	without options are equivalent to 'always' and 'never' respectively.
 +
 This option is only applicable in non-verbose mode.

Documentation/git-cat-file.txt

@@ -35,42 +35,42 @@ OPTIONS
 
 -t::
 	Instead of the content, show the object type identified by
-	`<object>`.
+	<object>.
 
 -s::
 	Instead of the content, show the object size identified by
-	`<object>`.
+	<object>.
 
 -e::
-	Exit with zero status if `<object>` exists and is a valid
+	Exit with zero status if <object> exists and is a valid
-	object. If `<object>` is of an invalid format exit with non-zero and
+	object. If <object> is of an invalid format exit with non-zero and
 	emits an error on stderr.
 
 -p::
-	Pretty-print the contents of `<object>` based on its type.
+	Pretty-print the contents of <object> based on its type.
 
 <type>::
-	Typically this matches the real type of `<object>` but asking
+	Typically this matches the real type of <object> but asking
 	for a type that can trivially be dereferenced from the given
-	`<object>` is also permitted.  An example is to ask for a
+	<object> is also permitted.  An example is to ask for a
-	"tree" with `<object>` being a commit object that contains it,
+	"tree" with <object> being a commit object that contains it,
-	or to ask for a "blob" with `<object>` being a tag object that
+	or to ask for a "blob" with <object> being a tag object that
 	points at it.
 
 --textconv::
 	Show the content as transformed by a textconv filter. In this case,
-	`<object>` has to be of the form `<tree-ish>:<path>`, or `:<path>` in
+	<object> has to be of the form <tree-ish>:<path>, or :<path> in
 	order to apply the filter to the content recorded in the index at
-	`<path>`.
+	<path>.
 
 --filters::
 	Show the content as converted by the filters configured in
-	the current working tree for the given `<path>` (i.e. smudge filters,
+	the current working tree for the given <path> (i.e. smudge filters,
-	end-of-line conversion, etc). In this case, `<object>` has to be of
+	end-of-line conversion, etc). In this case, <object> has to be of
-	the form `<tree-ish>:<path>`, or `:<path>`.
+	the form <tree-ish>:<path>, or :<path>.
 
 --path=<path>::
-	For use with `--textconv` or `--filters`, to allow specifying an object
+	For use with --textconv or --filters, to allow specifying an object
 	name and a path separately, e.g. when it is difficult to figure out
 	the revision from which the blob came.
 
@@ -115,15 +115,15 @@ OPTIONS
 	repository.
 
 --allow-unknown-type::
-	Allow `-s` or `-t` to query broken/corrupt objects of unknown type.
+	Allow -s or -t to query broken/corrupt objects of unknown type.
 
 --follow-symlinks::
-	With `--batch` or `--batch-check`, follow symlinks inside the
+	With --batch or --batch-check, follow symlinks inside the
 	repository when requesting objects with extended SHA-1
 	expressions of the form tree-ish:path-in-tree.  Instead of
 	providing output about the link itself, provide output about
 	the linked-to object.  If a symlink points outside the
-	tree-ish (e.g. a link to `/foo` or a root-level link to `../foo`),
+	tree-ish (e.g. a link to /foo or a root-level link to ../foo),
 	the portion of the link which is outside the tree will be
 	printed.
 +
@@ -175,15 +175,15 @@ respectively print:
 
 OUTPUT
 ------
-If `-t` is specified, one of the `<type>`.
+If `-t` is specified, one of the <type>.
 
-If `-s` is specified, the size of the `<object>` in bytes.
+If `-s` is specified, the size of the <object> in bytes.
 
-If `-e` is specified, no output, unless the `<object>` is malformed.
+If `-e` is specified, no output, unless the <object> is malformed.
 
-If `-p` is specified, the contents of `<object>` are pretty-printed.
+If `-p` is specified, the contents of <object> are pretty-printed.
 
-If `<type>` is specified, the raw (though uncompressed) contents of the `<object>`
+If <type> is specified, the raw (though uncompressed) contents of the <object>
 will be returned.
 
 BATCH OUTPUT
@@ -200,7 +200,7 @@ object, with placeholders of the form `%(atom)` expanded, followed by a
 newline. The available atoms are:
 
 `objectname`::
-	The full hex representation of the object name.
+	The 40-hex object name of the object.
 
 `objecttype`::
 	The type of the object (the same as `cat-file -t` reports).
@@ -215,9 +215,8 @@ newline. The available atoms are:
 
 `deltabase`::
 	If the object is stored as a delta on-disk, this expands to the
-	full hex representation of the delta base object name.
+	40-hex sha1 of the delta base object. Otherwise, expands to the
-	Otherwise, expands to the null OID (all zeroes). See `CAVEATS`
+	null sha1 (40 zeroes). See `CAVEATS` below.
-	below.
 
 `rest`::
 	If this atom is used in the output string, input lines are split
@@ -236,14 +235,14 @@ newline.
 For example, `--batch` without a custom format would produce:
 
 ------------
-<oid> SP <type> SP <size> LF
+<sha1> SP <type> SP <size> LF
 <contents> LF
 ------------
 
 Whereas `--batch-check='%(objectname) %(objecttype)'` would produce:
 
 ------------
-<oid> SP <type> LF
+<sha1> SP <type> LF
 ------------
 
 If a name is specified on stdin that cannot be resolved to an object in
@@ -259,7 +258,7 @@ If a name is specified that might refer to more than one object (an ambiguous sh
 <object> SP ambiguous LF
 ------------
 
-If `--follow-symlinks` is used, and a symlink in the repository points
+If --follow-symlinks is used, and a symlink in the repository points
 outside the repository, then `cat-file` will ignore any custom format
 and print:
 
@@ -268,11 +267,11 @@ symlink SP <size> LF
 <symlink> LF
 ------------
 
-The symlink will either be absolute (beginning with a `/`), or relative
+The symlink will either be absolute (beginning with a /), or relative
-to the tree root.  For instance, if dir/link points to `../../foo`, then
+to the tree root.  For instance, if dir/link points to ../../foo, then
-`<symlink>` will be `../foo`.  `<size>` is the size of the symlink in bytes.
+<symlink> will be ../foo.  <size> is the size of the symlink in bytes.
 
-If `--follow-symlinks` is used, the following error messages will be
+If --follow-symlinks is used, the following error messages will be
 displayed:
 
 ------------

Documentation/git-check-mailmap.txt

@@ -36,17 +36,10 @@ name is provided or known to the 'mailmap', ``Name $$<user@host>$$'' is
 printed; otherwise only ``$$<user@host>$$'' is printed.
 
 
-CONFIGURATION
--------------
-
-See `mailmap.file` and `mailmap.blob` in linkgit:git-config[1] for how
-to specify a custom `.mailmap` target file or object.
-
-
 MAPPING AUTHORS
 ---------------
 
-See linkgit:gitmailmap[5].
+include::mailmap.txt[]
 
 
 GIT

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] [--[no-]reject-shallow]
+	  [--[no-]remote-submodules] [--jobs <n>] [--sparse]
 	  [--filter=<filter>] [--] <repository>
 	  [<directory>]
 
@@ -149,11 +149,6 @@ objects from the source repository into a pack in the cloned repository.
 --no-checkout::
 	No checkout of HEAD is performed after the clone is complete.
 
---[no-]reject-shallow::
-	Fail if the source repository is a shallow repository.
-	The 'clone.rejectShallow' configuration variable can be used to
-	specify the default.
-
 --bare::
 	Make a 'bare' Git repository.  That is, instead of
 	creating `<directory>` and placing the administrative

Documentation/git-commit.txt

@@ -9,13 +9,12 @@ SYNOPSIS
 --------
 [verse]
 'git commit' [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
-	   [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>)]
+	   [--dry-run] [(-c | -C | --fixup | --squash) <commit>]
 	   [-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]]
-	   [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
+	   [-S[<keyid>]] [--] [<pathspec>...]
-	   [--] [<pathspec>...]
 
 DESCRIPTION
 -----------
@@ -87,44 +86,11 @@ OPTIONS
 	Like '-C', but with `-c` the editor is invoked, so that
 	the user can further edit the commit message.
 
---fixup=[(amend|reword):]<commit>::
+--fixup=<commit>::
-	Create a new commit which "fixes up" `<commit>` when applied with
+	Construct a commit message for use with `rebase --autosquash`.
-	`git rebase --autosquash`. Plain `--fixup=<commit>` creates a
+	The commit message will be the subject line from the specified
-	"fixup!" commit which changes the content of `<commit>` but leaves
+	commit with a prefix of "fixup! ".  See linkgit:git-rebase[1]
-	its log message untouched. `--fixup=amend:<commit>` is similar but
+	for details.
-	creates an "amend!" commit which also replaces the log message of
-	`<commit>` with the log message of the "amend!" commit.
-	`--fixup=reword:<commit>` creates an "amend!" commit which
-	replaces the log message of `<commit>` with its own log message
-	but makes no changes to the content of `<commit>`.
-+
-The commit created by plain `--fixup=<commit>` has a subject
-composed of "fixup!" followed by the subject line from <commit>,
-and is recognized specially by `git rebase --autosquash`. The `-m`
-option may be used to supplement the log message of the created
-commit, but the additional commentary will be thrown away once the
-"fixup!" commit is squashed into `<commit>` by
-`git rebase --autosquash`.
-+
-The commit created by `--fixup=amend:<commit>` is similar but its
-subject is instead prefixed with "amend!". The log message of
-<commit> is copied into the log message of the "amend!" commit and
-opened in an editor so it can be refined. When `git rebase
---autosquash` squashes the "amend!" commit into `<commit>`, the
-log message of `<commit>` is replaced by the refined log message
-from the "amend!" commit. It is an error for the "amend!" commit's
-log message to be empty unless `--allow-empty-message` is
-specified.
-+
-`--fixup=reword:<commit>` is shorthand for `--fixup=amend:<commit>
---only`. It creates an "amend!" commit with only a log message
-(ignoring any changes staged in the index). When squashed by `git
-rebase --autosquash`, it replaces the log message of `<commit>`
-without making any other changes.
-+
-Neither "fixup!" nor "amend!" commits change authorship of
-`<commit>` when applied by `git rebase --autosquash`.
-See linkgit:git-rebase[1] for details.
 
 --squash=<commit>::
 	Construct a commit message for use with `rebase --autosquash`.
@@ -200,17 +166,6 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
 
 include::signoff-option.txt[]
 
---trailer <token>[(=|:)<value>]::
-	Specify a (<token>, <value>) pair that should be applied as a
-	trailer. (e.g. `git commit --trailer "Signed-off-by:C O Mitter \
-	<committer@example.com>" --trailer "Helped-by:C O Mitter \
-	<committer@example.com>"` will add the "Signed-off-by" trailer
-	and the "Helped-by" trailer to the commit message.)
-	The `trailer.*` configuration variables
-	(linkgit:git-interpret-trailers[1]) can be used to define if
-	a duplicated trailer is omitted, where in the run of trailers
-	each trailer would appear, and other details.
-
 -n::
 --no-verify::
 	This option bypasses the pre-commit and commit-msg hooks.

Documentation/git-config.txt

@@ -340,33 +340,12 @@ GIT_CONFIG::
 	Using the "--global" option forces this to ~/.gitconfig. Using the
 	"--system" option forces this to $(prefix)/etc/gitconfig.
 
-GIT_CONFIG_GLOBAL::
-GIT_CONFIG_SYSTEM::
-	Take the configuration from the given files instead from global or
-	system-level configuration. See linkgit:git[1] for details.
-
 GIT_CONFIG_NOSYSTEM::
 	Whether to skip reading settings from the system-wide
 	$(prefix)/etc/gitconfig file. See linkgit:git[1] for details.
 
 See also <<FILES>>.
 
-GIT_CONFIG_COUNT::
-GIT_CONFIG_KEY_<n>::
-GIT_CONFIG_VALUE_<n>::
-	If GIT_CONFIG_COUNT is set to a positive number, all environment pairs
-	GIT_CONFIG_KEY_<n> and GIT_CONFIG_VALUE_<n> up to that number will be
-	added to the process's runtime configuration. The config pairs are
-	zero-indexed. Any missing key or value is treated as an error. An empty
-	GIT_CONFIG_COUNT is treated the same as GIT_CONFIG_COUNT=0, namely no
-	pairs are processed. These environment variables will override values
-	in configuration files, but will be overridden by any explicit options
-	passed via `git -c`.
-+
-This is useful for cases where you want to spawn multiple git commands
-with a common configuration but cannot depend on a configuration file,
-for example when writing scripts.
-
 
 [[EXAMPLES]]
 EXAMPLES

Documentation/git-credential.txt

@@ -159,7 +159,3 @@ empty string.
 +
 Components which are missing from the URL (e.g., there is no
 username in the example above) will be left unset.
-
-GIT
----
-Part of the linkgit:git[1] suite

Documentation/git-cvsserver.txt

@@ -24,18 +24,6 @@ Usage:
 [verse]
 'git-cvsserver' [<options>] [pserver|server] [<directory> ...]
 
-DESCRIPTION
------------
-
-This application is a CVS emulation layer for Git.
-
-It is highly functional. However, not all methods are implemented,
-and for those methods that are implemented,
-not all switches are implemented.
-
-Testing has been done using both the CLI CVS client, and the Eclipse CVS
-plugin. Most functionality works fine with both of these clients.
-
 OPTIONS
 -------
 
@@ -69,6 +57,18 @@ access still needs to be enabled by the `gitcvs.enabled` config option
 unless `--export-all` was given, too.
 
 
+DESCRIPTION
+-----------
+
+This application is a CVS emulation layer for Git.
+
+It is highly functional. However, not all methods are implemented,
+and for those methods that are implemented,
+not all switches are implemented.
+
+Testing has been done using both the CLI CVS client, and the Eclipse CVS
+plugin. Most functionality works fine with both of these clients.
+
 LIMITATIONS
 -----------
 

Documentation/git-difftool.txt

@@ -34,14 +34,6 @@ OPTIONS
 	This is the default behaviour; the option is provided to
 	override any configuration settings.
 
---rotate-to=<file>::
-	Start showing the diff for the given path,
-	the paths before it will move to end and output.
-
---skip-to=<file>::
-	Start showing the diff for the given path, skipping all
-	the paths before it.
-
 -t <tool>::
 --tool=<tool>::
 	Use the diff tool specified by <tool>.  Valid values include

Documentation/git-for-each-ref.txt

@@ -260,9 +260,11 @@ contents:lines=N::
 	The first `N` lines of the message.
 
 Additionally, the trailers as interpreted by linkgit:git-interpret-trailers[1]
-are obtained as `trailers[:options]` (or by using the historical alias
+are obtained as `trailers` (or by using the historical alias
-`contents:trailers[:options]`). For valid [:option] values see `trailers`
+`contents:trailers`).  Non-trailer lines from the trailer block can be omitted
-section of linkgit:git-log[1].
+with `trailers:only`. Whitespace-continuations can be removed from trailers so
+that each trailer appears on a line by itself with its full content with
+`trailers:unfold`. Both can be used together as `trailers:unfold,only`.
 
 For sorting purposes, fields with numeric values sort in numeric order
 (`objectsize`, `authordate`, `committerdate`, `creatordate`, `taggerdate`).

Documentation/git-format-patch.txt

@@ -36,28 +36,11 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-Prepare each non-merge commit with its "patch" in
+Prepare each commit with its patch in
-one "message" per commit, formatted to resemble a UNIX mailbox.
+one file per commit, formatted to resemble UNIX mailbox format.
 The output of this command is convenient for e-mail submission or
 for use with 'git am'.
 
-A "message" generated by the command consists of three parts:
-
-* A brief metadata header that begins with `From <commit>`
-  with a fixed `Mon Sep 17 00:00:00 2001` datestamp to help programs
-  like "file(1)" to recognize that the file is an output from this
-  command, fields that record the author identity, the author date,
-  and the title of the change (taken from the first paragraph of the
-  commit log message).
-
-* The second and subsequent paragraphs of the commit log message.
-
-* The "patch", which is the "diff -p --stat" output (see
-  linkgit:git-diff[1]) between the commit and its parent.
-
-The log message and the patch is separated by a line with a
-three-dash line.
-
 There are two ways to specify which commits to operate on.
 
 1. A single commit, <since>, specifies that the commits leading
@@ -238,11 +221,6 @@ populated with placeholder text.
 	`--subject-prefix` option) has ` v<n>` appended to it.  E.g.
 	`--reroll-count=4` may produce `v4-0001-add-makefile.patch`
 	file that has "Subject: [PATCH v4 1/20] Add makefile" in it.
-	`<n>` does not have to be an integer (e.g. "--reroll-count=4.4",
-	or "--reroll-count=4rev2" are allowed), but the downside of
-	using such a reroll-count is that the range-diff/interdiff
-	with the previous version does not state exactly which
-	version the new interation is compared against.
 
 --to=<email>::
 	Add a `To:` header to the email headers. This is in addition
@@ -740,14 +718,6 @@ use it only when you know the recipient uses Git to apply your patch.
 $ git format-patch -3
 ------------
 
-CAVEATS
--------
-
-Note that `format-patch` will omit merge commits from the output, even
-if they are part of the requested range. A simple "patch" does not
-include enough information for the receiving end to reproduce the same
-merge commit.
-
 SEE ALSO
 --------
 linkgit:git-am[1], linkgit:git-send-email[1]

Documentation/git-gc.txt

@@ -117,14 +117,12 @@ 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, reflogs
+objects referenced by the index, remote-tracking branches, notes saved
-(which may reference commits in branches that were later amended or
+by 'git notes' under refs/notes/, reflogs (which may reference commits
-rewound), and anything else in the refs/* namespace. Note that a note
+in branches that were later amended or rewound), and anything else in
-(of the kind created by 'git notes') attached to an object does not
+the refs/* namespace.  If you are expecting some objects to be deleted
-contribute in keeping the object alive. If you are expecting some
+and they aren't, check all of those locations and decide whether it
-objects to be deleted and they aren't, check all of those locations
+makes sense in your case to remove those references.
-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

Documentation/git-grep.txt

@@ -38,6 +38,38 @@ are lists of one or more search expressions separated by newline
 characters.  An empty string as search expression matches all lines.
 
 
+CONFIGURATION
+-------------
+
+grep.lineNumber::
+	If set to true, enable `-n` option by default.
+
+grep.column::
+	If set to true, enable the `--column` option by default.
+
+grep.patternType::
+	Set the default matching behavior. Using a value of 'basic', 'extended',
+	'fixed', or 'perl' will enable the `--basic-regexp`, `--extended-regexp`,
+	`--fixed-strings`, or `--perl-regexp` option accordingly, while the
+	value 'default' will return to the default matching behavior.
+
+grep.extendedRegexp::
+	If set to true, enable `--extended-regexp` option by default. This
+	option is ignored when the `grep.patternType` option is set to a value
+	other than 'default'.
+
+grep.threads::
+	Number of grep worker threads to use. If unset (or set to 0), Git will
+	use as many threads as the number of logical cores available.
+
+grep.fullName::
+	If set to true, enable `--full-name` option by default.
+
+grep.fallbackToNoIndex::
+	If set to true, fall back to git grep --no-index if git grep
+	is executed outside of a git repository.  Defaults to false.
+
+
 OPTIONS
 -------
 --cached::
@@ -331,38 +363,6 @@ with multiple threads might perform slower than single threaded if `--textconv`
 is given and there're too many text conversions. So if you experience low
 performance in this case, it might be desirable to use `--threads=1`.
 
-CONFIGURATION
--------------
-
-grep.lineNumber::
-	If set to true, enable `-n` option by default.
-
-grep.column::
-	If set to true, enable the `--column` option by default.
-
-grep.patternType::
-	Set the default matching behavior. Using a value of 'basic', 'extended',
-	'fixed', or 'perl' will enable the `--basic-regexp`, `--extended-regexp`,
-	`--fixed-strings`, or `--perl-regexp` option accordingly, while the
-	value 'default' will return to the default matching behavior.
-
-grep.extendedRegexp::
-	If set to true, enable `--extended-regexp` option by default. This
-	option is ignored when the `grep.patternType` option is set to a value
-	other than 'default'.
-
-grep.threads::
-	Number of grep worker threads to use. If unset (or set to 0), Git will
-	use as many threads as the number of logical cores available.
-
-grep.fullName::
-	If set to true, enable `--full-name` option by default.
-
-grep.fallbackToNoIndex::
-	If set to true, fall back to git grep --no-index if git grep
-	is executed outside of a git repository.  Defaults to false.
-
-
 GIT
 ---
 Part of the linkgit:git[1] suite

Documentation/git-http-fetch.txt

@@ -41,17 +41,11 @@ commit-id::
 		<commit-id>['\t'<filename-as-in--w>]
 
 --packfile=<hash>::
-	For internal use only. Instead of a commit id on the command
+	Instead of a commit id on the command line (which is not expected in
-	line (which is not expected in
 	this case), 'git http-fetch' fetches the packfile directly at the given
 	URL and uses index-pack to generate corresponding .idx and .keep files.
 	The hash is used to determine the name of the temporary file and is
-	arbitrary. The output of index-pack is printed to stdout. Requires
+	arbitrary. The output of index-pack is printed to stdout.
-	--index-pack-args.
-
---index-pack-args=<args>::
-	For internal use only. The command to run on the contents of the
-	downloaded pack. Arguments are URL-encoded separated by spaces.
 
 --recover::
 	Verify that everything reachable from target is fetched.  Used after

Documentation/git-index-pack.txt

@@ -9,18 +9,17 @@ git-index-pack - Build pack index file for an existing packed archive
 SYNOPSIS
 --------
 [verse]
-'git index-pack' [-v] [-o <index-file>] [--[no-]rev-index] <pack-file>
+'git index-pack' [-v] [-o <index-file>] <pack-file>
 'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
-		  [--[no-]rev-index] [<pack-file>]
+                 [<pack-file>]
 
 
 DESCRIPTION
 -----------
 Reads a packed archive (.pack) from the specified file, and
-builds a pack index file (.idx) for it. Optionally writes a
+builds a pack index file (.idx) for it.  The packed archive
-reverse-index (.rev) for the specified pack. The packed
+together with the pack index can then be placed in the
-archive together with the pack index can then be placed in
+objects/pack/ directory of a Git repository.
-the objects/pack/ directory of a Git repository.
 
 
 OPTIONS
@@ -36,13 +35,6 @@ OPTIONS
 	fails if the name of packed archive does not end
 	with .pack).
 
---[no-]rev-index::
-	When this flag is provided, generate a reverse index
-	(a `.rev` file) corresponding to the given pack. If
-	`--verify` is given, ensure that the existing
-	reverse index is correct. Takes precedence over
-	`pack.writeReverseIndex`.
-
 --stdin::
 	When this flag is provided, the pack is read from stdin
 	instead and a copy is then written to <pack-file>. If
@@ -86,12 +78,7 @@ OPTIONS
 	Die if the pack contains broken links. For internal use only.
 
 --fsck-objects::
-	For internal use only.
+	Die if the pack contains broken objects. For internal use only.
-+
-Die if the pack contains broken objects. If the pack contains a tree
-pointing to a .gitmodules blob that does not exist, prints the hash of
-that blob (for the caller to check) after the hash that goes into the
-name of the pack/idx file (see "Notes").
 
 --threads=<n>::
 	Specifies the number of threads to spawn when resolving

Documentation/git-interpret-trailers.txt

@@ -232,38 +232,25 @@ trailer.<token>.ifmissing::
 	that option for trailers with the specified <token>.
 
 trailer.<token>.command::
-	This option behaves in the same way as 'trailer.<token>.cmd', except
+	This option can be used to specify a shell command that will
-	that it doesn't pass anything as argument to the specified command.
+	be called to automatically add or modify a trailer with the
-	Instead the first occurrence of substring $ARG is replaced by the
+	specified <token>.
-	value that would be passed as argument.
 +
-The 'trailer.<token>.command' option has been deprecated in favor of
+When this option is specified, the behavior is as if a special
-'trailer.<token>.cmd' due to the fact that $ARG in the user's command is
+'<token>=<value>' argument were added at the beginning of the command
-only replaced once and that the original way of replacing $ARG is not safe.
+line, where <value> is taken to be the standard output of the
+specified command with any leading and trailing whitespace trimmed
+off.
 +
-When both 'trailer.<token>.cmd' and 'trailer.<token>.command' are given
+If the command contains the `$ARG` string, this string will be
-for the same <token>, 'trailer.<token>.cmd' is used and
+replaced with the <value> part of an existing trailer with the same
-'trailer.<token>.command' is ignored.
+<token>, if any, before the command is launched.
-
-trailer.<token>.cmd::
-	This option can be used to specify a shell command that will be called:
-	once to automatically add a trailer with the specified <token>, and then
-	each time a '--trailer <token>=<value>' argument to modify the <value> of
-	the trailer that this option would produce.
 +
-When the specified command is first called to add a trailer
+If some '<token>=<value>' arguments are also passed on the command
-with the specified <token>, the behavior is as if a special
+line, when a 'trailer.<token>.command' is configured, the command will
-'--trailer <token>=<value>' argument was added at the beginning
+also be executed for each of these arguments. And the <value> part of
-of the "git interpret-trailers" command, where <value>
+these arguments, if any, will be used to replace the `$ARG` string in
-is taken to be the standard output of the command with any
+the command.
-leading and trailing whitespace trimmed off.
-+
-If some '--trailer <token>=<value>' arguments are also passed
-on the command line, the command is called again once for each
-of these arguments with the same <token>. And the <value> part
-of these arguments, if any, will be passed to the command as its
-first argument. This way the command can produce a <value> computed
-from the <value> passed in the '--trailer <token>=<value>' argument.
 
 EXAMPLES
 --------
@@ -346,55 +333,6 @@ subject
 Fix #42
 ------------
 
-* Configure a 'help' trailer with a cmd use a script `glog-find-author`
-  which search specified author identity from git log in git repository
-  and show how it works:
-+
-------------
-$ cat ~/bin/glog-find-author
-#!/bin/sh
-test -n "$1" && git log --author="$1" --pretty="%an <%ae>" -1 || true
-$ git config trailer.help.key "Helped-by: "
-$ git config trailer.help.ifExists "addIfDifferentNeighbor"
-$ git config trailer.help.cmd "~/bin/glog-find-author"
-$ git interpret-trailers --trailer="help:Junio" --trailer="help:Couder" <<EOF
-> subject
->
-> message
->
-> EOF
-subject
-
-message
-
-Helped-by: Junio C Hamano <gitster@pobox.com>
-Helped-by: Christian Couder <christian.couder@gmail.com>
-------------
-
-* Configure a 'ref' trailer with a cmd use a script `glog-grep`
-  to grep last relevant commit from git log in the git repository
-  and show how it works:
-+
-------------
-$ cat ~/bin/glog-grep
-#!/bin/sh
-test -n "$1" && git log --grep "$1" --pretty=reference -1 || true
-$ git config trailer.ref.key "Reference-to: "
-$ git config trailer.ref.ifExists "replace"
-$ git config trailer.ref.cmd "~/bin/glog-grep"
-$ git interpret-trailers --trailer="ref:Add copyright notices." <<EOF
-> subject
->
-> message
->
-> EOF
-subject
-
-message
-
-Reference-to: 8bc9a0c769 (Add copyright notices., 2005-04-07)
-------------
-
 * Configure a 'see' trailer with a command to show the subject of a
   commit that is related, and show how it works:
 +

Documentation/git-log.txt

@@ -107,15 +107,47 @@ DIFF FORMATTING
 By default, `git log` does not generate any diff output. The options
 below can be used to show the changes made by each commit.
 
-Note that unless one of `--diff-merges` variants (including short
+Note that unless one of `-c`, `--cc`, or `-m` is given, merge commits
-`-m`, `-c`, and `--cc` options) is explicitly given, merge commits
+will never show a diff, even if a diff format like `--patch` is
-will not show a diff, even if a diff format like `--patch` is
+selected, nor will they match search options like `-S`. The exception is
-selected, nor will they match search options like `-S`. The exception
+when `--first-parent` is in use, in which merges are treated like normal
-is when `--first-parent` is in use, in which case `first-parent` is
+single-parent commits (this can be overridden by providing a
-the default format.
+combined-diff option or with `--no-diff-merges`).
+
+-c::
+	With this option, diff output for a merge commit
+	shows the differences from each of the parents to the merge result
+	simultaneously instead of showing pairwise diff between a parent
+	and the result one at a time. Furthermore, it lists only files
+	which were modified from all parents.
+
+--cc::
+	This flag implies the `-c` option and further compresses the
+	patch output by omitting uninteresting hunks whose contents in
+	the parents have only two variants and the merge result picks
+	one of them without modification.
+
+--combined-all-paths::
+	This flag causes combined diffs (used for merge commits) to
+	list the name of the file from all parents.  It thus only has
+	effect when -c or --cc are specified, and is likely only
+	useful if filename changes are detected (i.e. when either
+	rename or copy detection have been requested).
+
+-m::
+	This flag makes the merge commits show the full diff like
+	regular commits; for each merge parent, a separate log entry
+	and diff is generated. An exception is that only diff against
+	the first parent is shown when `--first-parent` option is given;
+	in that case, the output represents the changes the merge
+	brought _into_ the then-current branch.
+
+--diff-merges=off::
+--no-diff-merges::
+	Disable output of diffs for merge commits (default). Useful to
+	override `-m`, `-c`, or `--cc`.
 
 :git-log: 1
-:diff-merges-default: `off`
 include::diff-options.txt[]
 
 include::diff-generate-patch.txt[]

Documentation/git-ls-files.txt

@@ -13,7 +13,6 @@ SYNOPSIS
 		(--[cached|deleted|others|ignored|stage|unmerged|killed|modified])*
 		(-[c|d|o|i|s|u|k|m])*
 		[--eol]
-		[--deduplicate]
 		[-x <pattern>|--exclude=<pattern>]
 		[-X <file>|--exclude-from=<file>]
 		[--exclude-per-directory=<file>]
@@ -81,13 +80,6 @@ OPTIONS
 	\0 line termination on output and do not quote filenames.
 	See OUTPUT below for more information.
 
---deduplicate::
-	When only filenames are shown, suppress duplicates that may
-	come from having multiple stages during a merge, or giving
-	`--deleted` and `--modified` option at the same time.
-	When any of the `-t`, `--unmerged`, or `--stage` option is
-	in use, this option has no effect.
-
 -x <pattern>::
 --exclude=<pattern>::
 	Skip untracked files matching pattern.

Documentation/git-mailinfo.txt

@@ -9,9 +9,7 @@ git-mailinfo - Extracts patch and authorship from a single e-mail message
 SYNOPSIS
 --------
 [verse]
-'git mailinfo' [-k|-b] [-u | --encoding=<encoding> | -n]
+'git mailinfo' [-k|-b] [-u | --encoding=<encoding> | -n] [--[no-]scissors] <msg> <patch>
-	       [--[no-]scissors] [--quoted-cr=<action>]
-	       <msg> <patch>
 
 
 DESCRIPTION
@@ -55,7 +53,7 @@ character.
 	The commit log message, author name and author email are
 	taken from the e-mail, and after minimally decoding MIME
 	transfer encoding, re-coded in the charset specified by
-	`i18n.commitEncoding` (defaulting to UTF-8) by transliterating
+	i18n.commitencoding (defaulting to UTF-8) by transliterating
 	them.  This used to be optional but now it is the default.
 +
 Note that the patch is always used as-is without charset
@@ -63,7 +61,7 @@ conversion, even with this flag.
 
 --encoding=<encoding>::
 	Similar to -u.  But when re-coding, the charset specified here is
-	used instead of the one specified by `i18n.commitEncoding` or UTF-8.
+	used instead of the one specified by i18n.commitencoding or UTF-8.
 
 -n::
 	Disable all charset re-coding of the metadata.
@@ -91,23 +89,6 @@ This can be enabled by default with the configuration option mailinfo.scissors.
 --no-scissors::
 	Ignore scissors lines. Useful for overriding mailinfo.scissors settings.
 
---quoted-cr=<action>::
-	Action when processes email messages sent with base64 or
-	quoted-printable encoding, and the decoded lines end with a CRLF
-	instead of a simple LF.
-+
-The valid actions are:
-+
---
-*	`nowarn`: Git will do nothing when such a CRLF is found.
-*	`warn`: Git will issue a warning for each message if such a CRLF is
-	found.
-*	`strip`: Git will convert those CRLF to LF.
---
-+
-The default action could be set by configuration option `mailinfo.quotedCR`.
-If no such configuration option has been set, `warn` will be used.
-
 <msg>::
 	The commit log message extracted from e-mail, usually
 	except the title line which comes from e-mail Subject.

Documentation/git-maintenance.txt

@@ -92,8 +92,10 @@ commit-graph::
 prefetch::
 	The `prefetch` task updates the object directory with the latest
 	objects from all registered remotes. For each remote, a `git fetch`
-	command is run. The configured refspec is modified to place all
+	command is run. The refmap is custom to avoid updating local or remote
-	requested refs within `refs/prefetch/`. Also, tags are not updated.
+	branches (those in `refs/heads` or `refs/remotes`). Instead, the
+	remote refs are stored in `refs/prefetch/<remote>/`. Also, tags are
+	not updated.
 +
 This is done to avoid disrupting the remote-tracking branches. The end users
 expect these refs to stay unmoved unless they initiate a fetch.  With prefetch
@@ -143,12 +145,6 @@ incremental-repack::
 	which is a special case that attempts to repack all pack-files
 	into a single pack-file.
 
-pack-refs::
-	The `pack-refs` task collects the loose reference files and
-	collects them into a single file. This speeds up operations that
-	need to iterate across many references. See linkgit:git-pack-refs[1]
-	for more information.
-
 OPTIONS
 -------
 --auto::
@@ -222,122 +218,6 @@ Further, the `git gc` command should not be combined with
 but does not take the lock in the same way as `git maintenance run`. If
 possible, use `git maintenance run --task=gc` instead of `git gc`.
 
-The following sections describe the mechanisms put in place to run
-background maintenance by `git maintenance start` and how to customize
-them.
-
-BACKGROUND MAINTENANCE ON POSIX SYSTEMS
----------------------------------------
-
-The standard mechanism for scheduling background tasks on POSIX systems
-is cron(8). This tool executes commands based on a given schedule. The
-current list of user-scheduled tasks can be found by running `crontab -l`.
-The schedule written by `git maintenance start` is similar to this:
-
------------------------------------------------------------------------
-# BEGIN GIT MAINTENANCE SCHEDULE
-# The following schedule was created by Git
-# Any edits made in this region might be
-# replaced in the future by a Git command.
-
-0 1-23 * * * "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=hourly
-0 0 * * 1-6 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=daily
-0 0 * * 0 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=weekly
-
-# END GIT MAINTENANCE SCHEDULE
------------------------------------------------------------------------
-
-The comments are used as a region to mark the schedule as written by Git.
-Any modifications within this region will be completely deleted by
-`git maintenance stop` or overwritten by `git maintenance start`.
-
-The `crontab` entry specifies the full path of the `git` executable to
-ensure that the executed `git` command is the same one with which
-`git maintenance start` was issued independent of `PATH`. If the same user
-runs `git maintenance start` with multiple Git executables, then only the
-latest executable is used.
-
-These commands use `git for-each-repo --config=maintenance.repo` to run
-`git maintenance run --schedule=<frequency>` on each repository listed in
-the multi-valued `maintenance.repo` config option. These are typically
-loaded from the user-specific global config. The `git maintenance` process
-then determines which maintenance tasks are configured to run on each
-repository with each `<frequency>` using the `maintenance.<task>.schedule`
-config options. These values are loaded from the global or repository
-config values.
-
-If the config values are insufficient to achieve your desired background
-maintenance schedule, then you can create your own schedule. If you run
-`crontab -e`, then an editor will load with your user-specific `cron`
-schedule. In that editor, you can add your own schedule lines. You could
-start by adapting the default schedule listed earlier, or you could read
-the crontab(5) documentation for advanced scheduling techniques. Please
-do use the full path and `--exec-path` techniques from the default
-schedule to ensure you are executing the correct binaries in your
-schedule.
-
-
-BACKGROUND MAINTENANCE ON MACOS SYSTEMS
----------------------------------------
-
-While macOS technically supports `cron`, using `crontab -e` requires
-elevated privileges and the executed process does not have a full user
-context. Without a full user context, Git and its credential helpers
-cannot access stored credentials, so some maintenance tasks are not
-functional.
-
-Instead, `git maintenance start` interacts with the `launchctl` tool,
-which is the recommended way to schedule timed jobs in macOS. Scheduling
-maintenance through `git maintenance (start|stop)` requires some
-`launchctl` features available only in macOS 10.11 or later.
-
-Your user-specific scheduled tasks are stored as XML-formatted `.plist`
-files in `~/Library/LaunchAgents/`. You can see the currently-registered
-tasks using the following command:
-
------------------------------------------------------------------------
-$ ls ~/Library/LaunchAgents/org.git-scm.git*
-org.git-scm.git.daily.plist
-org.git-scm.git.hourly.plist
-org.git-scm.git.weekly.plist
------------------------------------------------------------------------
-
-One task is registered for each `--schedule=<frequency>` option. To
-inspect how the XML format describes each schedule, open one of these
-`.plist` files in an editor and inspect the `<array>` element following
-the `<key>StartCalendarInterval</key>` element.
-
-`git maintenance start` will overwrite these files and register the
-tasks again with `launchctl`, so any customizations should be done by
-creating your own `.plist` files with distinct names. Similarly, the
-`git maintenance stop` command will unregister the tasks with `launchctl`
-and delete the `.plist` files.
-
-To create more advanced customizations to your background tasks, see
-launchctl.plist(5) for more information.
-
-
-BACKGROUND MAINTENANCE ON WINDOWS SYSTEMS
------------------------------------------
-
-Windows does not support `cron` and instead has its own system for
-scheduling background tasks. The `git maintenance start` command uses
-the `schtasks` command to submit tasks to this system. You can inspect
-all background tasks using the Task Scheduler application. The tasks
-added by Git have names of the form `Git Maintenance (<frequency>)`.
-The Task Scheduler GUI has ways to inspect these tasks, but you can also
-export the tasks to XML files and view the details there.
-
-Note that since Git is a console application, these background tasks
-create a console window visible to the current user. This can be changed
-manually by selecting the "Run whether user is logged in or not" option
-in Task Scheduler. This change requires a password input, which is why
-`git maintenance start` does not select it by default.
-
-If you want to customize the background tasks, please rename the tasks
-so future calls to `git maintenance (start|stop)` do not overwrite your
-custom tasks.
-
 
 GIT
 ---

Documentation/git-mergetool--lib.txt

@@ -38,10 +38,6 @@ get_merge_tool_cmd::
 get_merge_tool_path::
 	returns the custom path for a merge tool.
 
-initialize_merge_tool::
-	bring merge tool specific functions into scope so they can be used or
-	overridden.
-
 run_merge_tool::
 	launches a merge tool given the tool name and a true/false
 	flag to indicate whether a merge base is present.

Documentation/git-mergetool.txt

@@ -99,10 +99,6 @@ success of the resolution after the custom tool has exited.
 	(see linkgit:git-config[1]).  To cancel `diff.orderFile`,
 	use `-O/dev/null`.
 
-CONFIGURATION
--------------
-include::config/mergetool.txt[]
-
 TEMPORARY FILES
 ---------------
 `git mergetool` creates `*.orig` backup files while resolving merges.

Documentation/git-mktag.txt

@@ -3,7 +3,7 @@ git-mktag(1)
 
 NAME
 ----
-git-mktag - Creates a tag object with extra validation
+git-mktag - Creates a tag object
 
 
 SYNOPSIS
@@ -13,50 +13,23 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
+Reads a tag contents on standard input and creates a tag object
+that can also be used to sign other objects.
 
-Reads a tag contents on standard input and creates a tag object. The
+The output is the new tag's <object> identifier.
-output is the new tag's <object> identifier.
-
-This command is mostly equivalent to linkgit:git-hash-object[1]
-invoked with `-t tag -w --stdin`. I.e. both of these will create and
-write a tag found in `my-tag`:
-
-    git mktag <my-tag
-    git hash-object -t tag -w --stdin <my-tag
-
-The difference is that mktag will die before writing the tag if the
-tag doesn't pass a linkgit:git-fsck[1] check.
-
-The "fsck" check done mktag is stricter than what linkgit:git-fsck[1]
-would run by default in that all `fsck.<msg-id>` messages are promoted
-from warnings to errors (so e.g. a missing "tagger" line is an error).
-
-Extra headers in the object are also an error under mktag, but ignored
-by linkgit:git-fsck[1]. This extra check can be turned off by setting
-the appropriate `fsck.<msg-id>` varible:
-
-    git -c fsck.extraHeaderEntry=ignore mktag <my-tag-with-headers
-
-OPTIONS
--------
-
---strict::
-	By default mktag turns on the equivalent of
-	linkgit:git-fsck[1] `--strict` mode. Use `--no-strict` to
-	disable it.
 
 Tag Format
 ----------
 A tag signature file, to be fed to this command's standard input,
 has a very simple fixed format: four lines of
 
-  object <hash>
+  object <sha1>
   type <typename>
   tag <tagname>
   tagger <tagger>
 
 followed by some 'optional' free-form message (some tags created
-by older Git may not have `tagger` line).  The message, when it
+by older Git may not have `tagger` line).  The message, when
 exists, is separated by a blank line from the header.  The
 message part may contain a signature that Git itself doesn't
 care about, but that can be verified with gpg.

Documentation/git-multi-pack-index.txt

@@ -9,8 +9,7 @@ git-multi-pack-index - Write and verify multi-pack-indexes
 SYNOPSIS
 --------
 [verse]
-'git multi-pack-index' [--object-dir=<dir>] [--[no-]progress]
+'git multi-pack-index' [--object-dir=<dir>] [--[no-]progress] <subcommand>
-	[--preferred-pack=<pack>] <subcommand>
 
 DESCRIPTION
 -----------
@@ -31,16 +30,7 @@ OPTIONS
 The following subcommands are available:
 
 write::
-	Write a new MIDX file. The following options are available for
+	Write a new MIDX file.
-	the `write` sub-command:
-+
---
-	--preferred-pack=<pack>::
-		Optionally specify the tie-breaking pack used when
-		multiple packs contain the same object. If not given,
-		ties are broken in favor of the pack with the lowest
-		mtime.
---
 
 verify::
 	Verify the contents of the MIDX file.

Documentation/git-p4.txt

@@ -762,7 +762,3 @@ IMPLEMENTATION DETAILS
   message indicating the p4 depot location and change number.  This
   line is used by later 'git p4 sync' operations to know which p4
   changes are new.
-
-GIT
----
-Part of the linkgit:git[1] suite

Documentation/git-pack-objects.txt

@@ -85,16 +85,6 @@ base-name::
 	reference was included in the resulting packfile.  This
 	can be useful to send new tags to native Git clients.
 
---stdin-packs::
-	Read the basenames of packfiles (e.g., `pack-1234abcd.pack`)
-	from the standard input, instead of object names or revision
-	arguments. The resulting pack contains all objects listed in the
-	included packs (those not beginning with `^`), excluding any
-	objects listed in the excluded packs (beginning with `^`).
-+
-Incompatible with `--revs`, or options that imply `--revs` (such as
-`--all`), with the exception of `--unpacked`, which is compatible.
-
 --window=<n>::
 --depth=<n>::
 	These two options affect how the objects contained in
@@ -410,17 +400,6 @@ Note that we pick a single island for each regex to go into, using "last
 one wins" ordering (which allows repo-specific config to take precedence
 over user-wide config, and so forth).
 
-
-CONFIGURATION
--------------
-
-Various configuration variables affect packing, see
-linkgit:git-config[1] (search for "pack" and "delta").
-
-Notably, delta compression is not used on objects larger than the
-`core.bigFileThreshold` configuration variable and on files with the
-attribute `delta` set to false.
-
 SEE ALSO
 --------
 linkgit:git-rev-list[1]

Documentation/git-push.txt

@@ -600,7 +600,7 @@ EXAMPLES
 
 `git push origin`::
 	Without additional configuration, pushes the current branch to
-	the configured upstream (`branch.<name>.merge` configuration
+	the configured upstream (`remote.origin.merge` configuration
 	variable) if it has the same name as the current branch, and
 	errors out without pushing otherwise.
 +

Documentation/git-range-diff.txt

@@ -10,7 +10,6 @@ SYNOPSIS
 [verse]
 'git range-diff' [--color=[<when>]] [--no-color] [<diff-options>]
 	[--no-dual-color] [--creation-factor=<factor>]
-	[--left-only | --right-only]
 	( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> )
 
 DESCRIPTION
@@ -29,17 +28,6 @@ Finally, the list of matching commits is shown in the order of the
 second commit range, with unmatched commits being inserted just after
 all of their ancestors have been shown.
 
-There are three ways to specify the commit ranges:
-
-- `<range1> <range2>`: Either commit range can be of the form
-  `<base>..<rev>`, `<rev>^!` or `<rev>^-<n>`. See `SPECIFYING RANGES`
-  in linkgit:gitrevisions[7] for more details.
-
-- `<rev1>...<rev2>`. This is equivalent to
-  `<rev2>..<rev1> <rev1>..<rev2>`.
-
-- `<base> <rev1> <rev2>`: This is equivalent to `<base>..<rev1>
-  <base>..<rev2>`.
 
 OPTIONS
 -------
@@ -69,14 +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.
 
---left-only::
-	Suppress commits that are missing from the first specified range
-	(or the "left range" when using the `<rev1>...<rev2>` format).
-
---right-only::
-	Suppress commits that are missing from the second specified range
-	(or the "right range" when using the `<rev1>...<rev2>` format).
-
 --[no-]notes[=<ref>]::
 	This flag is passed to the `git log` program
 	(see linkgit:git-log[1]) that generates the patches.

Documentation/git-rebase.txt

@@ -200,6 +200,12 @@ Alternatively, you can undo the 'git rebase' with
 
     git rebase --abort
 
+CONFIGURATION
+-------------
+
+include::config/rebase.txt[]
+include::config/sequencer.txt[]
+
 OPTIONS
 -------
 --onto <newbase>::
@@ -587,17 +593,16 @@ See also INCOMPATIBLE OPTIONS below.
 
 --autosquash::
 --no-autosquash::
-	When the commit log message begins with "squash! ..." or "fixup! ..."
+	When the commit log message begins with "squash! ..." (or
-	or "amend! ...", and there is already a commit in the todo list that
+	"fixup! ..."), and there is already a commit in the todo list that
-	matches the same `...`, automatically modify the todo list of
+	matches the same `...`, automatically modify the todo list of rebase
-	`rebase -i`, so that the commit marked for squashing comes right after
+	-i so that the commit marked for squashing comes right after the
-	the commit to be modified, and change the action of the moved commit
+	commit to be modified, and change the action of the moved commit
-	from `pick` to `squash` or `fixup` or `fixup -C` respectively. A commit
+	from `pick` to `squash` (or `fixup`).  A commit matches the `...` if
-	matches the `...` if the commit subject matches, or if the `...` refers
+	the commit subject matches, or if the `...` refers to the commit's
-	to the commit's hash. As a fall-back, partial matches of the commit
+	hash. As a fall-back, partial matches of the commit subject work,
-	subject work, too. The recommended way to create fixup/amend/squash
+	too.  The recommended way to create fixup/squash commits is by using
-	commits is by using the `--fixup`, `--fixup=amend:` or `--fixup=reword:`
+	the `--fixup`/`--squash` options of linkgit:git-commit[1].
-	and `--squash` options respectively of linkgit:git-commit[1].
 +
 If the `--autosquash` option is enabled by default using the
 configuration variable `rebase.autoSquash`, this option can be
@@ -617,14 +622,6 @@ See also INCOMPATIBLE OPTIONS below.
 --no-reschedule-failed-exec::
 	Automatically reschedule `exec` commands that failed. This only makes
 	sense in interactive mode (or when an `--exec` option was provided).
-+
-Even though this option applies once a rebase is started, it's set for
-the whole rebase at the start based on either the
-`rebase.rescheduleFailedExec` configuration (see linkgit:git-config[1]
-or "CONFIGURATION" below) or whether this option is
-provided. Otherwise an explicit `--no-reschedule-failed-exec` at the
-start would be overridden by the presence of
-`rebase.rescheduleFailedExec=true` configuration.
 
 INCOMPATIBLE OPTIONS
 --------------------
@@ -890,17 +887,9 @@ If you want to fold two or more commits into one, replace the command
 "pick" for the second and subsequent commits with "squash" or "fixup".
 If the commits had different authors, the folded commit will be
 attributed to the author of the first commit.  The suggested commit
-message for the folded commit is the concatenation of the first
+message for the folded commit is the concatenation of the commit
-commit's message with those identified by "squash" commands, omitting the
+messages of the first commit and of those with the "squash" command,
-messages of commits identified by "fixup" commands, unless "fixup -c"
+but omits the commit messages of commits with the "fixup" command.
-is used.  In that case the suggested commit message is only the message
-of the "fixup -c" commit, and an editor is opened allowing you to edit
-the message.  The contents (patch) of the "fixup -c" commit are still
-incorporated into the folded commit. If there is more than one "fixup -c"
-commit, the message from the final one is used.  You can also use
-"fixup -C" to get the same behavior as "fixup -c" except without opening
-an editor.
-
 
 'git rebase' will stop when "pick" has been replaced with "edit" or
 when a command fails due to merge errors. When you are done editing
@@ -1268,12 +1257,6 @@ merge tlsv1.3
 merge cmake
 ------------
 
-CONFIGURATION
--------------
-
-include::config/rebase.txt[]
-include::config/sequencer.txt[]
-
 BUGS
 ----
 The todo list presented by the deprecated `--preserve-merges --interactive`

Documentation/git-repack.txt

@@ -165,35 +165,9 @@ depth is 4095.
 	Pass the `--delta-islands` option to `git-pack-objects`, see
 	linkgit:git-pack-objects[1].
 
--g=<factor>::
+Configuration
---geometric=<factor>::
-	Arrange resulting pack structure so that each successive pack
-	contains at least `<factor>` times the number of objects as the
-	next-largest pack.
-+
-`git repack` ensures this by determining a "cut" of packfiles that need
-to be repacked into one in order to ensure a geometric progression. It
-picks the smallest set of packfiles such that as many of the larger
-packfiles (by count of objects contained in that pack) may be left
-intact.
-+
-Unlike other repack modes, the set of objects to pack is determined
-uniquely by the set of packs being "rolled-up"; in other words, the
-packs determined to need to be combined in order to restore a geometric
-progression.
-+
-When `--unpacked` is specified, loose objects are implicitly included in
-this "roll-up", without respect to their reachability. This is subject
-to change in the future. This option (implying a drastically different
-repack mode) is not guaranteed to work with all other combinations of
-option to `git repack`.
-
-CONFIGURATION
 -------------
 
-Various configuration variables affect packing, see
-linkgit:git-config[1] (search for "pack" and "delta").
-
 By default, the command passes `--delta-base-offset` option to
 'git pack-objects'; this typically results in slightly smaller packs,
 but the generated packs are incompatible with versions of Git older than
@@ -204,10 +178,6 @@ need to set the configuration variable `repack.UseDeltaBaseOffset` to
 is unaffected by this option as the conversion is performed on the fly
 as needed in that case.
 
-Delta compression is not used on objects larger than the
-`core.bigFileThreshold` configuration variable and on files with the
-attribute `delta` set to false.
-
 SEE ALSO
 --------
 linkgit:git-pack-objects[1]

Documentation/git-rev-list.txt

@@ -31,99 +31,6 @@ include::rev-list-options.txt[]
 
 include::pretty-formats.txt[]
 
-EXAMPLES
---------
-
-* Print the list of commits reachable from the current branch.
-+
-----------
-git rev-list HEAD
-----------
-
-* Print the list of commits on this branch, but not present in the
-  upstream branch.
-+
-----------
-git rev-list @{upstream}..HEAD
-----------
-
-* Format commits with their author and commit message (see also the
-  porcelain linkgit:git-log[1]).
-+
-----------
-git rev-list --format=medium HEAD
-----------
-
-* Format commits along with their diffs (see also the porcelain
-  linkgit:git-log[1], which can do this in a single process).
-+
-----------
-git rev-list HEAD |
-git diff-tree --stdin --format=medium -p
-----------
-
-* Print the list of commits on the current branch that touched any
-  file in the `Documentation` directory.
-+
-----------
-git rev-list HEAD -- Documentation/
-----------
-
-* Print the list of commits authored by you in the past year, on
-  any branch, tag, or other ref.
-+
-----------
-git rev-list --author=you@example.com --since=1.year.ago --all
-----------
-
-* Print the list of objects reachable from the current branch (i.e., all
-  commits and the blobs and trees they contain).
-+
-----------
-git rev-list --objects HEAD
-----------
-
-* Compare the disk size of all reachable objects, versus those
-  reachable from reflogs, versus the total packed size. This can tell
-  you whether running `git repack -ad` might reduce the repository size
-  (by dropping unreachable objects), and whether expiring reflogs might
-  help.
-+
-----------
-# reachable objects
-git rev-list --disk-usage --objects --all
-# plus reflogs
-git rev-list --disk-usage --objects --all --reflog
-# total disk size used
-du -c .git/objects/pack/*.pack .git/objects/??/*
-# alternative to du: add up "size" and "size-pack" fields
-git count-objects -v
-----------
-
-* Report the disk size of each branch, not including objects used by the
-  current branch. This can find outliers that are contributing to a
-  bloated repository size (e.g., because somebody accidentally committed
-  large build artifacts).
-+
-----------
-git for-each-ref --format='%(refname)' |
-while read branch
-do
-	size=$(git rev-list --disk-usage --objects HEAD..$branch)
-	echo "$size $branch"
-done |
-sort -n
-----------
-
-* Compare the on-disk size of branches in one group of refs, excluding
-  another. If you co-mingle objects from multiple remotes in a single
-  repository, this can show which remotes are contributing to the
-  repository size (taking the size of `origin` as a baseline).
-+
-----------
-git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin
-----------
-
 GIT
 ---
 Part of the linkgit:git[1] suite

Documentation/git-rev-parse.txt

@@ -212,18 +212,6 @@ Options for Files
 	Only the names of the variables are listed, not their value,
 	even if they are set.
 
---path-format=(absolute|relative)::
-	Controls the behavior of certain other options. If specified as absolute, the
-	paths printed by those options will be absolute and canonical. If specified as
-	relative, the paths will be relative to the current working directory if that
-	is possible.  The default is option specific.
-+
-This option may be specified multiple times and affects only the arguments that
-follow it on the command line, either to the end of the command line or the next
-instance of this option.
-
-The following options are modified by `--path-format`:
-
 --git-dir::
 	Show `$GIT_DIR` if defined. Otherwise show the path to
 	the .git directory. The path shown, when relative, is
@@ -233,42 +221,13 @@ If `$GIT_DIR` is not defined and the current directory
 is not detected to lie in a Git repository or work tree
 print a message to stderr and exit with nonzero status.
 
---git-common-dir::
-	Show `$GIT_COMMON_DIR` if defined, else `$GIT_DIR`.
-
---resolve-git-dir <path>::
-	Check if <path> is a valid repository or a gitfile that
-	points at a valid repository, and print the location of the
-	repository.  If <path> is a gitfile then the resolved path
-	to the real repository is printed.
-
---git-path <path>::
-	Resolve "$GIT_DIR/<path>" and takes other path relocation
-	variables such as $GIT_OBJECT_DIRECTORY,
-	$GIT_INDEX_FILE... into account. For example, if
-	$GIT_OBJECT_DIRECTORY is set to /foo/bar then "git rev-parse
-	--git-path objects/abc" returns /foo/bar/abc.
-
---show-toplevel::
-	Show the (by default, absolute) path of the top-level directory
-	of the working tree. If there is no working tree, report an error.
-
---show-superproject-working-tree::
-	Show the absolute path of the root of the superproject's
-	working tree (if exists) that uses the current repository as
-	its submodule.  Outputs nothing if the current repository is
-	not used as a submodule by any project.
-
---shared-index-path::
-	Show the path to the shared index file in split index mode, or
-	empty if not in split-index mode.
-
-The following options are unaffected by `--path-format`:
-
 --absolute-git-dir::
 	Like `--git-dir`, but its output is always the canonicalized
 	absolute path.
 
+--git-common-dir::
+	Show `$GIT_COMMON_DIR` if defined, else `$GIT_DIR`.
+
 --is-inside-git-dir::
 	When the current working directory is below the repository
 	directory print "true", otherwise "false".
@@ -283,6 +242,19 @@ The following options are unaffected by `--path-format`:
 --is-shallow-repository::
 	When the repository is shallow print "true", otherwise "false".
 
+--resolve-git-dir <path>::
+	Check if <path> is a valid repository or a gitfile that
+	points at a valid repository, and print the location of the
+	repository.  If <path> is a gitfile then the resolved path
+	to the real repository is printed.
+
+--git-path <path>::
+	Resolve "$GIT_DIR/<path>" and takes other path relocation
+	variables such as $GIT_OBJECT_DIRECTORY,
+	$GIT_INDEX_FILE... into account. For example, if
+	$GIT_OBJECT_DIRECTORY is set to /foo/bar then "git rev-parse
+	--git-path objects/abc" returns /foo/bar/abc.
+
 --show-cdup::
 	When the command is invoked from a subdirectory, show the
 	path of the top-level directory relative to the current
@@ -293,6 +265,20 @@ The following options are unaffected by `--path-format`:
 	path of the current directory relative to the top-level
 	directory.
 
+--show-toplevel::
+	Show the absolute path of the top-level directory of the working
+	tree. If there is no working tree, report an error.
+
+--show-superproject-working-tree::
+	Show the absolute path of the root of the superproject's
+	working tree (if exists) that uses the current repository as
+	its submodule.  Outputs nothing if the current repository is
+	not used as a submodule by any project.
+
+--shared-index-path::
+	Show the path to the shared index file in split index mode, or
+	empty if not in split-index mode.
+
 --show-object-format[=(storage|input|output)]::
 	Show the object format (hash algorithm) used for the repository
 	for storage inside the `.git` directory, input, or output. For

Documentation/git-rm.txt

@@ -23,9 +23,7 @@ branch, and no updates to their contents can be staged in the index,
 though that default behavior can be overridden with the `-f` option.
 When `--cached` is given, the staged content has to
 match either the tip of the branch or the file on disk,
-allowing the file to be removed from just the index. When
+allowing the file to be removed from just the index.
-sparse-checkouts are in use (see linkgit:git-sparse-checkout[1]),
-`git rm` will only remove paths within the sparse-checkout patterns.
 
 
 OPTIONS

Documentation/git-shortlog.txt

@@ -111,11 +111,11 @@ include::rev-list-options.txt[]
 MAPPING AUTHORS
 ---------------
 
-See linkgit:gitmailmap[5].
+The `.mailmap` feature is used to coalesce together commits by the same
+person in the shortlog, where their name and/or email address was
+spelled differently.
 
-Note that if `git shortlog` is run outside of a repository (to process
+include::mailmap.txt[]
-log contents on standard input), it will look for a `.mailmap` file in
-the current directory.
 
 GIT
 ---

Documentation/git-show.txt

@@ -45,13 +45,10 @@ include::pretty-options.txt[]
 include::pretty-formats.txt[]
 
 
-DIFF FORMATTING
+COMMON DIFF OPTIONS
----------------
+-------------------
-The options below can be used to change the way `git show` generates
-diff output.
 
 :git-log: 1
-:diff-merges-default: `dense-combined`
 include::diff-options.txt[]
 
 include::diff-generate-patch.txt[]

Documentation/git-sparse-checkout.txt

@@ -45,20 +45,6 @@ To avoid interfering with other worktrees, it first enables the
 When `--cone` is provided, the `core.sparseCheckoutCone` setting is
 also set, allowing for better performance with a limited set of
 patterns (see 'CONE PATTERN SET' below).
-+
-Use the `--[no-]sparse-index` option to toggle the use of the sparse
-index format. This reduces the size of the index to be more closely
-aligned with your sparse-checkout definition. This can have significant
-performance advantages for commands such as `git status` or `git add`.
-This feature is still experimental. Some commands might be slower with
-a sparse index until they are properly integrated with the feature.
-+
-**WARNING:** Using a sparse index requires modifying the index in a way
-that is not completely understood by external tools. If you have trouble
-with this compatibility, then run `git sparse-checkout init --no-sparse-index`
-to rewrite your index to not be sparse. Older versions of Git will not
-understand the sparse directory entries index extension and may fail to
-interact with your repository until it is disabled.
 
 'set'::
 	Write a set of patterns to the sparse-checkout file, as given as

Documentation/git-stash.txt

@@ -8,8 +8,8 @@ git-stash - Stash the changes in a dirty working directory away
 SYNOPSIS
 --------
 [verse]
-'git stash' list [<log-options>]
+'git stash' list [<options>]
-'git stash' show [-u|--include-untracked|--only-untracked] [<diff-options>] [<stash>]
+'git stash' show [<options>] [<stash>]
 'git stash' drop [-q|--quiet] [<stash>]
 'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>]
 'git stash' branch <branchname> [<stash>]
@@ -67,7 +67,7 @@ save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q
 	Instead, all non-option arguments are concatenated to form the stash
 	message.
 
-list [<log-options>]::
+list [<options>]::
 
 	List the stash entries that you currently have.  Each 'stash entry' is
 	listed with its name (e.g. `stash@{0}` is the latest entry, `stash@{1}` is
@@ -83,7 +83,7 @@ stash@{1}: On master: 9cc0589... Add git-stash
 The command takes options applicable to the 'git log'
 command to control what is shown and how. See linkgit:git-log[1].
 
-show [-u|--include-untracked|--only-untracked] [<diff-options>] [<stash>]::
+show [<options>] [<stash>]::
 
 	Show the changes recorded in the stash entry as a diff between the
 	stashed contents and the commit back when the stash entry was first
@@ -91,10 +91,8 @@ show [-u|--include-untracked|--only-untracked] [<diff-options>] [<stash>]::
 	By default, the command shows the diffstat, but it will accept any
 	format known to 'git diff' (e.g., `git stash show -p stash@{1}`
 	to view the second most recent entry in patch form).
-	If no `<diff-option>` is provided, the default behavior will be given
+	You can use stash.showStat and/or stash.showPatch config variables
-	by the `stash.showStat`, and `stash.showPatch` config variables. You
+	to change the default behavior.
-	can also use `stash.showIncludeUntracked` to set whether
-	`--include-untracked` is enabled by default.
 
 pop [--index] [-q|--quiet] [<stash>]::
 
@@ -162,18 +160,10 @@ up with `git clean`.
 
 -u::
 --include-untracked::
---no-include-untracked::
+	This option is only valid for `push` and `save` commands.
-	When used with the `push` and `save` commands,
-	all untracked files are also stashed and then cleaned up with
-	`git clean`.
 +
-When used with the `show` command, show the untracked files in the stash
+All untracked files are also stashed and then cleaned up with
-entry as part of the diff.
+`git clean`.
-
---only-untracked::
-	This option is only valid for the `show` command.
-+
-Show only the untracked files in the stash entry as part of the diff.
 
 --index::
 	This option is only valid for `pop` and `apply` commands.

Documentation/git-status.txt

@@ -130,7 +130,7 @@ ignored, then the directory is not shown, but all contents are shown.
 --column[=<options>]::
 --no-column::
 	Display untracked files in columns. See configuration variable
-	`column.status` for option syntax. `--column` and `--no-column`
+	column.status for option syntax.`--column` and `--no-column`
 	without options are equivalent to 'always' and 'never'
 	respectively.
 

Documentation/git-svn.txt

@@ -1061,6 +1061,25 @@ with different name spaces.  For example:
 	branches = stable/*:refs/remotes/svn/stable/*
 	branches = debug/*:refs/remotes/svn/debug/*
 
+BUGS
+----
+
+We ignore all SVN properties except svn:executable.  Any unhandled
+properties are logged to $GIT_DIR/svn/<refname>/unhandled.log
+
+Renamed and copied directories are not detected by Git and hence not
+tracked when committing to SVN.  I do not plan on adding support for
+this as it's quite difficult and time-consuming to get working for all
+the possible corner cases (Git doesn't do it, either).  Committing
+renamed and copied files is fully supported if they're similar enough
+for Git to detect them.
+
+In SVN, it is possible (though discouraged) to commit changes to a tag
+(because a tag is just a directory copy, thus technically the same as a
+branch). When cloning an SVN repository, 'git svn' cannot know if such a
+commit to a tag will happen in the future. Thus it acts conservatively
+and imports all SVN tags as branches, prefixing the tag name with 'tags/'.
+
 CONFIGURATION
 -------------
 
@@ -1147,25 +1166,6 @@ $GIT_DIR/svn/\**/.rev_map.*::
 if it is missing or not up to date.  'git svn reset' automatically
 rewinds it.
 
-BUGS
-----
-
-We ignore all SVN properties except svn:executable.  Any unhandled
-properties are logged to $GIT_DIR/svn/<refname>/unhandled.log
-
-Renamed and copied directories are not detected by Git and hence not
-tracked when committing to SVN.  I do not plan on adding support for
-this as it's quite difficult and time-consuming to get working for all
-the possible corner cases (Git doesn't do it, either).  Committing
-renamed and copied files is fully supported if they're similar enough
-for Git to detect them.
-
-In SVN, it is possible (though discouraged) to commit changes to a tag
-(because a tag is just a directory copy, thus technically the same as a
-branch). When cloning an SVN repository, 'git svn' cannot know if such a
-commit to a tag will happen in the future. Thus it acts conservatively
-and imports all SVN tags as branches, prefixing the tag name with 'tags/'.
-
 SEE ALSO
 --------
 linkgit:git-rebase[1]

Documentation/git-tag.txt

@@ -134,7 +134,7 @@ options for details.
 --column[=<options>]::
 --no-column::
 	Display tag listing in columns. See configuration variable
-	`column.tag` for option syntax. `--column` and `--no-column`
+	column.tag for option syntax.`--column` and `--no-column`
 	without options are equivalent to 'always' and 'never' respectively.
 +
 This option is only applicable when listing tags without annotation lines.

Documentation/git-worktree.txt

@@ -97,9 +97,8 @@ list::
 List details of each working tree.  The main working tree is listed first,
 followed by each of the linked working trees.  The output details include
 whether the working tree is bare, the revision currently checked out, the
-branch currently checked out (or "detached HEAD" if none), "locked" if
+branch currently checked out (or "detached HEAD" if none), and "locked" if
-the worktree is locked, "prunable" if the worktree can be pruned by `prune`
+the worktree is locked.
-command.
 
 lock::
 
@@ -144,11 +143,6 @@ locate it. Running `repair` within the recently-moved working tree will
 reestablish the connection. If multiple linked working trees are moved,
 running `repair` from any working tree with each tree's new `<path>` as
 an argument, will reestablish the connection to all the specified paths.
-+
-If both the main working tree and linked working trees have been moved
-manually, then running `repair` in the main working tree and specifying the
-new `<path>` of each linked working tree will reestablish all connections
-in both directions.
 
 unlock::
 
@@ -232,14 +226,9 @@ This can also be set up as the default behaviour by using the
 -v::
 --verbose::
 	With `prune`, report all removals.
-+
-With `list`, output additional information about worktrees (see below).
 
 --expire <time>::
 	With `prune`, only expire unused working trees older than `<time>`.
-+
-With `list`, annotate missing working trees as prunable if they are
-older than `<time>`.
 
 --reason <string>::
 	With `lock`, an explanation why the working tree is locked.
@@ -378,46 +367,13 @@ $ git worktree list
 /path/to/other-linked-worktree  1234abc  (detached HEAD)
 ------------
 
-The command also shows annotations for each working tree, according to its state.
-These annotations are:
-
- * `locked`, if the working tree is locked.
- * `prunable`, if the working tree can be pruned via `git worktree prune`.
-
-------------
-$ git worktree list
-/path/to/linked-worktree    abcd1234 [master]
-/path/to/locked-worktreee   acbd5678 (brancha) locked
-/path/to/prunable-worktree  5678abc  (detached HEAD) prunable
-------------
-
-For these annotations, a reason might also be available and this can be
-seen using the verbose mode. The annotation is then moved to the next line
-indented followed by the additional information.
-
-------------
-$ git worktree list --verbose
-/path/to/linked-worktree              abcd1234 [master]
-/path/to/locked-worktree-no-reason    abcd5678 (detached HEAD) locked
-/path/to/locked-worktree-with-reason  1234abcd (brancha)
-	locked: working tree path is mounted on a portable device
-/path/to/prunable-worktree            5678abc1 (detached HEAD)
-	prunable: gitdir file points to non-existent location
-------------
-
-Note that the annotation is moved to the next line if the additional
-information is available, otherwise it stays on the same line as the
-working tree itself.
-
 Porcelain Format
 ~~~~~~~~~~~~~~~~
 The porcelain format has a line per attribute.  Attributes are listed with a
 label and value separated by a single space.  Boolean attributes (like `bare`
 and `detached`) are listed as a label only, and are present only
-if the value is true.  Some attributes (like `locked`) can be listed as a label
+if the value is true.  The first attribute of a working tree is always
-only or with a value depending upon whether a reason is available.  The first
+`worktree`, an empty line indicates the end of the record.  For example:
-attribute of a working tree is always `worktree`, an empty line indicates the
-end of the record.  For example:
 
 ------------
 $ git worktree list --porcelain
@@ -432,33 +388,6 @@ worktree /path/to/other-linked-worktree
 HEAD 1234abc1234abc1234abc1234abc1234abc1234a
 detached
 
-worktree /path/to/linked-worktree-locked-no-reason
-HEAD 5678abc5678abc5678abc5678abc5678abc5678c
-branch refs/heads/locked-no-reason
-locked
-
-worktree /path/to/linked-worktree-locked-with-reason
-HEAD 3456def3456def3456def3456def3456def3456b
-branch refs/heads/locked-with-reason
-locked reason why is locked
-
-worktree /path/to/linked-worktree-prunable
-HEAD 1233def1234def1234def1234def1234def1234b
-detached
-prunable gitdir file points to non-existent location
-
-------------
-
-If the lock reason contains "unusual" characters such as newline, they
-are escaped and the entire reason is quoted as explained for the
-configuration variable `core.quotePath` (see linkgit:git-config[1]).
-For Example:
-
-------------
-$ git worktree list --porcelain
-...
-locked "reason\nwhy is locked"
-...
 ------------
 
 EXAMPLES

Documentation/git.txt

@@ -13,7 +13,7 @@ SYNOPSIS
     [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
     [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
     [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
-    [--super-prefix=<path>] [--config-env=<name>=<envvar>]
+    [--super-prefix=<path>]
     <command> [<args>]
 
 DESCRIPTION
@@ -80,28 +80,6 @@ config file). Including the equals but with an empty value (like `git -c
 foo.bar= ...`) sets `foo.bar` to the empty string which `git config
 --type=bool` will convert to `false`.
 
---config-env=<name>=<envvar>::
-	Like `-c <name>=<value>`, give configuration variable
-	'<name>' a value, where <envvar> is the name of an
-	environment variable from which to retrieve the value. Unlike
-	`-c` there is no shortcut for directly setting the value to an
-	empty string, instead the environment variable itself must be
-	set to the empty string.  It is an error if the `<envvar>` does not exist
-	in the environment. `<envvar>` may not contain an equals sign
-	to avoid ambiguity with `<name>` containing one.
-+
-This is useful for cases where you want to pass transitory
-configuration options to git, but are doing so on OS's where
-other processes might be able to read your cmdline
-(e.g. `/proc/self/cmdline`), but not your environ
-(e.g. `/proc/self/environ`). That behavior is the default on
-Linux, but may not be on your system.
-+
-Note that this might add security for variables such as
-`http.extraHeader` where the sensitive information is part of
-the value, but not e.g. `url.<base>.insteadOf` where the
-sensitive information can be part of the key.
-
 --exec-path[=<path>]::
 	Path to wherever your core Git programs are installed.
 	This can also be controlled by setting the GIT_EXEC_PATH
@@ -670,16 +648,6 @@ for further details.
 	If this environment variable is set to `0`, git will not prompt
 	on the terminal (e.g., when asking for HTTP authentication).
 
-`GIT_CONFIG_GLOBAL`::
-`GIT_CONFIG_SYSTEM`::
-	Take the configuration from the given files instead from global or
-	system-level configuration files. If `GIT_CONFIG_SYSTEM` is set, the
-	system config file defined at build time (usually `/etc/gitconfig`)
-	will not be read. Likewise, if `GIT_CONFIG_GLOBAL` is set, neither
-	`$HOME/.gitconfig` nor `$XDG_CONFIG_HOME/git/config` will be read. Can
-	be set to `/dev/null` to skip reading configuration files of the
-	respective level.
-
 `GIT_CONFIG_NOSYSTEM`::
 	Whether to skip reading settings from the system-wide
 	`$(prefix)/etc/gitconfig` file.  This environment variable can

Documentation/gitattributes.txt

@@ -845,8 +845,6 @@ patterns are available:
 
 - `rust` suitable for source code in the Rust language.
 
-- `scheme` suitable for source code in the Scheme language.
-
 - `tex` suitable for source code for LaTeX documents.
 
 
@@ -1176,8 +1174,7 @@ tag then no replacement will be done.  The placeholders are the same
 as those for the option `--pretty=format:` of linkgit:git-log[1],
 except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`
 in the file.  E.g. the string `$Format:%H$` will be replaced by the
-commit hash.  However, only one `%(describe)` placeholder is expanded
+commit hash.
-per archive to avoid denial-of-service attacks.
 
 
 Packing objects
@@ -1247,12 +1244,6 @@ to:
 [attr]binary -diff -merge -text
 ------------
 
-NOTES
------
-
-Git does not follow symbolic links when accessing a `.gitattributes`
-file in the working tree. This keeps behavior consistent when the file
-is accessed from the index or a tree versus from the filesystem.
 
 EXAMPLES
 --------

Documentation/gitdiffcore.txt

@@ -74,7 +74,6 @@ into another list.  There are currently 5 such transformations:
 - diffcore-merge-broken
 - diffcore-pickaxe
 - diffcore-order
-- diffcore-rotate
 
 These are applied in sequence.  The set of filepairs 'git diff-{asterisk}'
 commands find are used as the input to diffcore-break, and
@@ -169,26 +168,6 @@ a similarity score different from the default of 50% by giving a
 number after the "-M" or "-C" option (e.g. "-M8" to tell it to use
 8/10 = 80%).
 
-Note that when rename detection is on but both copy and break
-detection are off, rename detection adds a preliminary step that first
-checks if files are moved across directories while keeping their
-filename the same.  If there is a file added to a directory whose
-contents is sufficiently similar to a file with the same name that got
-deleted from a different directory, it will mark them as renames and
-exclude them from the later quadratic step (the one that pairwise
-compares all unmatched files to find the "best" matches, determined by
-the highest content similarity).  So, for example, if a deleted
-docs/ext.txt and an added docs/config/ext.txt are similar enough, they
-will be marked as a rename and prevent an added docs/ext.md that may
-be even more similar to the deleted docs/ext.txt from being considered
-as the rename destination in the later step.  For this reason, the
-preliminary "match same filename" step uses a bit higher threshold to
-mark a file pair as a rename and stop considering other candidates for
-better matches.  At most, one comparison is done per file in this
-preliminary pass; so if there are several remaining ext.txt files
-throughout the directory hierarchy after exact rename detection, this
-preliminary step may be skipped for those files.
-
 Note.  When the "-C" option is used with `--find-copies-harder`
 option, 'git diff-{asterisk}' commands feed unmodified filepairs to
 diffcore mechanism as well as modified ones.  This lets the copy
@@ -297,26 +276,6 @@ Documentation
 t
 ------------------------------------------------
 
-diffcore-rotate: For Changing At Which Path Output Starts
----------------------------------------------------------
-
-This transformation takes one pathname, and rotates the set of
-filepairs so that the filepair for the given pathname comes first,
-optionally discarding the paths that come before it.  This is used
-to implement the `--skip-to` and the `--rotate-to` options.  It is
-an error when the specified pathname is not in the set of filepairs,
-but it is not useful to error out when used with "git log" family of
-commands, because it is unreasonable to expect that a given path
-would be modified by each and every commit shown by the "git log"
-command.  For this reason, when used with "git log", the filepair
-that sorts the same as, or the first one that sorts after, the given
-pathname is where the output starts.
-
-Use of this transformation combined with diffcore-order will produce
-unexpected results, as the input to this transformation is likely
-not sorted when diffcore-order is in effect.
-
-
 SEE ALSO
 --------
 linkgit:git-diff[1],

Documentation/githooks.txt

@@ -138,7 +138,7 @@ given); `template` (if a `-t` option was given or the
 configuration option `commit.template` is set); `merge` (if the
 commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
 (if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
-a commit object name (if a `-c`, `-C` or `--amend` option was given).
+a commit SHA-1 (if a `-c`, `-C` or `--amend` option was given).
 
 If the exit status is non-zero, `git commit` will abort.
 
@@ -231,19 +231,19 @@ named remote is not being used both values will be the same.
 Information about what is to be pushed is provided on the hook's standard
 input with lines of the form:
 
-  <local ref> SP <local object name> SP <remote ref> SP <remote object name> LF
+  <local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF
 
 For instance, if the command +git push origin master:foreign+ were run the
 hook would receive a line like the following:
 
   refs/heads/master 67890 refs/heads/foreign 12345
 
-although the full object name would be supplied.  If the foreign ref does not
+although the full, 40-character SHA-1s would be supplied.  If the foreign ref
-yet exist the `<remote object name>` will be the all-zeroes object name.  If a
+does not yet exist the `<remote SHA-1>` will be 40 `0`.  If a ref is to be
-ref is to be deleted, the `<local ref>` will be supplied as `(delete)` and the
+deleted, the `<local ref>` will be supplied as `(delete)` and the `<local
-`<local object name>` will be the all-zeroes object name.  If the local commit
+SHA-1>` will be 40 `0`.  If the local commit was specified by something other
-was specified by something other than a name which could be expanded (such as
+than a name which could be expanded (such as `HEAD~`, or a SHA-1) it will be
-`HEAD~`, or an object name) it will be supplied as it was originally given.
+supplied as it was originally given.
 
 If this hook exits with a non-zero status, `git push` will abort without
 pushing anything.  Information about why the push is rejected may be sent
@@ -268,7 +268,7 @@ input a line of the format:
 where `<old-value>` is the old object name stored in the ref,
 `<new-value>` is the new object name to be stored in the ref and
 `<ref-name>` is the full name of the ref.
-When creating a new ref, `<old-value>` is the all-zeroes object name.
+When creating a new ref, `<old-value>` is 40 `0`.
 
 If the hook exits with non-zero status, none of the refs will be
 updated. If the hook exits with zero, updating of individual refs can
@@ -473,8 +473,7 @@ reference-transaction
 
 This hook is invoked by any Git command that performs reference
 updates. It executes whenever a reference transaction is prepared,
-committed or aborted and may thus get called multiple times. The hook
+committed or aborted and may thus get called multiple times.
-does not cover symbolic references (but that may change in the future).
 
 The hook takes exactly one argument, which is the current state the
 given reference transaction is in:
@@ -493,14 +492,6 @@ receives on standard input a line of the format:
 
   <old-value> SP <new-value> SP <ref-name> LF
 
-where `<old-value>` is the old object name passed into the reference
-transaction, `<new-value>` is the new object name to be stored in the
-ref and `<ref-name>` is the full name of the ref. When force updating
-the reference regardless of its current value or when the reference is
-to be created anew, `<old-value>` is the all-zeroes object name. To
-distinguish these cases, you can inspect the current value of
-`<ref-name>` via `git rev-parse`.
-
 The exit status of the hook is ignored for any state except for the
 "prepared" state. In the "prepared" state, a non-zero exit status will
 cause the transaction to be aborted. The hook will not be called with
@@ -559,7 +550,7 @@ command-dependent arguments may be passed in the future.
 The hook receives a list of the rewritten commits on stdin, in the
 format
 
-  <old-object-name> SP <new-object-name> [ SP <extra-info> ] LF
+  <old-sha1> SP <new-sha1> [ SP <extra-info> ] LF
 
 The 'extra-info' is again command-dependent.  If it is empty, the
 preceding SP is also omitted.  Currently, no commands pass any
@@ -575,7 +566,7 @@ rebase::
 	For the 'squash' and 'fixup' operation, all commits that were
 	squashed are listed as being rewritten to the squashed commit.
 	This means that there will be several lines sharing the same
-	'new-object-name'.
+	'new-sha1'.
 +
 The commits are guaranteed to be listed in the order that they were
 processed by rebase.

Documentation/gitignore.txt

@@ -149,15 +149,11 @@ not tracked by Git remain untracked.
 To stop tracking a file that is currently tracked, use
 'git rm --cached'.
 
-Git does not follow symbolic links when accessing a `.gitignore` file in
-the working tree. This keeps behavior consistent when the file is
-accessed from the index or a tree versus from the filesystem.
-
 EXAMPLES
 --------
 
  - The pattern `hello.*` matches any file or folder
-   whose name begins with `hello.`. If one wants to restrict
+   whose name begins with `hello`. If one wants to restrict
    this only to the directory and not in its subdirectories,
    one can prepend the pattern with a slash, i.e. `/hello.*`;
    the pattern now matches `hello.txt`, `hello.c` but not

Documentation/gitmailmap.txt

@@ -1,130 +0,0 @@
-gitmailmap(5)
-=============
-
-NAME
-----
-gitmailmap - Map author/committer names and/or E-Mail addresses
-
-SYNOPSIS
---------
-$GIT_WORK_TREE/.mailmap
-
-
-DESCRIPTION
------------
-
-If the file `.mailmap` exists at the toplevel of the repository, or at
-the location pointed to by the `mailmap.file` or `mailmap.blob`
-configuration options (see linkgit:git-config[1]), it
-is used to map author and committer names and email addresses to
-canonical real names and email addresses.
-
-
-SYNTAX
-------
-
-The '#' character begins a comment to the end of line, blank lines
-are ignored.
-
-In the simple form, each line in the file consists of the canonical
-real name of an author, whitespace, and an email address used in the
-commit (enclosed by '<' and '>') to map to the name. For example:
---
-	Proper Name <commit@email.xx>
---
-
-The more complex forms are:
---
-	<proper@email.xx> <commit@email.xx>
---
-which allows mailmap to replace only the email part of a commit, and:
---
-	Proper Name <proper@email.xx> <commit@email.xx>
---
-which allows mailmap to replace both the name and the email of a
-commit matching the specified commit email address, and:
---
-	Proper Name <proper@email.xx> Commit Name <commit@email.xx>
---
-which allows mailmap to replace both the name and the email of a
-commit matching both the specified commit name and email address.
-
-Both E-Mails and names are matched case-insensitively. For example
-this would also match the 'Commit Name <commit&#64;email.xx>' above:
---
-	Proper Name <proper@email.xx> CoMmIt NaMe <CoMmIt@EmAiL.xX>
---
-
-NOTES
------
-
-Git does not follow symbolic links when accessing a `.mailmap` file in
-the working tree. This keeps behavior consistent when the file is
-accessed from the index or a tree versus from the filesystem.
-
-EXAMPLES
---------
-
-Your history contains commits by two authors, Jane
-and Joe, whose names appear in the repository under several forms:
-
-------------
-Joe Developer <joe@example.com>
-Joe R. Developer <joe@example.com>
-Jane Doe <jane@example.com>
-Jane Doe <jane@laptop.(none)>
-Jane D. <jane@desktop.(none)>
-------------
-
-Now suppose that Joe wants his middle name initial used, and Jane
-prefers her family name fully spelled out. A `.mailmap` file to
-correct the names would look like:
-
-------------
-Joe R. Developer <joe@example.com>
-Jane Doe <jane@example.com>
-Jane Doe <jane@desktop.(none)>
-------------
-
-Note that there's no need to map the name for '<jane&#64;laptop.(none)>' to
-only correct the names. However, leaving the obviously broken
-'<jane&#64;laptop.(none)>' and '<jane&#64;desktop.(none)>' E-Mails as-is is
-usually not what you want. A `.mailmap` file which also corrects those
-is:
-
-------------
-Joe R. Developer <joe@example.com>
-Jane Doe <jane@example.com> <jane@laptop.(none)>
-Jane Doe <jane@example.com> <jane@desktop.(none)>
-------------
-
-Finally, let's say that Joe and Jane shared an E-Mail address, but not
-a name, e.g. by having these two commits in the history generated by a
-bug reporting system. I.e. names appearing in history as:
-
-------------
-Joe <bugs@example.com>
-Jane <bugs@example.com>
-------------
-
-A full `.mailmap` file which also handles those cases (an addition of
-two lines to the above example) would be:
-
-------------
-Joe R. Developer <joe@example.com>
-Jane Doe <jane@example.com> <jane@laptop.(none)>
-Jane Doe <jane@example.com> <jane@desktop.(none)>
-Joe R. Developer <joe@example.com> Joe <bugs@example.com>
-Jane Doe <jane@example.com> Jane <bugs@example.com>
-------------
-
-
-
-SEE ALSO
---------
-linkgit:git-check-mailmap[1]
-
-
-GIT
----
-Part of the linkgit:git[1] suite

Documentation/gitmodules.txt

@@ -98,14 +98,6 @@ submodule.<name>.shallow::
 	shallow clone (with a history depth of 1) unless the user explicitly
 	asks for a non-shallow clone.
 
-NOTES
------
-
-Git does not allow the `.gitmodules` file within a working tree to be a
-symbolic link, and will refuse to check out such a tree entry. This
-keeps behavior consistent when the file is accessed from the index or a
-tree versus from the filesystem, and helps Git reliably enforce security
-checks of the file contents.
 
 EXAMPLES
 --------

Documentation/gitnamespaces.txt

@@ -62,7 +62,3 @@ git clone ext::'git --namespace=foo %s /tmp/prefixed.git'
 ----------
 
 include::transfer-data-leaks.txt[]
-
-GIT
----
-Part of the linkgit:git[1] suite

Documentation/gitweb.conf.txt

@@ -751,17 +751,6 @@ default font sizes or lineheights are changed (e.g. via adding extra
 CSS stylesheet in `@stylesheets`), it may be appropriate to change
 these values.
 
-email-privacy::
-	Redact e-mail addresses from the generated HTML, etc. content.
-	This obscures e-mail addresses retrieved from the author/committer
-	and comment sections of the Git log.
-	It is meant to hinder web crawlers that harvest and abuse addresses.
-	Such crawlers may not respect robots.txt.
-	Note that users and user tools also see the addresses as redacted.
-	If Gitweb is not the final step in a workflow then subsequent steps
-	may misbehave because of the redacted information they receive.
-	Disabled by default.
-
 highlight::
 	Server-side syntax highlight support in "blob" view.  It requires
 	`$highlight_bin` program to be available (see the description of

Documentation/howto/coordinate-embargoed-releases.txt

@@ -1,131 +0,0 @@
-Content-type: text/asciidoc
-Abstract: When a critical vulnerability is discovered and fixed, we follow this
- script to coordinate a public release.
-
-How we coordinate embargoed releases
-====================================
-
-To protect Git users from critical vulnerabilities, we do not just release
-fixed versions like regular maintenance releases. Instead, we coordinate
-releases with packagers, keeping the fixes under an embargo until the release
-date. That way, users will have a chance to upgrade on that date, no matter
-what Operating System or distribution they run.
-
-Open a Security Advisory draft
-------------------------------
-
-The first step is to https://github.com/git/git/security/advisories/new[open an
-advisory]. Technically, it is not necessary, but it is convenient and saves a
-bit of hassle. This advisory can also be used to obtain the CVE number and it
-will give us a private fork associated with it that can be used to collaborate
-on a fix.
-
-Release date of the embargoed version
--------------------------------------
-
-If the vulnerability affects Windows users, we want to have our friends over at
-Visual Studio on board. This means we need to target a "Patch Tuesday" (i.e. a
-second Tuesday of the month), at the minimum three weeks from heads-up to
-coordinated release.
-
-If the vulnerability affects the server side, or can benefit from scans on the
-server side (i.e. if `git fsck` can detect an attack), it is important to give
-all involved Git repository hosting sites enough time to scan all of those
-repositories.
-
-Notifying the Linux distributions
----------------------------------
-
-At most two weeks before release date, we need to send a notification to
-distros@vs.openwall.org, preferably less than 7 days before the release date.
-This will reach most (all?) Linux distributions. See an example below, and the
-guidelines for this mailing list at
-https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists[here].
-
-Once the version has been published, we send a note about that to oss-security.
-As an example, see https://www.openwall.com/lists/oss-security/2019/12/13/1[the
-v2.24.1 mail];
-https://oss-security.openwall.org/wiki/mailing-lists/oss-security[Here] are
-their guidelines.
-
-The mail to oss-security should also describe the exploit, and give credit to
-the reporter(s): security researchers still receive too little respect for the
-invaluable service they provide, and public credit goes a long way to keep them
-paid by their respective organizations.
-
-Technically, describing any exploit can be delayed up to 7 days, but we usually
-refrain from doing that, including it right away.
-
-As a courtesy we typically attach a Git bundle (as `.tar.xz` because the list
-will drop `.bundle` attachments) in the mail to distros@ so that the involved
-parties can take care of integrating/backporting them. This bundle is typically
-created using a command like this:
-
-	git bundle create cve-xxx.bundle ^origin/master vA.B.C vD.E.F
-	tar cJvf cve-xxx.bundle.tar.xz cve-xxx.bundle
-
-Example mail to distros@vs.openwall.org
----------------------------------------
-
-....
-To: distros@vs.openwall.org
-Cc: git-security@googlegroups.com, <other people involved in the report/fix>
-Subject: [vs] Upcoming Git security fix release
-
-Team,
-
-The Git project will release new versions on <date> at 10am Pacific Time or
-soon thereafter. I have attached a Git bundle (embedded in a `.tar.xz` to avoid
-it being dropped) which you can fetch into a clone of
-https://github.com/git/git via `git fetch --tags /path/to/cve-xxx.bundle`,
-containing the tags for versions <versions>.
-
-You can verify with `git tag -v <tag>` that the versions were signed by
-the Git maintainer, using the same GPG key as e.g. v2.24.0.
-
-Please use these tags to prepare `git` packages for your various
-distributions, using the appropriate tagged versions. The added test cases
-help verify the correctness.
-
-The addressed issues are:
-
-<list of CVEs with a short description, typically copy/pasted from Git's
-release notes, usually demo exploit(s), too>
-
-Credit for finding the vulnerability goes to <reporter>, credit for fixing
-it goes to <developer>.
-
-Thanks,
-<name>
-
-....
-
-Example mail to oss-security@lists.openwall.com
------------------------------------------------
-
-....
-To: oss-security@lists.openwall.com
-Cc: git-security@googlegroups.com, <other people involved in the report/fix>
-Subject: git: <copy from security advisory>
-
-Team,
-
-The Git project released new versions on <date>, addressing <CVE>.
-
-All supported platforms are affected in one way or another, and all Git
-versions all the way back to <version> are affected. The fixed versions are:
-<versions>.
-
-Link to the announcement: <link to lore.kernel.org/git>
-
-We highly recommend to upgrade.
-
-The addressed issues are:
-* <list of CVEs and their explanations, along with demo exploits>
-
-Credit for finding the vulnerability goes to <reporter>, credit for fixing
-it goes to <developer>.
-
-Thanks,
-<name>
-....

Documentation/i18n.txt

@@ -38,7 +38,7 @@ mind.
   a warning if the commit log message given to it does not look
   like a valid UTF-8 string, unless you explicitly say your
   project uses a legacy encoding.  The way to say this is to
-  have `i18n.commitEncoding` in `.git/config` file, like this:
+  have i18n.commitencoding in `.git/config` file, like this:
 +
 ------------
 [i18n]