Compare commits

..

29 Commits

Author SHA1 Message Date
868154bb1c Git 2.35.5
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06 17:44:02 -04:00
ac8a1db867 Sync with 2.34.5
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06 17:43:37 -04:00
be85cfc4db Git 2.34.5
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06 17:43:08 -04:00
478a426f14 Sync with 2.33.5
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06 17:42:55 -04:00
7800e1dccf Git 2.33.5
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06 17:42:27 -04:00
3957f3c84e Sync with 2.32.4
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06 17:42:02 -04:00
af778cd9be Git 2.32.4
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06 17:41:15 -04:00
9cbd2827c5 Sync with 2.31.5
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06 17:40:44 -04:00
ecf9b4a443 Git 2.31.5
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06 17:39:26 -04:00
122512967e Sync with 2.30.6
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06 17:39:15 -04:00
abd4d67ab0 Git 2.30.6
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06 17:38:16 -04:00
ef374dd9b8 t2080: prepare for changing protocol.file.allow
Explicitly cloning over the "file://" protocol in t1092 in preparation
for merging a security release which will change the default value of
this configuration to be "user".

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:30:45 -04:00
092d3a2bf9 t1092: prepare for changing protocol.file.allow
Explicitly cloning over the "file://" protocol in t1092 in preparation
for merging a security release which will change the default value of
this configuration to be "user".

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:30:43 -04:00
067aa8fb41 t2080: prepare for changing protocol.file.allow
Explicitly cloning over the "file://" protocol in t1092 in preparation
for merging a security release which will change the default value of
this configuration to be "user".

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:27:18 -04:00
4a7dab5ce4 t1092: prepare for changing protocol.file.allow
Explicitly cloning over the "file://" protocol in t1092 in preparation
for merging a security release which will change the default value of
this configuration to be "user".

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:27:14 -04:00
0ca6ead81e alias.c: reject too-long cmdline strings in split_cmdline()
This function improperly uses an int to represent the number of entries
in the resulting argument array. This allows a malicious actor to
intentionally overflow the return value, leading to arbitrary heap
writes.

Because the resulting argv array is typically passed to execv(), it may
be possible to leverage this attack to gain remote code execution on a
victim machine. This was almost certainly the case for certain
configurations of git-shell until the previous commit limited the size
of input it would accept. Other calls to split_cmdline() are typically
limited by the size of argv the OS is willing to hand us, so are
similarly protected.

So this is not strictly fixing a known vulnerability, but is a hardening
of the function that is worth doing to protect against possible unknown
vulnerabilities.

One approach to fixing this would be modifying the signature of
`split_cmdline()` to look something like:

    int split_cmdline(char *cmdline, const char ***argv, size_t *argc);

Where the return value of `split_cmdline()` is negative for errors, and
zero otherwise. If non-NULL, the `*argc` pointer is modified to contain
the size of the `**argv` array.

But this implies an absurdly large `argv` array, which more than likely
larger than the system's argument limit. So even if split_cmdline()
allowed this, it would fail immediately afterwards when we called
execv(). So instead of converting all of `split_cmdline()`'s callers to
work with `size_t` types in this patch, instead pursue the minimal fix
here to prevent ever returning an array with more than INT_MAX entries
in it.

Signed-off-by: Kevin Backhouse <kevinbackhouse@github.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
71ad7fe1bc shell: limit size of interactive commands
When git-shell is run in interactive mode (which must be enabled by
creating $HOME/git-shell-commands), it reads commands from stdin, one
per line, and executes them.

We read the commands with git_read_line_interactively(), which uses a
strbuf under the hood. That means we'll accept an input of arbitrary
size (limited only by how much heap we can allocate). That creates two
problems:

  - the rest of the code is not prepared to handle large inputs. The
    most serious issue here is that split_cmdline() uses "int" for most
    of its types, which can lead to integer overflow and out-of-bounds
    array reads and writes. But even with that fixed, we assume that we
    can feed the command name to snprintf() (via xstrfmt()), which is
    stuck for historical reasons using "int", and causes it to fail (and
    even trigger a BUG() call).

  - since the point of git-shell is to take input from untrusted or
    semi-trusted clients, it's a mild denial-of-service. We'll allocate
    as many bytes as the client sends us (actually twice as many, since
    we immediately duplicate the buffer).

We can fix both by just limiting the amount of per-command input we're
willing to receive.

We should also fix split_cmdline(), of course, which is an accident
waiting to happen, but that can come on top. Most calls to
split_cmdline(), including the other one in git-shell, are OK because
they are reading from an OS-provided argv, which is limited in practice.
This patch should eliminate the immediate vulnerabilities.

I picked 4MB as an arbitrary limit. It's big enough that nobody should
ever run into it in practice (since the point is to run the commands via
exec, we're subject to OS limits which are typically much lower). But
it's small enough that allocating it isn't that big a deal.

The code is mostly just swapping out fgets() for the strbuf call, but we
have to add a few niceties like flushing and trimming line endings. We
could simplify things further by putting the buffer on the stack, but
4MB is probably a bit much there. Note that we'll _always_ allocate 4MB,
which for normal, non-malicious requests is more than we would before
this patch. But on the other hand, other git programs are happy to use
96MB for a delta cache. And since we'd never touch most of those pages,
on a lazy-allocating OS like Linux they won't even get allocated to
actual RAM.

The ideal would be a version of strbuf_getline() that accepted a maximum
value. But for a minimal vulnerability fix, let's keep things localized
and simple. We can always refactor further on top.

The included test fails in an obvious way with ASan or UBSan (which
notice the integer overflow and out-of-bounds reads). Without them, it
fails in a less obvious way: we may segfault, or we may try to xstrfmt()
a long string, leading to a BUG(). Either way, it fails reliably before
this patch, and passes with it. Note that we don't need an EXPENSIVE
prereq on it. It does take 10-15s to fail before this patch, but with
the new limit, we fail almost immediately (and the perl process
generating 2GB of data exits via SIGPIPE).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
32696a4cbe shell: add basic tests
We have no tests of even basic functionality of git-shell. Let's add a
couple of obvious ones. This will serve as a framework for adding tests
for new things we fix, as well as making sure we don't screw anything up
too badly while doing so.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
a1d4f67c12 transport: make protocol.file.allow be "user" by default
An earlier patch discussed and fixed a scenario where Git could be used
as a vector to exfiltrate sensitive data through a Docker container when
a potential victim clones a suspicious repository with local submodules
that contain symlinks.

That security hole has since been plugged, but a similar one still
exists.  Instead of convincing a would-be victim to clone an embedded
submodule via the "file" protocol, an attacker could convince an
individual to clone a repository that has a submodule pointing to a
valid path on the victim's filesystem.

For example, if an individual (with username "foo") has their home
directory ("/home/foo") stored as a Git repository, then an attacker
could exfiltrate data by convincing a victim to clone a malicious
repository containing a submodule pointing at "/home/foo/.git" with
`--recurse-submodules`. Doing so would expose any sensitive contents in
stored in "/home/foo" tracked in Git.

For systems (such as Docker) that consider everything outside of the
immediate top-level working directory containing a Dockerfile as
inaccessible to the container (with the exception of volume mounts, and
so on), this is a violation of trust by exposing unexpected contents in
the working copy.

To mitigate the likelihood of this kind of attack, adjust the "file://"
protocol's default policy to be "user" to prevent commands that execute
without user input (including recursive submodule initialization) from
taking place by default.

Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
f4a32a550f t/t9NNN: allow local submodules
To prepare for the default value of `protocol.file.allow` to change to
"user", ensure tests that rely on local submodules can initialize them
over the file protocol.

Tests that interact with submodules a handful of times use
`test_config_global`.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
0d3beb71da t/t7NNN: allow local submodules
To prepare for the default value of `protocol.file.allow` to change to
"user", ensure tests that rely on local submodules can initialize them
over the file protocol.

Tests that only need to interact with submodules in a limited capacity
have individual Git commands annotated with the appropriate
configuration via `-c`. Tests that interact with submodules a handful of
times use `test_config_global` instead. Test scripts that rely on
submodules throughout use a `git config --global` during a setup test
towards the beginning of the script.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
0f21b8f468 t/t6NNN: allow local submodules
To prepare for the default value of `protocol.file.allow` to change to
"user", ensure tests that rely on local submodules can initialize them
over the file protocol.

Tests that only need to interact with submodules in a limited capacity
have individual Git commands annotated with the appropriate
configuration via `-c`.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
225d2d50cc t/t5NNN: allow local submodules
To prepare for the default value of `protocol.file.allow` to change to
"user", ensure tests that rely on local submodules can initialize them
over the file protocol.

Tests that only need to interact with submodules in a limited capacity
have individual Git commands annotated with the appropriate
configuration via `-c`. Tests that interact with submodules a handful of
times use `test_config_global` instead. Test scripts that rely on
submodules throughout use a `git config --global` during a setup test
towards the beginning of the script.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
ac7e57fa28 t/t4NNN: allow local submodules
To prepare for the default value of `protocol.file.allow` to change to
"user", ensure tests that rely on local submodules can initialize them
over the file protocol.

Tests that only need to interact with submodules in a limited capacity
have individual Git commands annotated with the appropriate
configuration via `-c`. Tests that interact with submodules a handful of
times use `test_config_global` instead. Test scripts that rely on
submodules throughout use a `git config --global` during a setup test
towards the beginning of the script.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
f8d510ed0b t/t3NNN: allow local submodules
To prepare for the default value of `protocol.file.allow` to change to
"user", ensure tests that rely on local submodules can initialize them
over the file protocol.

Tests that only need to interact with submodules in a limited capacity
have individual Git commands annotated with the appropriate
configuration via `-c`. Tests that interact with submodules a handful of
times use `test_config_global` instead. Test scripts that rely on
submodules throughout use a `git config --global` during a setup test
towards the beginning of the script.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
99f4abb8da t/2NNNN: allow local submodules
To prepare for the default value of `protocol.file.allow` to change to
"user", ensure tests that rely on local submodules can initialize them
over the file protocol.

Tests that only need to interact with submodules in a limited capacity
have individual Git commands annotated with the appropriate
configuration via `-c`. Tests that interact with submodules a handful of
times use `test_config_global` instead. Test scripts that rely on
submodules throughout use a `git config --global` during a setup test
towards the beginning of the script.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
8a96dbcb33 t/t1NNN: allow local submodules
To prepare for the default value of `protocol.file.allow` to change to
"user", ensure tests that rely on local submodules can initialize them
over the file protocol.

Tests that only need to interact with submodules in a limited capacity
have individual Git commands annotated with the appropriate
configuration via `-c`. Tests that interact with submodules a handful of
times use `test_config_global` instead.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
7de0c306f7 t/lib-submodule-update.sh: allow local submodules
To prepare for changing the default value of `protocol.file.allow` to
"user", update the `prolog()` function in lib-submodule-update to allow
submodules to be cloned over the file protocol.

This is used by a handful of submodule-related test scripts, which
themselves will have to tweak the value of `protocol.file.allow` in
certain locations. Those will be done in subsequent commits.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
6f054f9fb3 builtin/clone.c: disallow --local clones with symlinks
When cloning a repository with `--local`, Git relies on either making a
hardlink or copy to every file in the "objects" directory of the source
repository. This is done through the callpath `cmd_clone()` ->
`clone_local()` -> `copy_or_link_directory()`.

The way this optimization works is by enumerating every file and
directory recursively in the source repository's `$GIT_DIR/objects`
directory, and then either making a copy or hardlink of each file. The
only exception to this rule is when copying the "alternates" file, in
which case paths are rewritten to be absolute before writing a new
"alternates" file in the destination repo.

One quirk of this implementation is that it dereferences symlinks when
cloning. This behavior was most recently modified in 36596fd2df (clone:
better handle symlinked files at .git/objects/, 2019-07-10), which
attempted to support `--local` clones of repositories with symlinks in
their objects directory in a platform-independent way.

Unfortunately, this behavior of dereferencing symlinks (that is,
creating a hardlink or copy of the source's link target in the
destination repository) can be used as a component in attacking a
victim by inadvertently exposing the contents of file stored outside of
the repository.

Take, for example, a repository that stores a Dockerfile and is used to
build Docker images. When building an image, Docker copies the directory
contents into the VM, and then instructs the VM to execute the
Dockerfile at the root of the copied directory. This protects against
directory traversal attacks by copying symbolic links as-is without
dereferencing them.

That is, if a user has a symlink pointing at their private key material
(where the symlink is present in the same directory as the Dockerfile,
but the key itself is present outside of that directory), the key is
unreadable to a Docker image, since the link will appear broken from the
container's point of view.

This behavior enables an attack whereby a victim is convinced to clone a
repository containing an embedded submodule (with a URL like
"file:///proc/self/cwd/path/to/submodule") which has a symlink pointing
at a path containing sensitive information on the victim's machine. If a
user is tricked into doing this, the contents at the destination of
those symbolic links are exposed to the Docker image at runtime.

One approach to preventing this behavior is to recreate symlinks in the
destination repository. But this is problematic, since symlinking the
objects directory are not well-supported. (One potential problem is that
when sharing, e.g. a "pack" directory via symlinks, different writers
performing garbage collection may consider different sets of objects to
be reachable, enabling a situation whereby garbage collecting one
repository may remove reachable objects in another repository).

Instead, prohibit the local clone optimization when any symlinks are
present in the `$GIT_DIR/objects` directory of the source repository.
Users may clone the repository again by prepending the "file://" scheme
to their clone URL, or by adding the `--no-local` option to their `git
clone` invocation.

The directory iterator used by `copy_or_link_directory()` must no longer
dereference symlinks (i.e., it *must* call `lstat()` instead of `stat()`
in order to discover whether or not there are symlinks present). This has
no bearing on the overall behavior, since we will immediately `die()` on
encounter a symlink.

Note that t5604.33 suggests that we do support local clones with
symbolic links in the source repository's objects directory, but this
was likely unintentional, or at least did not take into consideration
the problem with sharing parts of the objects directory with symbolic
links at the time. Update this test to reflect which options are and
aren't supported.

Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01 00:23:38 -04:00
1291 changed files with 248747 additions and 222073 deletions

View File

@ -9,7 +9,7 @@ freebsd_12_task:
DEFAULT_TEST_TARGET: prove
DEVELOPER: 1
freebsd_instance:
image_family: freebsd-12-3
image_family: freebsd-12-2
memory: 2G
install_script:
pkg install -y gettext gmake perl5

View File

@ -119,8 +119,8 @@ jobs:
- name: test
shell: bash
run: . /etc/profile && ci/run-test-slice.sh ${{matrix.nr}} 10
- name: print test failures
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
- name: ci/print-test-failures.sh
if: failure()
shell: bash
run: ci/print-test-failures.sh
- name: Upload failed tests' directories
@ -204,8 +204,8 @@ jobs:
env:
NO_SVN_TESTS: 1
run: . /etc/profile && ci/run-test-slice.sh ${{matrix.nr}} 10
- name: print test failures
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
- name: ci/print-test-failures.sh
if: failure()
shell: bash
run: ci/print-test-failures.sh
- name: Upload failed tests' directories
@ -261,10 +261,8 @@ jobs:
- uses: actions/checkout@v2
- run: ci/install-dependencies.sh
- run: ci/run-build-and-tests.sh
- name: print test failures
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
shell: bash
run: ci/print-test-failures.sh
- run: ci/print-test-failures.sh
if: failure()
- name: Upload failed tests' directories
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
uses: actions/upload-artifact@v2
@ -294,10 +292,8 @@ jobs:
- uses: actions/checkout@v1
- run: ci/install-docker-dependencies.sh
- run: ci/run-build-and-tests.sh
- name: print test failures
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
shell: bash
run: ci/print-test-failures.sh
- run: ci/print-test-failures.sh
if: failure()
- name: Upload failed tests' directories
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
uses: actions/upload-artifact@v1
@ -309,7 +305,7 @@ jobs:
if: needs.ci-config.outputs.enabled == 'yes'
env:
jobname: StaticAnalysis
runs-on: ubuntu-22.04
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v2
- run: ci/install-dependencies.sh

8
.gitignore vendored
View File

@ -53,7 +53,6 @@
/git-cvsimport
/git-cvsserver
/git-daemon
/git-diagnose
/git-diff
/git-diff-files
/git-diff-index
@ -73,13 +72,11 @@
/git-format-patch
/git-fsck
/git-fsck-objects
/git-fsmonitor--daemon
/git-gc
/git-get-tar-commit-id
/git-grep
/git-hash-object
/git-help
/git-hook
/git-http-backend
/git-http-fetch
/git-http-push
@ -181,14 +178,11 @@
/git-verify-commit
/git-verify-pack
/git-verify-tag
/git-version
/git-web--browse
/git-whatchanged
/git-worktree
/git-write-tree
/scalar
/git-core-*/?*
/git.res
/gitweb/GITWEB-BUILD-OPTIONS
/gitweb/gitweb.cgi
/gitweb/static/gitweb.js
@ -204,7 +198,6 @@
*.[aos]
*.o.json
*.py[co]
.build/
.depend/
*.gcda
*.gcno
@ -229,6 +222,7 @@
*.hcc
*.obj
*.lib
*.res
*.sln
*.sp
*.suo

View File

@ -59,9 +59,8 @@ David Reiss <dreiss@facebook.com> <dreiss@dreiss-vmware.(none)>
David S. Miller <davem@davemloft.net>
David Turner <novalis@novalis.org> <dturner@twopensource.com>
David Turner <novalis@novalis.org> <dturner@twosigma.com>
Derrick Stolee <derrickstolee@github.com> <stolee@gmail.com>
Derrick Stolee <derrickstolee@github.com> Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Derrick Stolee <derrickstolee@github.com> <dstolee@microsoft.com>
Derrick Stolee <dstolee@microsoft.com> <stolee@gmail.com>
Derrick Stolee <dstolee@microsoft.com> Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Deskin Miller <deskinm@umich.edu>
Đoàn Trần Công Danh <congdanhqx@gmail.com> Doan Tran Cong Danh
Dirk Süsserott <newsletter@dirk.my1.cc>

View File

@ -70,8 +70,8 @@ git@sfconservancy.org, or individually:
- Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Christian Couder <christian.couder@gmail.com>
- Jeff King <peff@peff.net>
- Junio C Hamano <gitster@pobox.com>
- Taylor Blau <me@ttaylorr.com>
All complaints will be reviewed and investigated promptly and fairly.

View File

@ -26,13 +26,6 @@ code. For Git in general, a few rough rules are:
go and fix it up."
Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
- Log messages to explain your changes are as important as the
changes themselves. Clearly written code and in-code comments
explain how the code works and what is assumed from the surrounding
context. The log messages explain what the changes wanted to
achieve and why the changes were necessary (more on this in the
accompanying SubmittingPatches document).
Make your code readable and sensible, and don't try to be clever.
As for more concrete guidelines, just imitate the existing code
@ -43,10 +36,7 @@ the overall style of existing code. Modifications to existing
code is expected to match the style the surrounding code already
uses (even if it doesn't match the overall style of existing code).
But if you must have a list of rules, here are some language
specific ones. Note that Documentation/ToolsForGit.txt document
has a collection of tips to help you use some external tools
to conform to these guidelines.
But if you must have a list of rules, here they are.
For shell scripts specifically (not exhaustive):
@ -220,9 +210,6 @@ For C programs:
. since mid 2017 with 512f41cf, we have been using designated
initializers for array (e.g. "int array[10] = { [5] = 2 }").
. since early 2021 with 765dc168882, we have been using variadic
macros, mostly for printf-like trace and debug macros.
These used to be forbidden, but we have not heard any breakage
report, and they are assumed to be safe.
@ -230,10 +217,7 @@ For C programs:
the first statement (i.e. -Wdeclaration-after-statement).
- Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
is still not allowed in this codebase. We are in the process of
allowing it by waiting to see that 44ba10d6 (revision: use C99
declaration of variable in for() loop, 2021-11-14) does not get
complaints. Let's revisit this around November 2022.
is still not allowed in this codebase.
- NULL pointers shall be written as NULL, not as 0.
@ -495,6 +479,17 @@ For Perl programs:
- Learn and use Git.pm if you need that functionality.
- For Emacs, it's useful to put the following in
GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
;; note the first part is useful for C editing, too
((nil . ((indent-tabs-mode . t)
(tab-width . 8)
(fill-column . 80)))
(cperl-mode . ((cperl-indent-level . 8)
(cperl-extra-newline-before-brace . nil)
(cperl-merge-trailing-else . t))))
For Python scripts:
- We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
@ -606,7 +601,7 @@ Writing Documentation:
avoidance of gendered pronouns.
- When it becomes awkward to stick to this style, prefer "you" when
addressing the hypothetical user, and possibly "we" when
addressing the the hypothetical user, and possibly "we" when
discussing how the program might react to the user. E.g.
You can use this option instead of --xyz, but we might remove

View File

@ -1,6 +1,3 @@
# Import tree-wide shared Makefile behavior and libraries
include ../shared.mak
# Guard against environment variables
MAN1_TXT =
MAN5_TXT =
@ -21,25 +18,13 @@ MAN1_TXT += $(filter-out \
MAN1_TXT += git.txt
MAN1_TXT += gitk.txt
MAN1_TXT += gitweb.txt
MAN1_TXT += scalar.txt
# man5 / man7 guides (note: new guides should also be added to command-list.txt)
MAN5_TXT += gitattributes.txt
MAN5_TXT += gitformat-bundle.txt
MAN5_TXT += gitformat-chunk.txt
MAN5_TXT += gitformat-commit-graph.txt
MAN5_TXT += gitformat-index.txt
MAN5_TXT += gitformat-pack.txt
MAN5_TXT += gitformat-signature.txt
MAN5_TXT += githooks.txt
MAN5_TXT += gitignore.txt
MAN5_TXT += gitmailmap.txt
MAN5_TXT += gitmodules.txt
MAN5_TXT += gitprotocol-capabilities.txt
MAN5_TXT += gitprotocol-common.txt
MAN5_TXT += gitprotocol-http.txt
MAN5_TXT += gitprotocol-pack.txt
MAN5_TXT += gitprotocol-v2.txt
MAN5_TXT += gitrepository-layout.txt
MAN5_TXT += gitweb.conf.txt
@ -63,7 +48,6 @@ HOWTO_TXT += $(wildcard howto/*.txt)
DOC_DEP_TXT += $(wildcard *.txt)
DOC_DEP_TXT += $(wildcard config/*.txt)
DOC_DEP_TXT += $(wildcard includes/*.txt)
ifdef MAN_FILTER
MAN_TXT = $(filter $(MAN_FILTER),$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT))
@ -103,24 +87,28 @@ 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)
TECH_DOCS += ReviewingGuidelines
TECH_DOCS += MyFirstContribution
TECH_DOCS += MyFirstObjectWalk
TECH_DOCS += SubmittingPatches
TECH_DOCS += ToolsForGit
TECH_DOCS += technical/bitmap-format
TECH_DOCS += technical/bundle-uri
TECH_DOCS += technical/bundle-format
TECH_DOCS += technical/hash-function-transition
TECH_DOCS += technical/http-protocol
TECH_DOCS += technical/index-format
TECH_DOCS += technical/long-running-process-protocol
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
TECH_DOCS += technical/protocol-v2
TECH_DOCS += technical/racy-git
TECH_DOCS += technical/reftable
TECH_DOCS += technical/scalar
TECH_DOCS += technical/send-pack-pipeline
TECH_DOCS += technical/shallow
TECH_DOCS += technical/signature-format
TECH_DOCS += technical/trivial-merge
SP_ARTICLES += $(TECH_DOCS)
SP_ARTICLES += technical/api-index
@ -227,6 +215,38 @@ DEFAULT_EDITOR_SQ = $(subst ','\'',$(DEFAULT_EDITOR))
ASCIIDOC_EXTRA += -a 'git-default-editor=$(DEFAULT_EDITOR_SQ)'
endif
QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
QUIET_SUBDIR1 =
ifneq ($(findstring $(MAKEFLAGS),w),w)
PRINT_DIR = --no-print-directory
else # "make -w"
NO_SUBDIR = :
endif
ifneq ($(findstring $(MAKEFLAGS),s),s)
ifndef V
QUIET = @
QUIET_ASCIIDOC = @echo ' ' ASCIIDOC $@;
QUIET_XMLTO = @echo ' ' XMLTO $@;
QUIET_DB2TEXI = @echo ' ' DB2TEXI $@;
QUIET_MAKEINFO = @echo ' ' MAKEINFO $@;
QUIET_DBLATEX = @echo ' ' DBLATEX $@;
QUIET_XSLTPROC = @echo ' ' XSLTPROC $@;
QUIET_GEN = @echo ' ' GEN $@;
QUIET_STDERR = 2> /dev/null
QUIET_SUBDIR0 = +@subdir=
QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo ' ' SUBDIR $$subdir; \
$(MAKE) $(PRINT_DIR) -C $$subdir
QUIET_LINT_GITLINK = @echo ' ' LINT GITLINK $<;
QUIET_LINT_MANSEC = @echo ' ' LINT MAN SEC $<;
QUIET_LINT_MANEND = @echo ' ' LINT MAN END $<;
export V
endif
endif
all: html man
html: $(DOC_HTML)
@ -296,8 +316,6 @@ cmds_txt = cmds-ancillaryinterrogators.txt \
cmds-synchingrepositories.txt \
cmds-synchelpers.txt \
cmds-guide.txt \
cmds-developerinterfaces.txt \
cmds-userinterfaces.txt \
cmds-purehelpers.txt \
cmds-foreignscminterface.txt
@ -313,12 +331,12 @@ $(mergetools_txt): mergetools-list.made
mergetools-list.made: ../git-mergetool--lib.sh $(wildcard ../mergetools/*)
$(QUIET_GEN) \
$(SHELL_PATH) -c 'MERGE_TOOLS_DIR=../mergetools && TOOL_MODE=diff && \
$(SHELL_PATH) -c 'MERGE_TOOLS_DIR=../mergetools && \
. ../git-mergetool--lib.sh && \
show_tool_names can_diff' | sed -e "s/\([a-z0-9]*\)/\`\1\`;;/" >mergetools-diff.txt && \
$(SHELL_PATH) -c 'MERGE_TOOLS_DIR=../mergetools && TOOL_MODE=merge && \
show_tool_names can_diff "* " || :' >mergetools-diff.txt && \
$(SHELL_PATH) -c 'MERGE_TOOLS_DIR=../mergetools && \
. ../git-mergetool--lib.sh && \
show_tool_names can_merge' | sed -e "s/\([a-z0-9]*\)/\`\1\`;;/" >mergetools-merge.txt && \
show_tool_names can_merge "* " || :' >mergetools-merge.txt && \
date >$@
TRACK_ASCIIDOCFLAGS = $(subst ','\'',$(ASCIIDOC_COMMON):$(ASCIIDOC_HTML):$(ASCIIDOC_DOCBOOK))
@ -401,7 +419,7 @@ gitman.texi: $(MAN_XML) cat-texi.perl texi.xsl
$(RM) $@+
gitman.info: gitman.texi
$(QUIET_MAKEINFO)$(MAKEINFO) --no-split --no-validate $<
$(QUIET_MAKEINFO)$(MAKEINFO) --no-split --no-validate $*.texi
$(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
$(QUIET_DB2TEXI)$(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@
@ -445,11 +463,25 @@ quick-install-html: require-htmlrepo
print-man1:
@for i in $(MAN1_TXT); do echo $$i; done
## Lint: Common
.build:
$(QUIET)mkdir $@
.build/lint-docs: | .build
$(QUIET)mkdir $@
## Lint: gitlink
.build/lint-docs/gitlink: | .build/lint-docs
$(QUIET)mkdir $@
.build/lint-docs/gitlink/howto: | .build/lint-docs/gitlink
$(QUIET)mkdir $@
.build/lint-docs/gitlink/config: | .build/lint-docs/gitlink
$(QUIET)mkdir $@
LINT_DOCS_GITLINK = $(patsubst %.txt,.build/lint-docs/gitlink/%.ok,$(HOWTO_TXT) $(DOC_DEP_TXT))
$(LINT_DOCS_GITLINK): | .build/lint-docs/gitlink
$(LINT_DOCS_GITLINK): | .build/lint-docs/gitlink/howto
$(LINT_DOCS_GITLINK): | .build/lint-docs/gitlink/config
$(LINT_DOCS_GITLINK): lint-gitlink.perl
$(LINT_DOCS_GITLINK): .build/lint-docs/gitlink/%.ok: %.txt
$(call mkdir_p_parent_template)
$(QUIET_LINT_GITLINK)$(PERL_PATH) lint-gitlink.perl \
$< \
$(HOWTO_TXT) $(DOC_DEP_TXT) \
@ -460,18 +492,23 @@ $(LINT_DOCS_GITLINK): .build/lint-docs/gitlink/%.ok: %.txt
lint-docs-gitlink: $(LINT_DOCS_GITLINK)
## Lint: man-end-blurb
.build/lint-docs/man-end-blurb: | .build/lint-docs
$(QUIET)mkdir $@
LINT_DOCS_MAN_END_BLURB = $(patsubst %.txt,.build/lint-docs/man-end-blurb/%.ok,$(MAN_TXT))
$(LINT_DOCS_MAN_END_BLURB): | .build/lint-docs/man-end-blurb
$(LINT_DOCS_MAN_END_BLURB): lint-man-end-blurb.perl
$(LINT_DOCS_MAN_END_BLURB): .build/lint-docs/man-end-blurb/%.ok: %.txt
$(call mkdir_p_parent_template)
$(QUIET_LINT_MANEND)$(PERL_PATH) lint-man-end-blurb.perl $< >$@
.PHONY: lint-docs-man-end-blurb
lint-docs-man-end-blurb: $(LINT_DOCS_MAN_END_BLURB)
## Lint: man-section-order
.build/lint-docs/man-section-order: | .build/lint-docs
$(QUIET)mkdir $@
LINT_DOCS_MAN_SECTION_ORDER = $(patsubst %.txt,.build/lint-docs/man-section-order/%.ok,$(MAN_TXT))
$(LINT_DOCS_MAN_SECTION_ORDER): | .build/lint-docs/man-section-order
$(LINT_DOCS_MAN_SECTION_ORDER): lint-man-section-order.perl
$(LINT_DOCS_MAN_SECTION_ORDER): .build/lint-docs/man-section-order/%.ok: %.txt
$(call mkdir_p_parent_template)
$(QUIET_LINT_MANSEC)$(PERL_PATH) lint-man-section-order.perl $< >$@
.PHONY: lint-docs-man-section-order
lint-docs-man-section-order: $(LINT_DOCS_MAN_SECTION_ORDER)
@ -487,4 +524,7 @@ doc-l10n install-l10n::
$(MAKE) -C po $@
endif
# Delete the target file on error
.DELETE_ON_ERROR:
.PHONY: FORCE

View File

@ -710,104 +710,13 @@ dependencies. `prove` also makes the output nicer.
Go ahead and commit this change, as well.
[[ready-to-share]]
== Getting Ready to Share: Anatomy of a Patch Series
== Getting Ready to Share
You may have noticed already that the Git project performs its code reviews via
emailed patches, which are then applied by the maintainer when they are ready
and approved by the community. The Git project does not accept contributions from
and approved by the community. The Git project does not accept patches from
pull requests, and the patches emailed for review need to be formatted a
specific way.
:patch-series: https://lore.kernel.org/git/pull.1218.git.git.1645209647.gitgitgadget@gmail.com/
:lore: https://lore.kernel.org/git/
Before taking a look at how to convert your commits into emailed patches,
let's analyze what the end result, a "patch series", looks like. Here is an
{patch-series}[example] of the summary view for a patch series on the web interface of
the {lore}[Git mailing list archive]:
----
2022-02-18 18:40 [PATCH 0/3] libify reflog John Cai via GitGitGadget
2022-02-18 18:40 ` [PATCH 1/3] reflog: libify delete reflog function and helpers John Cai via GitGitGadget
2022-02-18 19:10 ` Ævar Arnfjörð Bjarmason [this message]
2022-02-18 19:39 ` Taylor Blau
2022-02-18 19:48 ` Ævar Arnfjörð Bjarmason
2022-02-18 19:35 ` Taylor Blau
2022-02-21 1:43 ` John Cai
2022-02-21 1:50 ` Taylor Blau
2022-02-23 19:50 ` John Cai
2022-02-18 20:00 ` // other replies ellided
2022-02-18 18:40 ` [PATCH 2/3] reflog: call reflog_delete from reflog.c John Cai via GitGitGadget
2022-02-18 19:15 ` Ævar Arnfjörð Bjarmason
2022-02-18 20:26 ` Junio C Hamano
2022-02-18 18:40 ` [PATCH 3/3] stash: call reflog_delete from reflog.c John Cai via GitGitGadget
2022-02-18 19:20 ` Ævar Arnfjörð Bjarmason
2022-02-19 0:21 ` Taylor Blau
2022-02-22 2:36 ` John Cai
2022-02-22 10:51 ` Ævar Arnfjörð Bjarmason
2022-02-18 19:29 ` [PATCH 0/3] libify reflog Ævar Arnfjörð Bjarmason
2022-02-22 18:30 ` [PATCH v2 0/3] libify reflog John Cai via GitGitGadget
2022-02-22 18:30 ` [PATCH v2 1/3] stash: add test to ensure reflog --rewrite --updatref behavior John Cai via GitGitGadget
2022-02-23 8:54 ` Ævar Arnfjörð Bjarmason
2022-02-23 21:27 ` Junio C Hamano
// continued
----
We can note a few things:
- Each commit is sent as a separate email, with the commit message title as
subject, prefixed with "[PATCH _i_/_n_]" for the _i_-th commit of an
_n_-commit series.
- Each patch is sent as a reply to an introductory email called the _cover
letter_ of the series, prefixed "[PATCH 0/_n_]".
- Subsequent iterations of the patch series are labelled "PATCH v2", "PATCH
v3", etc. in place of "PATCH". For example, "[PATCH v2 1/3]" would be the first of
three patches in the second iteration. Each iteration is sent with a new cover
letter (like "[PATCH v2 0/3]" above), itself a reply to the cover letter of the
previous iteration (more on that below).
NOTE: A single-patch topic is sent with "[PATCH]", "[PATCH v2]", etc. without
_i_/_n_ numbering (in the above thread overview, no single-patch topic appears,
though).
[[cover-letter]]
=== The cover letter
In addition to an email per patch, the Git community also expects your patches
to come with a cover letter. This is an important component of change
submission as it explains to the community from a high level what you're trying
to do, and why, in a way that's more apparent than just looking at your
patches.
The title of your cover letter should be something which succinctly covers the
purpose of your entire topic branch. It's often in the imperative mood, just
like our commit message titles. Here is how we'll title our series:
---
Add the 'psuh' command
---
The body of the cover letter is used to give additional context to reviewers.
Be sure to explain anything your patches don't make clear on their own, but
remember that since the cover letter is not recorded in the commit history,
anything that might be useful to future readers of the repository's history
should also be in your commit messages.
Here's an example body for `psuh`:
----
Our internal metrics indicate widespread interest in the command
git-psuh - that is, many users are trying to use it, but finding it is
unavailable, using some unknown workaround instead.
The following handful of patches add the psuh command and implement some
handy features on top of it.
This patchset is part of the MyFirstContribution tutorial and should not
be merged.
----
At this point the tutorial diverges, in order to demonstrate two
specific way. At this point the tutorial diverges, in order to demonstrate two
different methods of formatting your patchset and getting it reviewed.
The first method to be covered is GitGitGadget, which is useful for those
@ -899,22 +808,8 @@ https://github.com/gitgitgadget/git and open a PR either with the "New pull
request" button or the convenient "Compare & pull request" button that may
appear with the name of your newly pushed branch.
Review the PR's title and description, as they're used by GitGitGadget
respectively as the subject and body of the cover letter for your change. Refer
to <<cover-letter,"The cover letter">> above for advice on how to title your
submission and what content to include in the description.
NOTE: For single-patch contributions, your commit message should already be
meaningful and explain at a high level the purpose (what is happening and why)
of your patch, so you usually do not need any additional context. In that case,
remove the PR description that GitHub automatically generates from your commit
message (your PR description should be empty). If you do need to supply even
more context, you can do so in that space and it will be appended to the email
that GitGitGadget will send, between the three-dash line and the diffstat
(see <<single-patch,Bonus Chapter: One-Patch Changes>> for how this looks once
submitted).
When you're happy, submit your pull request.
Review the PR's title and description, as it's used by GitGitGadget as the cover
letter for your change. When you're happy, submit your pull request.
[[run-ci-ggg]]
=== Running CI and Getting Ready to Send
@ -1057,29 +952,49 @@ but want reviewers to look at what they have so far. You can add this flag with
Check and make sure that your patches and cover letter template exist in the
directory you specified - you're nearly ready to send out your review!
[[preparing-cover-letter]]
[[cover-letter]]
=== Preparing Email
Since you invoked `format-patch` with `--cover-letter`, you've already got a
cover letter template ready. Open it up in your favorite editor.
In addition to an email per patch, the Git community also expects your patches
to come with a cover letter, typically with a subject line [PATCH 0/x] (where
x is the number of patches you're sending). Since you invoked `format-patch`
with `--cover-letter`, you've already got a template ready. Open it up in your
favorite editor.
You should see a number of headers present already. Check that your `From:`
header is correct. Then modify your `Subject:` (see <<cover-letter,above>> for
how to choose good title for your patch series):
header is correct. Then modify your `Subject:` to something which succinctly
covers the purpose of your entire topic branch, for example:
----
Subject: [PATCH 0/7] Add the 'psuh' command
Subject: [PATCH 0/7] adding the 'psuh' command
----
Make sure you retain the ``[PATCH 0/X]'' part; that's what indicates to the Git
community that this email is the beginning of a patch series, and many
reviewers filter their email for this type of flag.
community that this email is the beginning of a review, and many reviewers
filter their email for this type of flag.
You'll need to add some extra parameters when you invoke `git send-email` to add
the cover letter.
Next you'll have to fill out the body of your cover letter. Again, see
<<cover-letter,above>> for what content to include.
Next you'll have to fill out the body of your cover letter. This is an important
component of change submission as it explains to the community from a high level
what you're trying to do, and why, in a way that's more apparent than just
looking at your diff. Be sure to explain anything your diff doesn't make clear
on its own.
Here's an example body for `psuh`:
----
Our internal metrics indicate widespread interest in the command
git-psuh - that is, many users are trying to use it, but finding it is
unavailable, using some unknown workaround instead.
The following handful of patches add the psuh command and implement some
handy features on top of it.
This patchset is part of the MyFirstContribution tutorial and should not
be merged.
----
The template created by `git format-patch --cover-letter` includes a diffstat.
This gives reviewers a summary of what they're in for when reviewing your topic.
@ -1160,7 +1075,7 @@ all named like `v2-000n-my-commit-subject.patch`. `-v2` will also format
your patches by prefixing them with "[PATCH v2]" instead of "[PATCH]",
and your range-diff will be prefaced with "Range-diff against v1".
After you run this command, `format-patch` will output the patches to the `psuh/`
Afer you run this command, `format-patch` will output the patches to the `psuh/`
directory, alongside the v1 patches. Using a single directory makes it easy to
refer to the old v1 patches while proofreading the v2 patches, but you will need
to be careful to send out only the v2 patches. We will use a pattern like

View File

@ -522,25 +522,24 @@ function shows that the all-object walk is being performed by
`traverse_commit_list()` or `traverse_commit_list_filtered()`. Those two
functions reside in `list-objects.c`; examining the source shows that, despite
the name, these functions traverse all kinds of objects. Let's have a look at
the arguments to `traverse_commit_list()`.
the arguments to `traverse_commit_list_filtered()`, which are a superset of the
arguments to the unfiltered version.
- `struct rev_info *revs`: This is the `rev_info` used for the walk. If
its `filter` member is not `NULL`, then `filter` contains information for
how to filter the object list.
- `struct list_objects_filter_options *filter_options`: This is a struct which
stores a filter-spec as outlined in `Documentation/rev-list-options.txt`.
- `struct rev_info *revs`: This is the `rev_info` used for the walk.
- `show_commit_fn show_commit`: A callback which will be used to handle each
individual commit object.
- `show_object_fn show_object`: A callback which will be used to handle each
non-commit object (so each blob, tree, or tag).
- `void *show_data`: A context buffer which is passed in turn to `show_commit`
and `show_object`.
In addition, `traverse_commit_list_filtered()` has an additional parameter:
- `struct oidset *omitted`: A linked-list of object IDs which the provided
filter caused to be omitted.
It looks like these methods use callbacks we provide instead of needing us
to call it repeatedly ourselves. Cool! Let's add the callbacks first.
It looks like this `traverse_commit_list_filtered()` uses callbacks we provide
instead of needing us to call it repeatedly ourselves. Cool! Let's add the
callbacks first.
For the sake of this tutorial, we'll simply keep track of how many of each kind
of object we find. At file scope in `builtin/walken.c` add the following
@ -713,9 +712,20 @@ help understand. In our case, that means we omit trees and blobs not directly
referenced by `HEAD` or `HEAD`'s history, because we begin the walk with only
`HEAD` in the `pending` list.)
First, we'll need to `#include "list-objects-filter-options.h"` and set up the
`struct list_objects_filter_options` at the top of the function.
----
static void walken_object_walk(struct rev_info *rev)
{
struct list_objects_filter_options filter_options = { 0 };
...
----
For now, we are not going to track the omitted objects, so we'll replace those
parameters with `NULL`. For the sake of simplicity, we'll add a simple
build-time branch to use our filter or not. Preface the line calling
build-time branch to use our filter or not. Replace the line calling
`traverse_commit_list()` with the following, which will remind us which kind of
walk we've just performed:
@ -723,17 +733,19 @@ walk we've just performed:
if (0) {
/* Unfiltered: */
trace_printf(_("Unfiltered object walk.\n"));
traverse_commit_list(rev, walken_show_commit,
walken_show_object, NULL);
} else {
trace_printf(
_("Filtered object walk with filterspec 'tree:1'.\n"));
CALLOC_ARRAY(rev->filter, 1);
parse_list_objects_filter(rev->filter, "tree:1");
parse_list_objects_filter(&filter_options, "tree:1");
traverse_commit_list_filtered(&filter_options, rev,
walken_show_commit, walken_show_object, NULL, NULL);
}
traverse_commit_list(rev, walken_show_commit,
walken_show_object, NULL);
----
The `rev->filter` member is usually built directly from a command
`struct list_objects_filter_options` is usually built directly from a command
line argument, so the module provides an easy way to build one from a string.
Even though we aren't taking user input right now, we can still build one with
a hardcoded string using `parse_list_objects_filter()`.
@ -772,7 +784,7 @@ object:
----
...
traverse_commit_list_filtered(rev,
traverse_commit_list_filtered(&filter_options, rev,
walken_show_commit, walken_show_object, NULL, &omitted);
...

View File

@ -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

View File

@ -0,0 +1,5 @@
Git v2.31.5 Release Notes
=========================
This release merges the security fix that appears in v2.30.6; see
the release notes for that version for details.

View File

@ -0,0 +1,5 @@
Git v2.32.4 Release Notes
=========================
This release merges the security fix that appears in v2.30.6; see
the release notes for that version for details.

View File

@ -0,0 +1,5 @@
Git v2.33.5 Release Notes
=========================
This release merges the security fix that appears in v2.30.6; see
the release notes for that version for details.

View File

@ -0,0 +1,5 @@
Git v2.34.5 Release Notes
=========================
This release merges the security fix that appears in v2.30.6; see
the release notes for that version for details.

View File

@ -0,0 +1,5 @@
Git v2.35.5 Release Notes
=========================
This release merges the security fix that appears in v2.30.6; see
the release notes for that version for details.

View File

@ -1,429 +0,0 @@
Git 2.36 Release Notes
======================
Updates since Git 2.35
----------------------
Backward compatibility warts
* "git name-rev --stdin" has been deprecated and issues a warning
when used; use "git name-rev --annotate-stdin" instead.
* "git clone --filter=... --recurse-submodules" only makes the
top-level a partial clone, while submodules are fully cloned. This
behaviour is changed to pass the same filter down to the submodules.
* With the fixes for CVE-2022-24765 that are common with versions of
Git 2.30.4, 2.31.3, 2.32.2, 2.33.3, 2.34.3, and 2.35.3, Git has
been taught not to recognise repositories owned by other users, in
order to avoid getting affected by their config files and hooks.
You can list the path to the safe/trusted repositories that may be
owned by others on a multi-valued configuration variable
`safe.directory` to override this behaviour, or use '*' to declare
that you trust anything.
Note to those who build from the source
* Since Git 2.31, our source assumed that the compiler you use to
build Git supports variadic macros, with an easy-to-use escape
hatch to allow compilation without variadic macros with an request
to report that you had to use the escape hatch to the list.
Because we haven't heard from anybody who actually needed to use
the escape hatch, it has been removed, making support of variadic
macros a hard requirement.
UI, Workflows & Features
* Assorted updates to "git cat-file", especially "-h".
* The command line completion (in contrib/) learns to complete
arguments to give to "git sparse-checkout" command.
* "git log --remerge-diff" shows the difference from mechanical merge
result and the result that is actually recorded in a merge commit.
* "git log" and friends learned an option --exclude-first-parent-only
to propagate UNINTERESTING bit down only along the first-parent
chain, just like --first-parent option shows commits that lack the
UNINTERESTING bit only along the first-parent chain.
* The command line completion script (in contrib/) learned to
complete all Git subcommands, including the ones that are normally
hidden, when GIT_COMPLETION_SHOW_ALL_COMMANDS is used.
* "git branch" learned the "--recurse-submodules" option.
* A user can forget to make a script file executable before giving
it to "git bisect run". In such a case, all tests will exit with
126 or 127 error codes, even on revisions that are marked as good.
Try to recognize this situation and stop iteration early.
* When "index-pack" dies due to incoming data exceeding the maximum
allowed input size, include the value of the limit in the error
message.
* The error message given by "git switch HEAD~4" has been clarified
to suggest the "--detach" option that is required.
* In sparse-checkouts, files mis-marked as missing from the working tree
could lead to later problems. Such files were hard to discover, and
harder to correct. Automatically detecting and correcting the marking
of such files has been added to avoid these problems.
* "git cat-file" learns "--batch-command" mode, which is a more
flexible interface than the existing "--batch" or "--batch-check"
modes, to allow different kinds of inquiries made.
* The level of verbose output from the ort backend during inner merge
has been aligned to that of the recursive backend.
* "git remote rename A B", depending on the number of remote-tracking
refs involved, takes long time renaming them. The command has been
taught to show progress bar while making the user wait.
* Bundle file format gets extended to allow a partial bundle,
filtered by similar criteria you would give when making a
partial/lazy clone.
* A new built-in userdiff driver for kotlin has been added.
* "git repack" learned a new configuration to disable triggering of
age-old "update-server-info" command, which is rarely useful these
days.
* "git stash" does not allow subcommands it internally runs as its
implementation detail, except for "git reset", to emit messages;
now "git reset" part has also been squelched.
* "git ls-tree" learns "--oid-only" option, similar to "--name-only",
and more generalized "--format" option.
* "git fetch --refetch" learned to fetch everything without telling
the other side what we already have, which is useful when you
cannot trust what you have in the local object store.
* "git branch" gives hint when branch tracking cannot be established
because fetch refspecs from multiple remote repositories overlap.
* "git worktree list --porcelain" did not c-quote pathnames and lock
reasons with unsafe bytes correctly, which is worked around by
introducing NUL terminated output format with "-z".
Performance, Internal Implementation, Development Support etc.
* "git apply" (ab)used the util pointer of the string-list to keep
track of how each symbolic link needs to be handled, which has been
simplified by using strset.
* Fix a hand-rolled alloca() imitation that may have violated
alignment requirement of data being sorted in compatibility
implementation of qsort_s() and stable qsort().
* Use the parse-options API in "git reflog" command.
* The conditional inclusion mechanism of configuration files using
"[includeIf <condition>]" learns to base its decision on the
URL of the remote repository the repository interacts with.
(merge 399b198489 jt/conditional-config-on-remote-url later to maint).
* "git name-rev --stdin" does not behave like usual "--stdin" at
all. Start the process of renaming it to "--annotate-stdin".
(merge a2585719b3 jc/name-rev-stdin later to maint).
* "git update-index", "git checkout-index", and "git clean" are
taught to work better with the sparse checkout feature.
* Use an internal call to reset_head() helper function instead of
spawning "git checkout" in "rebase", and update code paths that are
involved in the change.
* Messages "ort" merge backend prepares while dealing with conflicted
paths were unnecessarily confusing since it did not differentiate
inner merges and outer merges.
* Small modernization of the rerere-train script (in contrib/).
* Use designated initializers we started using in mid 2017 in more
parts of the codebase that are relatively quiescent.
* Improve failure case behaviour of xdiff library when memory
allocation fails.
* General clean-up in reftable implementation, including
clarification of the API documentation, tightening the code to
honor documented length limit, etc.
* Remove the escape hatch we added when we introduced the weather
balloon to use variadic macros unconditionally, to make it official
that we now have a hard dependency on the feature.
* Makefile refactoring with a bit of suffixes rule stripping to
optimize the runtime overhead.
* "git stash drop" is reimplemented as an internal call to
reflog_delete() function, instead of invoking "git reflog delete"
via run_command() API.
* Count string_list items in size_t, not "unsigned int".
* The single-key interactive operation used by "git add -p" has been
made more robust.
* Remove unneeded <meta http-equiv=content-type...> from gitweb
output.
* "git name-rev" learned to use the generation numbers when setting
the lower bound of searching commits used to explain the revision,
when available, instead of committer time.
* Replace core.fsyncObjectFiles with two new configuration variables,
core.fsync and core.fsyncMethod.
* Updates to refs traditionally weren't fsync'ed, but we can
configure using core.fsync variable to do so.
* "git reflog" command now uses parse-options API to parse its
command line options.
Fixes since v2.35
-----------------
* "rebase" and "stash" in secondary worktrees are broken in
Git 2.35.0, which has been corrected.
* "git pull --rebase" ignored the rebase.autostash configuration
variable when the remote history is a descendant of our history,
which has been corrected.
(merge 3013d98d7a pb/pull-rebase-autostash-fix later to maint).
* "git update-index --refresh" has been taught to deal better with
racy timestamps (just like "git status" already does).
(merge 2ede073fd2 ms/update-index-racy later to maint).
* Avoid tests that are run under GIT_TRACE2 set from failing
unnecessarily.
(merge 944d808e42 js/test-unset-trace2-parents later to maint).
* The merge-ort misbehaved when merge.renameLimit configuration is
set too low and failed to find all renames.
(merge 9ae39fef7f en/merge-ort-restart-optim-fix later to maint).
* We explain that revs come first before the pathspec among command
line arguments, but did not spell out that dashed options come
before other args, which has been corrected.
(merge c11f95010c tl/doc-cli-options-first later to maint).
* "git add -p" rewritten in C regressed hunk splitting in some cases,
which has been corrected.
(merge 7008ddc645 pw/add-p-hunk-split-fix later to maint).
* "git fetch --negotiate-only" is an internal command used by "git
push" to figure out which part of our history is missing from the
other side. It should never recurse into submodules even when
fetch.recursesubmodules configuration variable is set, nor it
should trigger "gc". The code has been tightened up to ensure it
only does common ancestry discovery and nothing else.
(merge de4eaae63a gc/fetch-negotiate-only-early-return later to maint).
* The code path that verifies signatures made with ssh were made to
work better on a system with CRLF line endings.
(merge caeef01ea7 fs/ssh-signing-crlf later to maint).
* "git sparse-checkout init" failed to write into $GIT_DIR/info
directory when the repository was created without one, which has
been corrected to auto-create it.
(merge 7f44842ac1 jt/sparse-checkout-leading-dir-fix later to maint).
* Cloning from a repository that does not yet have any branches or
tags but has other refs resulted in a "remote transport reported
error", which has been corrected.
(merge dccea605b6 jt/clone-not-quite-empty later to maint).
* Mark in various places in the code that the sparse index and the
split index features are mutually incompatible.
(merge 451b66c533 js/sparse-vs-split-index later to maint).
* Update the logic to compute alignment requirement for our mem-pool.
(merge e38bcc66d8 jc/mem-pool-alignment later to maint).
* Pick a better random number generator and use it when we prepare
temporary filenames.
(merge 47efda967c bc/csprng-mktemps later to maint).
* Update the contributor-facing documents on proposed log messages.
(merge cdba0295b0 jc/doc-log-messages later to maint).
* When "git fetch --prune" failed to prune the refs it wanted to
prune, the command issued error messages but exited with exit
status 0, which has been corrected.
(merge c9e04d905e tg/fetch-prune-exit-code-fix later to maint).
* Problems identified by Coverity in the reftable code have been
corrected.
(merge 01033de49f hn/reftable-coverity-fixes later to maint).
* A bug that made multi-pack bitmap and the object order out-of-sync,
making the .midx data corrupt, has been fixed.
(merge f8b60cf99b tb/midx-bitmap-corruption-fix later to maint).
* The build procedure has been taught to notice older version of zlib
and enable our replacement uncompress2() automatically.
(merge 07564773c2 ab/auto-detect-zlib-compress2 later to maint).
* Interaction between fetch.negotiationAlgorithm and
feature.experimental configuration variables has been corrected.
(merge 714edc620c en/fetch-negotiation-default-fix later to maint).
* "git diff --diff-filter=aR" is now parsed correctly.
(merge 75408ca949 js/diff-filter-negation-fix later to maint).
* When "git subtree" wants to create a merge, it used "git merge" and
let it be affected by end-user's "merge.ff" configuration, which
has been corrected.
(merge 9158a3564a tk/subtree-merge-not-ff-only later to maint).
* Unlike "git apply", "git patch-id" did not handle patches with
hunks that has only 1 line in either preimage or postimage, which
has been corrected.
(merge 757e75c81e jz/patch-id-hunk-header-parsing-fix later to maint).
* "receive-pack" checks if it will do any ref updates (various
conditions could reject a push) before received objects are taken
out of the temporary directory used for quarantine purposes, so
that a push that is known-to-fail will not leave crufts that a
future "gc" needs to clean up.
(merge 5407764069 cb/clear-quarantine-early-on-all-ref-update-errors later to maint).
* When there is no object to write .bitmap file for, "git
multi-pack-index" triggered an error, instead of just skipping,
which has been corrected.
(merge eb57277ba3 tb/midx-no-bitmap-for-no-objects later to maint).
* "git cmd -h" outside a repository should error out cleanly for many
commands, but instead it hit a BUG(), which has been corrected.
(merge 87ad07d735 js/short-help-outside-repo-fix later to maint).
* "working tree" and "per-worktree ref" were in glossary, but
"worktree" itself wasn't, which has been corrected.
(merge 2df5387ed0 jc/glossary-worktree later to maint).
* L10n support for a few error messages.
(merge 3d3c23b3a7 bs/forbid-i18n-of-protocol-token-in-fetch-pack later to maint).
* Test modernization.
(merge d4fe066e4b sy/t0001-use-path-is-helper later to maint).
* "git log --graph --graph" used to leak a graph structure, and there
was no way to countermand "--graph" that appear earlier on the
command line. A "--no-graph" option has been added and resource
leakage has been plugged.
* Error output given in response to an ambiguous object name has been
improved.
(merge 3a73c1dfaf ab/ambiguous-object-name later to maint).
* "git sparse-checkout" wants to work with per-worktree configuration,
but did not work well in a worktree attached to a bare repository.
(merge 3ce1138272 ds/sparse-checkout-requires-per-worktree-config later to maint).
* Setting core.untrackedCache to true failed to add the untracked
cache extension to the index.
* Workaround we have for versions of PCRE2 before their version 10.36
were in effect only for their versions newer than 10.36 by mistake,
which has been corrected.
(merge 97169fc361 rs/pcre-invalid-utf8-fix-fix later to maint).
* Document Taylor as a new member of Git PLC at SFC. Welcome.
(merge e8d56ca863 tb/coc-plc-update later to maint).
* "git checkout -b branch/with/multi/level/name && git stash" only
recorded the last level component of the branch name, which has
been corrected.
* Check the return value from parse_tree_indirect() to turn segfaults
into calls to die().
(merge 8d2eaf649a gc/parse-tree-indirect-errors later to maint).
* Newer version of GPGSM changed its output in a backward
incompatible way to break our code that parses its output. It also
added more processes our tests need to kill when cleaning up.
Adjustments have been made to accommodate these changes.
(merge b0b70d54c4 fs/gpgsm-update later to maint).
* The untracked cache newly computed weren't written back to the
on-disk index file when there is no other change to the index,
which has been corrected.
* "git config -h" did not describe the "--type" option correctly.
(merge 5445124fad mf/fix-type-in-config-h later to maint).
* The way generation number v2 in the commit-graph files are
(not) handled has been corrected.
(merge 6dbf4b8172 ds/commit-graph-gen-v2-fixes later to maint).
* The method to trigger malloc check used in our tests no longer work
with newer versions of glibc.
(merge baedc59543 ep/test-malloc-check-with-glibc-2.34 later to maint).
* When "git fetch --recurse-submodules" grabbed submodule commits
that would be needed to recursively check out newly fetched commits
in the superproject, it only paid attention to submodules that are
in the current checkout of the superproject. We now do so for all
submodules that have been run "git submodule init" on.
* "git rebase $base $non_branch_commit", when $base is an ancestor or
the $non_branch_commit, modified the current branch, which has been
corrected.
* When "shallow" information is updated, we forgot to update the
in-core equivalent, which has been corrected.
* When creating a loose object file, we didn't report the exact
filename of the file we failed to fsync, even though the
information was readily available, which has been corrected.
* "git am" can read from the standard input when no mailbox is given
on the command line, but the end-user gets no indication when it
happens, making Git appear stuck.
(merge 7b20af6a06 jc/mailsplit-warn-on-tty later to maint).
* "git mv" failed to refresh the cached stat information for the
entry it moved.
(merge b7f9130a06 vd/mv-refresh-stat later to maint).
* Other code cleanup, docfix, build fix, etc.
(merge cfc5cf428b jc/find-header later to maint).
(merge 40e7cfdd46 jh/p4-fix-use-of-process-error-exception later to maint).
(merge 727e6ea350 jh/p4-spawning-external-commands-cleanup later to maint).
(merge 0a6adc26e2 rs/grep-expr-cleanup later to maint).
(merge 4ed7dfa713 po/readme-mention-contributor-hints later to maint).
(merge 6046f7a91c en/plug-leaks-in-merge later to maint).
(merge 8c591dbfce bc/clarify-eol-attr later to maint).
(merge 518e15db74 rs/parse-options-lithelp-help later to maint).
(merge cbac0076ef gh/doc-typos later to maint).
(merge ce14de03db ab/no-errno-from-resolve-ref-unsafe later to maint).
(merge 2826ffad8c rc/negotiate-only-typofix later to maint).
(merge 0f03f04c5c en/sparse-checkout-leakfix later to maint).
(merge 74f3390dde sy/diff-usage-typofix later to maint).
(merge 45d0212a71 ll/doc-mktree-typofix later to maint).
(merge e9b272e4c1 js/no-more-legacy-stash later to maint).
(merge 6798b08e84 ab/do-not-hide-failures-in-git-dot-pm later to maint).
(merge 9325285df4 po/doc-check-ignore-markup-fix later to maint).
(merge cd26cd6c7c sy/modernize-t-lib-read-tree-m-3way later to maint).
(merge d17294a05e ab/hash-object-leakfix later to maint).
(merge b8403129d3 jd/t0015-modernize later to maint).
(merge 332acc248d ds/mailmap later to maint).
(merge 04bf052eef ab/grep-patterntype later to maint).
(merge 6ee36364eb ab/diff-free-more later to maint).
(merge 63a36017fe nj/read-tree-doc-reffix later to maint).
(merge eed36fce38 sm/no-git-in-upstream-of-pipe-in-tests later to maint).
(merge c614beb933 ep/t6423-modernize later to maint).
(merge 57be9c6dee ab/reflog-prep-fix later to maint).
(merge 5327d8982a js/in-place-reverse-in-sequencer later to maint).
(merge 2e2c0be51e dp/worktree-repair-in-usage later to maint).
(merge 6563706568 jc/coding-guidelines-decl-in-for-loop later to maint).

View File

@ -1,33 +0,0 @@
Git v2.36.1 Release Notes
=========================
Fixes since v2.36
-----------------
* "git submodule update" without pathspec should silently skip an
uninitialized submodule, but it started to become noisy by mistake.
* "diff-tree --stdin" has been broken for about a year, but 2.36
release broke it even worse by breaking running the command with
<pathspec>, which in turn broke "gitk" and got noticed. This has
been corrected by aligning its behaviour to that of "log".
* Regression fix for 2.36 where "git name-rev" started to sometimes
reference strings after they are freed.
* "git show <commit1> <commit2>... -- <pathspec>" lost the pathspec
when showing the second and subsequent commits, which has been
corrected.
* "git fast-export -- <pathspec>" lost the pathspec when showing the
second and subsequent commits, which has been corrected.
* "git format-patch <args> -- <pathspec>" lost the pathspec when
showing the second and subsequent commits, which has been
corrected.
* Get rid of a bogus and over-eager coccinelle rule.
* Correct choices of C compilers used in various CI jobs.
Also contains minor documentation updates and code clean-ups.

View File

@ -1,56 +0,0 @@
Git v2.36.2 Release Notes
=========================
This release merges up the fixes that appear in v2.30.5, v2.31.4,
v2.32.3, v2.33.4, v2.34.4 and v2.35.4 to address the security
issue CVE-2022-29187; see the release notes for these versions
for details.
Apart from that, this maintenance release is primarily to merge down
updates to the build and CI procedures from the 'master' front, in
order to ensure that we can cut healthy maintenance releases in the
future. It also contains a handful of small and trivially-correct
bugfixes.
Fixes since v2.36.1
-------------------
* Fixes real problems noticed by gcc 12 and works around false
positives.
* Update URL to the gitk repository.
* The "--current" option of "git show-branch" should have been made
incompatible with the "--reflog" mode, but this was not enforced,
which has been corrected.
* "git archive --add-file=<path>" picked up the raw permission bits
from the path and propagated to zip output in some cases, without
normalization, which has been corrected (tar output did not have
this issue).
* A bit of test framework fixes with a few fixes to issues found by
valgrind.
* macOS CI jobs have been occasionally flaky due to tentative version
skew between perforce and the homebrew packager. Instead of
failing the whole CI job, just let it skip the p4 tests when this
happens.
* The commit summary shown after making a commit is matched to what
is given in "git status" not to use the break-rewrite heuristics.
* Avoid problems from interaction between malloc_check and address
sanitizer.
* "git rebase --keep-base <upstream> <branch-to-rebase>" computed the
commit to rebase onto incorrectly, which has been corrected.
* The path taken by "git multi-pack-index" command from the end user
was compared with path internally prepared by the tool withut first
normalizing, which lead to duplicated paths not being noticed,
which has been corrected.
* "git clone --origin X" leaked piece of memory that held value read
from the clone.defaultRemoteName configuration variable, which has
been plugged.

View File

@ -1,337 +0,0 @@
Git v2.37 Release Notes
=======================
UI, Workflows & Features
* "vimdiff[123]" mergetool drivers have been reimplemented with a
more generic layout mechanism.
* "git -v" and "git -h" are now understood as "git --version" and
"git --help".
* The temporary files fed to external diff command are now generated
inside a new temporary directory under the same basename.
* "git log --since=X" will stop traversal upon seeing a commit that
is older than X, but there may be commits behind it that is younger
than X when the commit was created with a faulty clock. A new
option is added to keep digging without stopping, and instead
filter out commits with timestamp older than X.
* "git -c branch.autosetupmerge=simple branch $A $B" will set the $B
as $A's upstream only when $A and $B shares the same name, and "git
-c push.default=simple" on branch $A would push to update the
branch $A at the remote $B came from. Also more places use the
sole remote, if exists, before defaulting to 'origin'.
* A new doc has been added that lists tips for tools to work with
Git's codebase.
* "git remote -v" now shows the list-objects-filter used during
fetching from the remote, if available.
* With the new http.curloptResolve configuration, the CURLOPT_RESOLVE
mechanism that allows cURL based applications to use pre-resolved
IP addresses for the requests is exposed to the scripts.
* "git add -i" was rewritten in C some time ago and has been in
testing; the reimplementation is now exposed to general public by
default.
* Deprecate non-cone mode of the sparse-checkout feature.
* Introduce a filesystem-dependent mechanism to optimize the way the
bits for many loose object files are ensured to hit the disk
platter.
* The "do not remove the directory the user started Git in" logic,
when Git cannot tell where that directory is, is disabled. Earlier
we refused to run in such a case.
* A mechanism to pack unreachable objects into a "cruft pack",
instead of ejecting them into loose form to be reclaimed later, has
been introduced.
* Update the doctype written in gitweb output to xhtml5.
* The "transfer.credentialsInURL" configuration variable controls what
happens when a URL with embedded login credential is used on either
"fetch" or "push". Credentials are currently only detected in
`remote.<name>.url` config, not `remote.<name>.pushurl`.
* "git revert" learns "--reference" option to use more human-readable
reference to the commit it reverts in the message template it
prepares for the user.
* Various error messages that talk about the removal of
"--preserve-merges" in "rebase" have been strengthened, and "rebase
--abort" learned to get out of a state that was left by an earlier
use of the option.
Performance, Internal Implementation, Development Support etc.
* The performance of the "untracked cache" feature has been improved
when "--untracked-files=<mode>" and "status.showUntrackedFiles"
are combined.
* "git stash" works better with sparse index entries.
* "git show :<path>" learned to work better with the sparse-index
feature.
* Introduce and apply coccinelle rule to discourage an explicit
comparison between a pointer and NULL, and applies the clean-up to
the maintenance track.
* Preliminary code refactoring around transport and bundle code.
* "sparse-checkout" learns to work better with the sparse-index
feature.
* A workflow change for translators are being proposed. git.pot is
no longer version controlled and it is local responsibility of
translators to generate it.
* Plug the memory leaks from the trickiest API of all, the revision
walker.
* Rename .env_array member to .env in the child_process structure.
* The fsmonitor--daemon handles even more corner cases when
watching filesystem events.
* A new bug() and BUG_if_bug() API is introduced to make it easier to
uniformly log "detect multiple bugs and abort in the end" pattern.
Fixes since v2.36
-----------------
* "git submodule update" without pathspec should silently skip an
uninitialized submodule, but it started to become noisy by mistake.
(merge 4f1ccef87c gc/submodule-update-part2 later to maint).
* "diff-tree --stdin" has been broken for about a year, but 2.36
release broke it even worse by breaking running the command with
<pathspec>, which in turn broke "gitk" and got noticed. This has
been corrected by aligning its behaviour to that of "log".
(merge f8781bfda3 jc/diff-tree-stdin-fix later to maint).
* Regression fix for 2.36 where "git name-rev" started to sometimes
reference strings after they are freed.
(merge 45a14f578e rs/name-rev-fix-free-after-use later to maint).
* "git show <commit1> <commit2>... -- <pathspec>" lost the pathspec
when showing the second and subsequent commits, which has been
corrected.
(merge 5cdb38458e jc/show-pathspec-fix later to maint).
* "git fast-export -- <pathspec>" lost the pathspec when showing the
second and subsequent commits, which has been corrected.
(merge d1c25272f5 rs/fast-export-pathspec-fix later to maint).
* "git format-patch <args> -- <pathspec>" lost the pathspec when
showing the second and subsequent commits, which has been
corrected.
(merge 91f8f7e46f rs/format-patch-pathspec-fix later to maint).
* "git clone --origin X" leaked piece of memory that held value read
from the clone.defaultRemoteName configuration variable, which has
been plugged.
(merge 6dfadc8981 jc/clone-remote-name-leak-fix later to maint).
* Get rid of a bogus and over-eager coccinelle rule.
(merge 08bdd3a185 jc/cocci-xstrdup-or-null-fix later to maint).
* The path taken by "git multi-pack-index" command from the end user
was compared with path internally prepared by the tool without first
normalizing, which lead to duplicated paths not being noticed,
which has been corrected.
(merge 11f9e8de3d ds/midx-normalize-pathname-before-comparison later to maint).
* Correct choices of C compilers used in various CI jobs.
(merge 3506cae04f ab/cc-package-fixes later to maint).
* Various cleanups to "git p4".
(merge 4ff0108d9e jh/p4-various-fixups later to maint).
* The progress meter of "git blame" was showing incorrect numbers
when processing only parts of the file.
(merge e5f5d7d42e ea/progress-partial-blame later to maint).
* "git rebase --keep-base <upstream> <branch-to-rebase>" computed the
commit to rebase onto incorrectly, which has been corrected.
(merge 9e5ebe9668 ah/rebase-keep-base-fix later to maint).
* Fix a leak of FILE * in an error codepath.
(merge c0befa0c03 kt/commit-graph-plug-fp-leak-on-error later to maint).
* Avoid problems from interaction between malloc_check and address
sanitizer.
(merge 067109a5e7 pw/test-malloc-with-sanitize-address later to maint).
* The commit summary shown after making a commit is matched to what
is given in "git status" not to use the break-rewrite heuristics.
(merge 84792322ed rs/commit-summary-wo-break-rewrite later to maint).
* Update a few end-user facing messages around EOL conversion.
(merge c970d30c2c ah/convert-warning-message later to maint).
* Trace2 documentation updates.
(merge a6c80c313c js/trace2-doc-fixes later to maint).
* Build procedure fixup.
(merge 1fbfd96f50 mg/detect-compiler-in-c-locale later to maint).
* "git pull" without "--recurse-submodules=<arg>" made
submodule.recurse take precedence over fetch.recurseSubmodules by
mistake, which has been corrected.
(merge 5819417365 gc/pull-recurse-submodules later to maint).
* "git bisect" was too silent before it is ready to start computing
the actual bisection, which has been corrected.
(merge f11046e6de cd/bisect-messages-from-pre-flight-states later to maint).
* macOS CI jobs have been occasionally flaky due to tentative version
skew between perforce and the homebrew packager. Instead of
failing the whole CI job, just let it skip the p4 tests when this
happens.
(merge f15e00b463 cb/ci-make-p4-optional later to maint).
* A bit of test framework fixes with a few fixes to issues found by
valgrind.
(merge 7c898554d7 ab/valgrind-fixes later to maint).
* "git archive --add-file=<path>" picked up the raw permission bits
from the path and propagated to zip output in some cases, without
normalization, which has been corrected (tar output did not have
this issue).
(merge 6a61661967 jc/archive-add-file-normalize-mode later to maint).
* "make coverage-report" without first running "make coverage" did
not produce any meaningful result, which has been corrected.
(merge 96ddfecc5b ep/coverage-report-wants-test-to-have-run later to maint).
* The "--current" option of "git show-branch" should have been made
incompatible with the "--reflog" mode, but this was not enforced,
which has been corrected.
(merge 41c64ae0e7 jc/show-branch-g-current later to maint).
* "git fetch" unnecessarily failed when an unexpected optional
section appeared in the output, which has been corrected.
(merge 7709acf7be jt/fetch-peek-optional-section later to maint).
* The way "git fetch" without "--update-head-ok" ensures that HEAD in
no worktree points at any ref being updated was too wasteful, which
has been optimized a bit.
(merge f7400da800 os/fetch-check-not-current-branch later to maint).
* "git fetch --recurse-submodules" from multiple remotes (either from
a remote group, or "--all") used to make one extra "git fetch" in
the submodules, which has been corrected.
(merge 0353c68818 jc/avoid-redundant-submodule-fetch later to maint).
* With a recent update to refuse access to repositories of other
people by default, "sudo make install" and "sudo git describe"
stopped working, which has been corrected.
(merge 6b11e3d52e cb/path-owner-check-with-sudo-plus later to maint).
* The tests that ensured merges stop when interfering local changes
are present did not make sure that local changes are preserved; now
they do.
(merge 4b317450ce jc/t6424-failing-merge-preserve-local-changes later to maint).
* Some real problems noticed by gcc 12 have been fixed, while false
positives have been worked around.
* Update the version of FreeBSD image used in Cirrus CI.
(merge c58bebd4c6 pb/use-freebsd-12.3-in-cirrus-ci later to maint).
* The multi-pack-index code did not protect the packfile it is going
to depend on from getting removed while in use, which has been
corrected.
(merge 4090511e40 tb/midx-race-in-pack-objects later to maint).
* Teach "git repack --geometric" work better with "--keep-pack" and
avoid corrupting the repository when packsize limit is used.
(merge 66731ff921 tb/geom-repack-with-keep-and-max later to maint).
* The documentation on the interaction between "--add-file" and
"--prefix" options of "git archive" has been improved.
(merge a75910602a rs/document-archive-prefix later to maint).
* A git subcommand like "git add -p" spawns a separate git process
while relaying its command line arguments. A pathspec with only
negative elements was mistakenly passed with an empty string, which
has been corrected.
(merge b02fdbc80a jc/all-negative-pathspec later to maint).
* With a more targeted workaround in http.c in another topic, we may
be able to lift this blanket "GCC12 dangling-pointer warning is
broken and unsalvageable" workaround.
(merge 419141e495 cb/buggy-gcc-12-workaround later to maint).
* A misconfigured 'branch..remote' led to a bug in configuration
parsing.
(merge f1dfbd9ee0 gc/zero-length-branch-config-fix later to maint).
* "git -c diff.submodule=log range-diff" did not show anything for
submodules that changed in the ranges being compared, and
"git -c diff.submodule=diff range-diff" did not work correctly.
Fix this by including the "--submodule=short" output
unconditionally to be compared.
* In Git 2.36 we revamped the way how hooks are invoked. One change
that is end-user visible is that the output of a hook is no longer
directly connected to the standard output of "git" that spawns the
hook, which was noticed post release. This is getting corrected.
(merge a082345372 ab/hooks-regression-fix later to maint).
* Updating the graft information invalidates the list of parents of
in-core commit objects that used to be in the graft file.
* "git show-ref --heads" (and "--tags") still iterated over all the
refs only to discard refs outside the specified area, which has
been corrected.
(merge c0c9d35e27 tb/show-ref-optim later to maint).
* Remove redundant copying (with index v3 and older) or possible
over-reading beyond end of mmapped memory (with index v4) has been
corrected.
(merge 6d858341d2 zh/read-cache-copy-name-entry-fix later to maint).
* Sample watchman interface hook sometimes failed to produce
correctly formatted JSON message, which has been corrected.
(merge 134047b500 sn/fsmonitor-missing-clock later to maint).
* Use-after-free (with another forget-to-free) fix.
(merge 323822c72b ab/remote-free-fix later to maint).
* Remove a coccinelle rule that is no longer relevant.
(merge b1299de4a1 jc/cocci-cleanup later to maint).
* Other code cleanup, docfix, build fix, etc.
(merge e6b2582da3 cm/reftable-0-length-memset later to maint).
(merge 0b75e5bf22 ab/misc-cleanup later to maint).
(merge 52e1ab8a76 ea/rebase-code-simplify later to maint).
(merge 756d15923b sg/safe-directory-tests-and-docs later to maint).
(merge d097a23bfa ds/do-not-call-bug-on-bad-refs later to maint).
(merge c36c27e75c rs/t7812-pcre2-ws-bug-test later to maint).
(merge 1da312742d gf/unused-includes later to maint).
(merge 465b30a92d pb/submodule-recurse-mode-enum later to maint).
(merge 82b28c4ed8 km/t3501-use-test-helpers later to maint).
(merge 72315e431b sa/t1011-use-helpers later to maint).
(merge 95b3002201 cg/vscode-with-gdb later to maint).
(merge fbe5f6b804 tk/p4-utf8-bom later to maint).
(merge 17f273ffba tk/p4-with-explicity-sync later to maint).
(merge 944db25c60 kf/p4-multiple-remotes later to maint).
(merge b014cee8de jc/update-ozlabs-url later to maint).
(merge 4ec5008062 pb/ggg-in-mfc-doc later to maint).
(merge af845a604d tb/receive-pack-code-cleanup later to maint).
(merge 2acf4cf001 js/ci-gcc-12-fixes later to maint).
(merge 05e280c0a6 jc/http-clear-finished-pointer later to maint).
(merge 8c49d704ef fh/transport-push-leakfix later to maint).
(merge 1d232d38bd tl/ls-tree-oid-only later to maint).
(merge db7961e6a6 gc/document-config-worktree-scope later to maint).
(merge ce18a30bb7 fs/ssh-default-key-command-doc later to maint).

View File

@ -1,17 +0,0 @@
Git 2.37.1 Release Notes
========================
This release merges up the fixes that appear in v2.30.5, v2.31.4,
v2.32.3, v2.33.4, v2.34.4, v2.35.4, and v2.36.2 to address the
security issue CVE-2022-29187; see the release notes for these
versions for details.
Fixes since Git 2.37
--------------------
* Rewrite of "git add -i" in C that appeared in Git 2.25 didn't
correctly record a removed file to the index, which is an old
regression but has become widely known because the C version has
become the default in the latest release.
* Fix for CVS-2022-29187.

View File

@ -1,88 +0,0 @@
Git 2.37.2 Release Notes
========================
This primarily is to backport various fixes accumulated on the 'master'
front since 2.37.1.
Fixes since v2.37.1
-------------------
* "git shortlog -n" relied on the underlying qsort() to be stable,
which shouldn't have. Fixed.
* Variable quoting fix in the vimdiff driver of "git mergetool".
* An earlier attempt to plug leaks placed a clean-up label to jump to
at a bogus place, which as been corrected.
* Fixes a long-standing corner case bug around directory renames in
the merge-ort strategy.
* Recent update to vimdiff layout code has been made more robust
against different end-user vim settings.
* In a non-bare repository, the behavior of Git when the
core.worktree configuration variable points at a directory that has
a repository as its subdirectory, regressed in Git 2.27 days.
* References to commands-to-be-typed-literally in "git rebase"
documentation mark-up have been corrected.
* Give _() markings to fatal/warning/usage: labels that are shown in
front of these messages.
* "git mktree --missing" lazily fetched objects that are missing from
the local object store, which was totally unnecessary for the purpose
of creating the tree object(s) from its input.
* Fixes for tests when the source directory has unusual characters in
its path, e.g. whitespaces, double-quotes, etc.
* Adjust technical/bitmap-format to be formatted by AsciiDoc, and
add some missing information to the documentation.
* Certain diff options are currently ignored when combined-diff is
shown; mark them as incompatible with the feature.
* "git clone" from a repository with some ref whose HEAD is unborn
did not set the HEAD in the resulting repository correctly, which
has been corrected.
* mkstemp() emulation on Windows has been improved.
* Add missing documentation for "include" and "includeIf" features in
"git config" file format, which incidentally teaches the command
line completion to include them in its offerings.
* Avoid "white/black-list" in documentation and code comments.
* Workaround for a compiler warning against use of die() in
osx-keychain (in contrib/).
* Workaround for a false positive compiler warning.
* The resolve-undo information in the index was not protected against
GC, which has been corrected.
* A corner case bug where lazily fetching objects from a promisor
remote resulted in infinite recursion has been corrected.
* "git p4" working on UTF-16 files on Windows did not implement
CRLF-to-LF conversion correctly, which has been corrected.
* "git p4" did not handle non-ASCII client name well, which has been
corrected.
* "rerere-train" script (in contrib/) used to honor commit.gpgSign
while recreating the throw-away merges.
* "git checkout" miscounted the paths it updated, which has been
corrected.
* Fix for a bug that makes write-tree to fail to write out a
non-existent index as a tree, introduced in 2.37.
* There was a bug in the codepath to upgrade generation information
in commit-graph from v1 to v2 format, which has been corrected.
Also contains minor documentation updates and code clean-ups.

View File

@ -1,46 +0,0 @@
Git 2.37.3 Release Notes
========================
This primarily is to backport various fixes accumulated on the 'master'
front since 2.37.2.
Fixes since v2.37.2
-------------------
* The build procedure for Windows that uses CMake has been updated to
pick up the shell interpreter from local installation location.
* Conditionally allow building Python interpreter on Windows
* Fix to lstat() emulation on Windows.
* Older gcc with -Wall complains about the universal zero initializer
"struct s = { 0 };" idiom, which makes developers' lives
inconvenient (as -Werror is enabled by DEVELOPER=YesPlease). The
build procedure has been tweaked to help these compilers.
* Plug memory leaks in the failure code path in the "merge-ort" merge
strategy backend.
* Avoid repeatedly running getconf to ask libc version in the test
suite, and instead just as it once per script.
* Platform-specific code that determines if a directory is OK to use
as a repository has been taught to report more details, especially
on Windows.
* "vimdiff3" regression has been corrected.
* "git fsck" reads mode from tree objects but canonicalizes the mode
before passing it to the logic to check object sanity, which has
hid broken tree objects from the checking logic. This has been
corrected, but to help exiting projects with broken tree objects
that they cannot fix retroactively, the severity of anomalies this
code detects has been demoted to "info" for now.
* Fixes to sparse index compatibility work for "reset" and "checkout"
commands.
* Documentation for "git add --renormalize" has been improved.
Also contains other minor documentation updates and code clean-ups.

View File

@ -1,31 +0,0 @@
Git 2.37.4 Release Notes
========================
This primarily is to backport various fixes accumulated on the 'master'
front since 2.37.3.
Fixes since v2.37.3
-------------------
* An earlier optimization discarded a tree-object buffer that is
still in use, which has been corrected.
* Fix deadlocks between main Git process and subprocess spawned via
the pipe_command() API, that can kill "git add -p" that was
reimplemented in C recently.
* xcalloc(), imitating calloc(), takes "number of elements of the
array", and "size of a single element", in this order. A call that
does not follow this ordering has been corrected.
* The preload-index codepath made copies of pathspec to give to
multiple threads, which were left leaked.
* Update the version of Ubuntu used for GitHub Actions CI from 18.04
to 22.04.
* The auto-stashed local changes created by "git merge --autostash"
was mixed into a conflicted state left in the working tree, which
has been corrected.
Also contains other minor documentation updates and code clean-ups.

View File

@ -1,404 +0,0 @@
Git v2.38 Release Notes
=======================
UI, Workflows & Features
* "git remote show [-n] frotz" now pays attention to negative
pathspec.
* "git push" sometimes performs poorly when reachability bitmaps are
used, even in a repository where other operations are helped by
bitmaps. The push.useBitmaps configuration variable is introduced
to allow disabling use of reachability bitmaps only for "git push".
* "git grep -m<max-hits>" is a way to limit the hits shown per file.
* "git merge-tree" learned a new mode where it takes two commits and
computes a tree that would result in the merge commit, if the
histories leading to these two commits were to be merged.
* "git mv A B" in a sparsely populated working tree can be asked to
move a path between directories that are "in cone" (i.e. expected
to be materialized in the working tree) and "out of cone"
(i.e. expected to be hidden). The handling of such cases has been
improved.
* Earlier, HTTP transport clients learned to tell the server side
what locale they are in by sending Accept-Language HTTP header, but
this was done only for some requests but not others.
* Introduce a safe.barerepository configuration variable that
allows users to forbid discovery of bare repositories.
* Various messages that come from the pack-bitmap codepaths have been
tweaked.
* "git rebase -i" learns to update branches whose tip appear in the
rebased range with "--update-refs" option.
* "git ls-files" learns the "--format" option to tweak its output.
* "git cat-file" learned an option to use the mailmap when showing
commit and tag objects.
* When "git merge" finds that it cannot perform a merge, it should
restore the working tree to the state before the command was
initiated, but in some corner cases it didn't.
* Operating modes like "--batch" of "git cat-file" command learned to
take NUL-terminated input, instead of one-item-per-line.
* "git rm" has become more aware of the sparse-index feature.
* "git rev-list --disk-usage" learned to take an optional value
"human" to show the reported value in human-readable format, like
"3.40MiB".
* The "diagnose" feature to create a zip archive for diagnostic
material has been lifted from "scalar" and made into a feature of
"git bugreport".
* The namespaces used by "log --decorate" from "refs/" hierarchy by
default has been tightened.
* "git rev-list --ancestry-path=C A..B" is a natural extension of
"git rev-list A..B"; instead of choosing a subset of A..B to those
that have ancestry relationship with A, it lets a subset with
ancestry relationship with C.
* "scalar" now enables built-in fsmonitor on enlisted repositories,
when able.
* The bash prompt (in contrib/) learned to optionally indicate when
the index is unmerged.
* "git clone" command learned the "--bundle-uri" option to coordinate
with hosting sites the use of pre-prepared bundle files.
* "git range-diff" learned to honor pathspec argument if given.
* "git format-patch --from=<ident>" can be told to add an in-body
"From:" line even for commits that are authored by the given
<ident> with "--force-in-body-from" option.
* The built-in fsmonitor refuses to work on a network mounted
repositories; a configuration knob for users to override this has
been introduced.
* The "scalar" addition from Microsoft is now part of the core Git
installation.
Performance, Internal Implementation, Development Support etc.
* Collection of what is referenced by objects in promisor packs have
been optimized to inspect these objects in the in-pack order.
* Introduce a helper to see if a branch is already being worked on
(hence should not be newly checked out in a working tree), which
performs much better than the existing find_shared_symref() to
replace many uses of the latter.
* Teach "git archive" to (optionally and then by default) avoid
spawning an external "gzip" process when creating ".tar.gz" (and
".tgz") archives.
* Allow large objects read from a packstream to be streamed into a
loose object file straight, without having to keep it in-core as a
whole.
* Further preparation to turn git-submodule.sh into a builtin
continues.
* Apply Coccinelle rule to turn raw memmove() into MOVE_ARRAY() cpp
macro, which would improve maintainability and readability.
* Teach "make all" to build gitweb as well.
* Tweak tests so that they still work when the "git init" template
did not create .git/info directory.
* Add Coccinelle rules to detect the pattern of initializing and then
finalizing a structure without using it in between at all, which
happens after code restructuring and the compilers fail to
recognize as an unused variable.
* The code to convert between GPG trust level strings and internal
constants we use to represent them have been cleaned up.
* Support for libnettle as SHA256 implementation has been added.
* The way "git multi-pack" uses parse-options API has been improved.
* A Coccinelle rule (in contrib/) to encourage use of COPY_ARRAY
macro has been improved.
* API tweak to make it easier to run fuzz testing on commit-graph parser.
* Omit fsync-related trace2 entries when their values are all zero.
* The codepath to write multi-pack index has been taught to release a
large chunk of memory that holds an array of objects in the packs,
as soon as it is done with the array, to reduce memory consumption.
* Add a level of redirection to array allocation API in xdiff part,
to make it easier to share with the libgit2 project.
* "git fetch" client logs the partial clone filter used in the trace2
output.
* The "bundle URI" design gets documented.
* The common ancestor negotiation exchange during a "git fetch"
session now leaves trace log.
* Test portability improvements.
(merge 4d1d843be7 mt/rot13-in-c later to maint).
* The "subcommand" mode is introduced to parse-options API and update
the command line parser of Git commands with subcommands.
* The pack bitmap file gained a bitmap-lookup table to speed up
locating the necessary bitmap for a given commit.
* The assembly version of SHA-1 implementation for PPC has been
removed.
* The server side that responds to "git fetch" and "git clone"
request has been optimized by allowing it to send objects in its
object store without recomputing and validating the object names.
* Annotate function parameters that are not used (but cannot be
removed for structural reasons), to prepare us to later compile
with -Wunused warning turned on.
* Share the text used to explain configuration variables used by "git
<subcmd>" in "git help <subcmd>" with the text from "git help config".
* "git mv A B" in a sparsely populated working tree can be asked to
move a path from a directory that is "in cone" to another directory
that is "out of cone". Handling of such a case has been improved.
* The chainlint script for our tests has been revamped.
Fixes since v2.37
-----------------
* Rewrite of "git add -i" in C that appeared in Git 2.25 didn't
correctly record a removed file to the index, which was fixed.
* Certain diff options are currently ignored when combined-diff is
shown; mark them as incompatible with the feature.
* Adjust technical/bitmap-format to be formatted by AsciiDoc, and
add some missing information to the documentation.
* Fixes for tests when the source directory has unusual characters in
its path, e.g. whitespaces, double-quotes, etc.
* "git mktree --missing" lazily fetched objects that are missing from
the local object store, which was totally unnecessary for the purpose
of creating the tree object(s) from its input.
* Give _() markings to fatal/warning/usage: labels that are shown in
front of these messages.
* References to commands-to-be-typed-literally in "git rebase"
documentation mark-up have been corrected.
* In a non-bare repository, the behavior of Git when the
core.worktree configuration variable points at a directory that has
a repository as its subdirectory, regressed in Git 2.27 days.
* Recent update to vimdiff layout code has been made more robust
against different end-user vim settings.
* Plug various memory leaks, both in the main code and in test-tool
commands.
* Fixes a long-standing corner case bug around directory renames in
the merge-ort strategy.
* The resolve-undo information in the index was not protected against
GC, which has been corrected.
* A corner case bug where lazily fetching objects from a promisor
remote resulted in infinite recursion has been corrected.
* "git clone" from a repository with some ref whose HEAD is unborn
did not set the HEAD in the resulting repository correctly, which
has been corrected.
* An earlier attempt to plug leaks placed a clean-up label to jump to
at a bogus place, which as been corrected.
* Variable quoting fix in the vimdiff driver of "git mergetool"
* "git shortlog -n" relied on the underlying qsort() to be stable,
which shouldn't have. Fixed.
* A fix for a regression in test framework.
* mkstemp() emulation on Windows has been improved.
* Add missing documentation for "include" and "includeIf" features in
"git config" file format, which incidentally teaches the command
line completion to include them in its offerings.
* Avoid "white/black-list" in documentation and code comments.
* Workaround for a compiler warning against use of die() in
osx-keychain (in contrib/).
* Workaround for a false positive compiler warning.
* "git p4" working on UTF-16 files on Windows did not implement
CRLF-to-LF conversion correctly, which has been corrected.
* "git p4" did not handle non-ASCII client name well, which has been
corrected.
* "rerere-train" script (in contrib/) used to honor commit.gpgSign
while recreating the throw-away merges.
* "git checkout" miscounted the paths it updated, which has been
corrected.
* Fix for a bug that makes write-tree to fail to write out a
non-existent index as a tree, introduced in 2.37.
* There was a bug in the codepath to upgrade generation information
in commit-graph from v1 to v2 format, which has been corrected.
* Gitweb had legacy URL shortener that is specific to the way
projects hosted on kernel.org used to (but no longer) work, which
has been removed.
* Fix build procedure for Windows that uses CMake so that it can pick
up the shell interpreter from local installation location.
* Conditionally allow building Python interpreter on Windows
* Fix to lstat() emulation on Windows.
* Older gcc with -Wall complains about the universal zero initializer
"struct s = { 0 };" idiom, which makes developers' lives
inconvenient (as -Werror is enabled by DEVELOPER=YesPlease). The
build procedure has been tweaked to help these compilers.
* Plug memory leaks in the failure code path in the "merge-ort" merge
strategy backend.
* "git symbolic-ref symref non..sen..se" is now diagnosed as an error.
* A follow-up fix to a fix for a regression in 2.36 around hooks.
* Avoid repeatedly running getconf to ask libc version in the test
suite, and instead just as it once per script.
* Platform-specific code that determines if a directory is OK to use
as a repository has been taught to report more details, especially
on Windows.
* "vimdiff3" regression fix.
* "git fsck" reads mode from tree objects but canonicalizes the mode
before passing it to the logic to check object sanity, which has
hid broken tree objects from the checking logic. This has been
corrected, but to help existing projects with broken tree objects
that they cannot fix retroactively, the severity of anomalies this
code detects has been demoted to "info" for now.
* Fixes to sparse index compatibility work for "reset" and "checkout"
commands.
* An earlier optimization discarded a tree-object buffer that is
still in use, which has been corrected.
* Fix deadlocks between main Git process and subprocess spawned via
the pipe_command() API, that can kill "git add -p" that was
reimplemented in C recently.
* The sequencer machinery translated messages left in the reflog by
mistake, which has been corrected.
* xcalloc(), imitating calloc(), takes "number of elements of the
array", and "size of a single element", in this order. A call that
does not follow this ordering has been corrected.
* The preload-index codepath made copies of pathspec to give to
multiple threads, which were left leaked.
* Update the version of Ubuntu used for GitHub Actions CI from 18.04
to 22.04.
* The auto-stashed local changes created by "git merge --autostash"
was mixed into a conflicted state left in the working tree, which
has been corrected.
* Multi-pack index got corrupted when preferred pack changed from one
pack to another in a certain way, which has been corrected.
(merge 99e4d084ff tb/midx-with-changing-preferred-pack-fix later to maint).
* The clean-up of temporary files created via mks_tempfile_dt() was
racy and attempted to unlink() the leading directory when signals
are involved, which has been corrected.
(merge babe2e0559 rs/tempfile-cleanup-race-fix later to maint).
* FreeBSD portability fix for "git maintenance" that spawns "crontab"
to schedule tasks.
(merge ee69e7884e bc/gc-crontab-fix later to maint).
* Those who use diff-so-fancy as the diff-filter noticed a regression
or two in the code that parses the diff output in the built-in
version of "add -p", which has been corrected.
(merge 0a101676e5 js/add-p-diff-parsing-fix later to maint).
* Segfault fix-up to an earlier fix to the topic to teach "git reset"
and "git checkout" work better in a sparse checkout.
(merge 037f8ea6d9 vd/sparse-reset-checkout-fixes later to maint).
* "git diff --no-index A B" managed its the pathnames of its two
input files rather haphazardly, sometimes leaking them. The
command line argument processing has been straightened out to clean
it up.
(merge 2b43dd0eb5 rs/diff-no-index-cleanup later to maint).
* "git rev-list --verify-objects" ought to inspect the contents of
objects and notice corrupted ones, but it didn't when the commit
graph is in use, which has been corrected.
(merge b27ccae34b jk/rev-list-verify-objects-fix later to maint).
* More fixes to "add -p"
(merge 64ec8efb83 js/builtin-add-p-portability-fix later to maint).
* The parser in the script interface to parse-options in "git
rev-parse" has been updated to diagnose a bogus input correctly.
(merge f20b9c36d0 ow/rev-parse-parseopt-fix later to maint).
* The code that manages list-object-filter structure, used in partial
clones, leaked the instances, which has been plugged.
(merge 66eede4a37 jk/plug-list-object-filter-leaks later to maint).
* Fix another UI regression in the reimplemented "add -p".
(merge f6f0ee247f rs/add-p-worktree-mode-prompt-fix later to maint).
* "git fetch" over protocol v2 sent an incorrect ref prefix request
to the server and made "git pull" with configured fetch refspec
that does not cover the remote branch to merge with fail, which has
been corrected.
(merge 49ca2fba39 jk/proto-v2-ref-prefix-fix later to maint).
* A result from opendir() was leaking in the commit-graph expiration
codepath, which has been plugged.
(merge 12f1ae5324 ml/commit-graph-expire-dir-leak-fix later to maint).
* Just like we have coding guidelines, we now have guidelines for
reviewers.
(merge e01b851923 vd/doc-reviewing-guidelines later to maint).
* Other code cleanup, docfix, build fix, etc.
(merge 77b9e85c0f vd/fix-perf-tests later to maint).
(merge 0682bc43f5 jk/test-crontab-fixes later to maint).
(merge b46dd1726c cc/doc-trailer-whitespace-rules later to maint).

View File

@ -1,162 +0,0 @@
Reviewing Patches in the Git Project
====================================
Introduction
------------
The Git development community is a widely distributed, diverse, ever-changing
group of individuals. Asynchronous communication via the Git mailing list poses
unique challenges when reviewing or discussing patches. This document contains
some guiding principles and helpful tools you can use to make your reviews both
more efficient for yourself and more effective for other contributors.
Note that none of the recommendations here are binding or in any way a
requirement of participation in the Git community. They are provided as a
resource to supplement your skills as a contributor.
Principles
----------
Selecting patch(es) to review
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are looking for a patch series in need of review, start by checking
latest "What's cooking in git.git" email
(https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/[example]). The "What's
cooking" emails & replies can be found using the query `s:"What's cooking"` on
the https://lore.kernel.org/git/[`lore.kernel.org` mailing list archive];
alternatively, you can find the contents of the "What's cooking" email tracked
in `whats-cooking.txt` on the `todo` branch of Git. Topics tagged with "Needs
review" and those in the "[New Topics]" section are typically those that would
benefit the most from additional review.
Patches can also be searched manually in the mailing list archive using a query
like `s:"PATCH" -s:"Re:"`. You can browse these results for topics relevant to
your expertise or interest.
If you've already contributed to Git, you may also be CC'd in another
contributor's patch series. These are topics where the author feels that your
attention is warranted. This may be because their patch changes something you
wrote previously (making you a good judge of whether the new approach does or
doesn't work), or because you have the expertise to provide an exceptionally
helpful review. There is no requirement to review these patches but, in the
spirit of open source collaboration, you should strongly consider doing so.
Reviewing patches
~~~~~~~~~~~~~~~~~
While every contributor takes their own approach to reviewing patches, here are
some general pieces of advice to make your reviews as clear and helpful as
possible. The advice is broken into two rough categories: high-level reviewing
guidance, and concrete tips for interacting with patches on the mailing list.
==== High-level guidance
- Remember to review the content of commit messages for correctness and clarity,
in addition to the code change in the patch's diff. The commit message of a
patch should accurately and fully explain the code change being made in the
diff.
- Reviewing test coverage is an important - but easy to overlook - component of
reviews. A patch's changes may be covered by existing tests, or new tests may
be introduced to exercise new behavior. Checking out a patch or series locally
allows you to manually mutate lines of new & existing tests to verify expected
pass/fail behavior. You can use this information to verify proper coverage or
to suggest additional tests the author could add.
- When providing a recommendation, be as clear as possible about whether you
consider it "blocking" (the code would be broken or otherwise made worse if an
issue isn't fixed) or "non-blocking" (the patch could be made better by taking
the recommendation, but acceptance of the series does not require it).
Non-blocking recommendations can be particularly ambiguous when they are
related to - but outside the scope of - a series ("nice-to-have"s), or when
they represent only stylistic differences between the author and reviewer.
- When commenting on an issue, try to include suggestions for how the author
could fix it. This not only helps the author to understand and fix the issue,
it also deepens and improves your understanding of the topic.
- Reviews do not need to exclusively point out problems. Feel free to "think out
loud" in your review: describe how you read & understood a complex section of
a patch, ask a question about something that confused you, point out something
you found exceptionally well-written, etc. In particular, uplifting feedback
goes a long way towards encouraging contributors to participate more actively
in the Git community.
==== Performing your review
- Provide your review comments per-patch in a plaintext "Reply-All" email to the
relevant patch. Comments should be made inline, immediately below the relevant
section(s).
- You may find that the limited context provided in the patch diff is sometimes
insufficient for a thorough review. In such cases, you can review patches in
your local tree by either applying patches with linkgit:git-am[1] or checking
out the associated branch from https://github.com/gitster/git once the series
is tracked there.
- Large, complicated patch diffs are sometimes unavoidable, such as when they
refactor existing code. If you find such a patch difficult to parse, try
reviewing the diff produced with the `--color-moved` and/or
`--ignore-space-change` options.
- If a patch is long, you are encouraged to delete parts of it that are
unrelated to your review from the email reply. Make sure to leave enough
context for readers to understand your comments!
- If you cannot complete a full review of a series all at once, consider letting
the author know (on- or off-list) if/when you plan to review the rest of the
series.
Completing a review
~~~~~~~~~~~~~~~~~~~
Once each patch of a series is reviewed, the author (and/or other contributors)
may discuss the review(s). This may result in no changes being applied, or the
author will send a new version of their patch(es).
After a series is rerolled in response to your or others' review, make sure to
re-review the updates. If you are happy with the state of the patch series,
explicitly indicate your approval (typically with a reply to the latest
version's cover letter). Optionally, you can let the author know that they can
add a "Reviewed-by: <you>" trailer if they resubmit the reviewed patch verbatim
in a later iteration of the series.
Finally, subsequent "What's cooking" emails may explicitly ask whether a
reviewed topic is ready for merging to the `next` branch (typically phrased
"Will merge to \'next\'?"). You can help the maintainer and author by responding
with a short description of the state of your (and others', if applicable)
review, including the links to the relevant thread(s).
Terminology
-----------
nit: ::
Denotes a small issue that should be fixed, such as a typographical error
or mis-alignment of conditions in an `if()` statement.
aside: ::
optional: ::
non-blocking: ::
Indicates to the reader that the following comment should not block the
acceptance of the patch or series. These are typically recommendations
related to code organization & style, or musings about topics related to
the patch in question, but beyond its scope.
s/<before>/<after>/::
Shorthand for "you wrote <before>, but I think you meant <after>," usually
for misspellings or other typographical errors. The syntax is a reference
to "substitute" command commonly found in Unix tools such as `ed`, `sed`,
`vim`, and `perl`.
cover letter::
The "Patch 0" of a multi-patch series. This email describes the
high-level intent and structure of the patch series to readers on the
Git mailing list. It is also where the changelog notes and range-diff of
subsequent versions are provided by the author.
+
On single-patch submissions, cover letter content is typically not sent as a
separate email. Instead, it is inserted between the end of the patch's commit
message (after the `---`) and the beginning of the diff.
#leftoverbits::
Used by either an author or a reviewer to describe features or suggested
changes that are out-of-scope of a given patch or series, but are relevant
to the topic for the sake of discussion.
See Also
--------
link:MyFirstContribution.html[MyFirstContribution]

View File

@ -110,35 +110,6 @@ run `git diff --check` on your changes before you commit.
[[describe-changes]]
=== Describe your changes well.
The log message that explains your changes is just as important as the
changes themselves. Your code may be clearly written with in-code
comment to sufficiently explain how it works with the surrounding
code, but those who need to fix or enhance your code in the future
will need to know _why_ your code does what it does, for a few
reasons:
. Your code may be doing something differently from what you wanted it
to do. Writing down what you actually wanted to achieve will help
them fix your code and make it do what it should have been doing
(also, you often discover your own bugs yourself, while writing the
log message to summarize the thought behind it).
. Your code may be doing things that were only necessary for your
immediate needs (e.g. "do X to directories" without implementing or
even designing what is to be done on files). Writing down why you
excluded what the code does not do will help guide future developers.
Writing down "we do X to directories, because directories have
characteristic Y" would help them infer "oh, files also have the same
characteristic Y, so perhaps doing X to them would also make sense?".
Saying "we don't do the same X to files, because ..." will help them
decide if the reasoning is sound (in which case they do not waste
time extending your code to cover files), or reason differently (in
which case, they can explain why they extend your code to cover
files, too).
The goal of your log message is to convey the _why_ behind your
change to help future developers.
The first line of the commit message should be a short description (50
characters is the soft limit, see DISCUSSION in linkgit:git-commit[1]),
and should skip the full stop. It is also conventional in most cases to
@ -171,13 +142,6 @@ The body should provide a meaningful commit message, which:
. alternate solutions considered but discarded, if any.
[[present-tense]]
The problem statement that describes the status quo is written in the
present tense. Write "The code does X when it is given input Y",
instead of "The code used to do Y when given input X". You do not
have to say "Currently"---the status quo in the problem statement is
about the code _without_ your change, by project convention.
[[imperative-mood]]
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
@ -452,10 +416,7 @@ repositories.
- `gitk-git/` comes from Paul Mackerras's gitk project:
git://git.ozlabs.org/~paulus/gitk
Those who are interested in improve gitk can volunteer to help Paul
in maintaining it cf. <YntxL/fTplFm8lr6@cleo>.
git://ozlabs.org/~paulus/gitk
- `po/` comes from the localization coordinator, Jiang Xin:

View File

@ -1,51 +0,0 @@
Tools for developing Git
========================
:sectanchors:
[[summary]]
== Summary
This document gathers tips, scripts and configuration file to help people
working on Git's codebase use their favorite tools while following Git's
coding style.
[[author]]
=== Author
The Git community.
[[table_of_contents]]
== Table of contents
- <<vscode>>
- <<emacs>>
[[vscode]]
=== Visual Studio Code (VS Code)
The contrib/vscode/init.sh script creates configuration files that enable
several valuable VS Code features. See contrib/vscode/README.md for more
information on using the script.
[[emacs]]
=== Emacs
This is adapted from Linux's suggestion in its CodingStyle document:
- To follow rules of the CodingGuideline, it's useful to put the following in
GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
----
;; note the first part is useful for C editing, too
((nil . ((indent-tabs-mode . t)
(tab-width . 8)
(fill-column . 80)))
(cperl-mode . ((cperl-indent-level . 8)
(cperl-extra-newline-before-brace . nil)
(cperl-merge-trailing-else . t))))
----
For a more complete setup, since Git's codebase uses a coding style
similar to the Linux kernel's style, tips given in Linux's CodingStyle
document can be applied here too.
==== https://www.kernel.org/doc/html/v4.10/process/coding-style.html#you-ve-made-a-mess-of-it

View File

@ -10,7 +10,7 @@ sub format_one {
$state = 0;
open I, '<', "$name.txt" or die "No such file $name.txt";
while (<I>) {
if (/^(?:git|scalar)[a-z0-9-]*\(([0-9])\)$/) {
if (/^git[a-z0-9-]*\(([0-9])\)$/) {
$mansection = $1;
next;
}

View File

@ -159,33 +159,6 @@ all branches that begin with `foo/`. This is useful if your branches are
organized hierarchically and you would like to apply a configuration to
all the branches in that hierarchy.
`hasconfig:remote.*.url:`::
The data that follows this keyword is taken to
be a pattern with standard globbing wildcards and two
additional ones, `**/` and `/**`, that can match multiple
components. The first time this keyword is seen, the rest of
the config files will be scanned for remote URLs (without
applying any values). If there exists at least one remote URL
that matches this pattern, the include condition is met.
+
Files included by this option (directly or indirectly) are not allowed
to contain remote URLs.
+
Note that unlike other includeIf conditions, resolving this condition
relies on information that is not yet known at the point of reading the
condition. A typical use case is this option being present as a
system-level or global-level config, and the remote URL being in a
local-level config; hence the need to scan ahead when resolving this
condition. In order to avoid the chicken-and-egg problem in which
potentially-included files can affect whether such files are potentially
included, Git breaks the cycle by prohibiting these files from affecting
the resolution of these conditions (thus, prohibiting them from
declaring remote URLs).
+
As for the naming of this keyword, it is for forwards compatibiliy with
a naming scheme that supports more variable-based include conditions,
but currently Git only supports the exact keyword described above.
A few more notes on matching via `gitdir` and `gitdir/i`:
* Symlinks in `$GIT_DIR` are not resolved before matching.
@ -253,14 +226,6 @@ Example
; currently checked out
[includeIf "onbranch:foo-branch"]
path = foo.inc
; include only if a remote with the given URL exists (note
; that such a URL may be provided later in a file or in a
; file read after this file is read, as seen in this example)
[includeIf "hasconfig:remote.*.url:https://example.com/**"]
path = foo.inc
[remote "origin"]
url = https://example.com/git
----
Values
@ -445,8 +410,6 @@ include::config/i18n.txt[]
include::config/imap.txt[]
include::config/includeif.txt[]
include::config/index.txt[]
include::config/init.txt[]
@ -497,7 +460,7 @@ include::config/repack.txt[]
include::config/rerere.txt[]
include::config/revert.txt[]
include::config/reset.txt[]
include::config/safe.txt[]
@ -507,8 +470,6 @@ include::config/sequencer.txt[]
include::config/showbranch.txt[]
include::config/sparse.txt[]
include::config/splitindex.txt[]
include::config/ssh.txt[]

View File

@ -7,6 +7,6 @@ add.ignore-errors (deprecated)::
variables.
add.interactive.useBuiltin::
Set to `false` to fall back to the original Perl implementation of
the interactive version of linkgit:git-add[1] instead of the built-in
version. Is `true` by default.
[EXPERIMENTAL] Set to `true` to use the experimental built-in
implementation of the interactive version of linkgit:git-add[1]
instead of the Perl script version. Is `false` by default.

View File

@ -4,10 +4,6 @@ advice.*::
can tell Git that you do not need help by setting these to 'false':
+
--
ambiguousFetchRefspec::
Advice shown when fetch refspec for multiple remotes map to
the same remote-tracking branch namespace and causes branch
tracking set-up to fail.
fetchShowForcedUpdates::
Advice shown when linkgit:git-fetch[1] takes a long time
to calculate forced updates after ref updates, or to warn
@ -71,10 +67,10 @@ advice.*::
commitBeforeMerge::
Advice shown when linkgit:git-merge[1] refuses to
merge to avoid overwriting local changes.
resetNoRefresh::
Advice to consider using the `--no-refresh` option to
linkgit:git-reset[1] when the command takes more than 2 seconds
to refresh the index after reset.
resetQuiet::
Advice to consider using the `--quiet` option to linkgit:git-reset[1]
when the command takes more than 2 seconds to enumerate unstaged
changes after reset.
resolveConflict::
Advice shown by various commands when conflicts
prevent the operation from being performed.
@ -89,9 +85,6 @@ advice.*::
linkgit:git-switch[1] or linkgit:git-checkout[1]
to move to the detach HEAD state, to instruct how to
create a local branch after the fact.
suggestDetachingHead::
Advice shown when linkgit:git-switch[1] refuses to detach HEAD
without the explicit `--detach` option.
checkoutAmbiguousRemoteBranchName::
Advice shown when the argument to
linkgit:git-checkout[1] and linkgit:git-switch[1]
@ -123,9 +116,6 @@ advice.*::
submoduleAlternateErrorStrategyDie::
Advice shown when a submodule.alternateErrorStrategy option
configured to "die" causes a fatal error.
submodulesNotUpdated::
Advice shown when a user runs a submodule command that fails
because `git submodule update --init` was not run.
addIgnoredFile::
Advice shown if a user attempts to add an ignored file to
the index.

View File

@ -9,9 +9,7 @@ branch.autoSetupMerge::
automatic setup is done when the starting point is either a
local branch or remote-tracking branch; `inherit` -- if the starting point
has a tracking configuration, it is copied to the new
branch; `simple` -- automatic setup is done only when the starting point
is a remote-tracking branch and the new branch has the same name as the
remote branch. This option defaults to true.
branch. This option defaults to true.
branch.autoSetupRebase::
When a new branch is created with 'git branch', 'git switch' or 'git checkout'
@ -40,9 +38,8 @@ branch.<name>.remote::
may be overridden with `remote.pushDefault` (for all branches).
The remote to push to, for the current branch, may be further
overridden by `branch.<name>.pushRemote`. If no remote is
configured, or if you are not on any branch and there is more than
one remote defined in the repository, it defaults to `origin` for
fetching and `remote.pushDefault` for pushing.
configured, or if you are not on any branch, it defaults to
`origin` for fetching and `remote.pushDefault` for pushing.
Additionally, `.` (a period) is the current local repository
(a dot-repository), see `branch.<name>.merge`'s final note below.

View File

@ -6,8 +6,3 @@ clone.defaultRemoteName::
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]
clone.filterSubmodules::
If a partial clone filter is provided (see `--filter` in
linkgit:git-rev-list[1]) and `--recurse-submodules` is used, also apply
the filter to submodules.

View File

@ -62,54 +62,22 @@ core.protectNTFS::
Defaults to `true` on Windows, and `false` elsewhere.
core.fsmonitor::
If set to true, enable the built-in file system monitor
daemon for this working directory (linkgit:git-fsmonitor{litdd}daemon[1]).
+
Like hook-based file system monitors, the built-in file system monitor
can speed up Git commands that need to refresh the Git index
(e.g. `git status`) in a working directory with many files. The
built-in monitor eliminates the need to install and maintain an
external third-party tool.
+
The built-in file system monitor is currently available only on a
limited set of supported platforms. Currently, this includes Windows
and MacOS.
+
Otherwise, this variable contains the pathname of the "fsmonitor"
hook command.
+
This hook command is used to identify all files that may have changed
since the requested date/time. This information is used to speed up
git by avoiding unnecessary scanning of files that have not changed.
+
See the "fsmonitor-watchman" section of linkgit:githooks[5].
+
Note that if you concurrently use multiple versions of Git, such
as one version on the command line and another version in an IDE
tool, that the definition of `core.fsmonitor` was extended to
allow boolean values in addition to hook pathnames. Git versions
2.35.1 and prior will not understand the boolean values and will
consider the "true" or "false" values as hook pathnames to be
invoked. Git versions 2.26 thru 2.35.1 default to hook protocol
V2 and will fall back to no fsmonitor (full scan). Git versions
prior to 2.26 default to hook protocol V1 and will silently
assume there were no changes to report (no scan), so status
commands may report incomplete results. For this reason, it is
best to upgrade all of your Git versions before using the built-in
file system monitor.
If set, the value of this variable is used as a command which
will identify all files that may have changed since the
requested date/time. This information is used to speed up git by
avoiding unnecessary processing of files that have not changed.
See the "fsmonitor-watchman" section of linkgit:githooks[5].
core.fsmonitorHookVersion::
Sets the protocol version to be used when invoking the
"fsmonitor" hook.
+
There are currently versions 1 and 2. When this is not set,
version 2 will be tried first and if it fails then version 1
will be tried. Version 1 uses a timestamp as input to determine
which files have changes since that time but some monitors
like Watchman have race conditions when used with a timestamp.
Version 2 uses an opaque string so that the monitor can return
something that can be used to determine what files have changed
without race conditions.
Sets the version of hook that is to be used when calling fsmonitor.
There are currently versions 1 and 2. When this is not set,
version 2 will be tried first and if it fails then version 1
will be tried. Version 1 uses a timestamp as input to determine
which files have changes since that time but some monitors
like watchman have race conditions when used with a timestamp.
Version 2 uses an opaque string so that the monitor can return
something that can be used to determine what files have changed
without race conditions.
core.trustctime::
If false, the ctime differences between the index and the
@ -444,32 +412,17 @@ You probably do not need to adjust this value.
Common unit suffixes of 'k', 'm', or 'g' are supported.
core.bigFileThreshold::
The size of files considered "big", which as discussed below
changes the behavior of numerous git commands, as well as how
such files are stored within the repository. The default is
512 MiB. Common unit suffixes of 'k', 'm', or 'g' are
supported.
Files larger than this size are stored deflated, without
attempting delta compression. Storing large files without
delta compression avoids excessive memory usage, at the
slight expense of increased disk usage. Additionally files
larger than this size are always treated as binary.
+
Files above the configured limit will be:
Default is 512 MiB on all platforms. This should be reasonable
for most projects as source code and other text files can still
be delta compressed, but larger binary media files won't be.
+
* Stored deflated in packfiles, without attempting delta compression.
+
The default limit is primarily set with this use-case in mind. With it,
most projects will have their source code and other text files delta
compressed, but not larger binary media files.
+
Storing large files without delta compression avoids excessive memory
usage, at the slight expense of increased disk usage.
+
* Will be treated as if they were labeled "binary" (see
linkgit:gitattributes[5]). e.g. linkgit:git-log[1] and
linkgit:git-diff[1] will not compute diffs for files above this limit.
+
* Will generally be streamed when written, which avoids excessive
memory usage, at the cost of some fixed overhead. Commands that make
use of this include linkgit:git-archive[1],
linkgit:git-fast-import[1], linkgit:git-index-pack[1],
linkgit:git-unpack-objects[1] and linkgit:git-fsck[1].
Common unit suffixes of 'k', 'm', or 'g' are supported.
core.excludesFile::
Specifies the pathname to the file that contains patterns to
@ -594,72 +547,13 @@ core.whitespace::
is relevant for `indent-with-non-tab` and when Git fixes `tab-in-indent`
errors. The default tab width is 8. Allowed values are 1 to 63.
core.fsync::
A comma-separated list of components of the repository that
should be hardened via the core.fsyncMethod when created or
modified. You can disable hardening of any component by
prefixing it with a '-'. Items that are not hardened may be
lost in the event of an unclean system shutdown. Unless you
have special requirements, it is recommended that you leave
this option empty or pick one of `committed`, `added`,
or `all`.
+
When this configuration is encountered, the set of components starts with
the platform default value, disabled components are removed, and additional
components are added. `none` resets the state so that the platform default
is ignored.
+
The empty string resets the fsync configuration to the platform
default. The default on most platforms is equivalent to
`core.fsync=committed,-loose-object`, which has good performance,
but risks losing recent work in the event of an unclean system shutdown.
+
* `none` clears the set of fsynced components.
* `loose-object` hardens objects added to the repo in loose-object form.
* `pack` hardens objects added to the repo in packfile form.
* `pack-metadata` hardens packfile bitmaps and indexes.
* `commit-graph` hardens the commit graph file.
* `index` hardens the index when it is modified.
* `objects` is an aggregate option that is equivalent to
`loose-object,pack`.
* `reference` hardens references modified in the repo.
* `derived-metadata` is an aggregate option that is equivalent to
`pack-metadata,commit-graph`.
* `committed` is an aggregate option that is currently equivalent to
`objects`. This mode sacrifices some performance to ensure that work
that is committed to the repository with `git commit` or similar commands
is hardened.
* `added` is an aggregate option that is currently equivalent to
`committed,index`. This mode sacrifices additional performance to
ensure that the results of commands like `git add` and similar operations
are hardened.
* `all` is an aggregate option that syncs all individual components above.
core.fsyncMethod::
A value indicating the strategy Git will use to harden repository data
using fsync and related primitives.
+
* `fsync` uses the fsync() system call or platform equivalents.
* `writeout-only` issues pagecache writeback requests, but depending on the
filesystem and storage hardware, data added to the repository may not be
durable in the event of a system crash. This is the default mode on macOS.
* `batch` enables a mode that uses writeout-only flushes to stage multiple
updates in the disk writeback cache and then does a single full fsync of
a dummy file to trigger the disk cache flush at the end of the operation.
+
Currently `batch` mode only applies to loose-object files. Other repository
data is made durable as if `fsync` was specified. This mode is expected to
be as safe as `fsync` on macOS for repos stored on HFS+ or APFS filesystems
and on Windows for repos stored on NTFS or ReFS filesystems.
core.fsyncObjectFiles::
This boolean will enable 'fsync()' when writing object files.
This setting is deprecated. Use core.fsync instead.
+
This setting affects data added to the Git repository in loose-object
form. When set to true, Git will issue an fsync or similar system call
to flush caches so that loose-objects remain consistent in the face
of a unclean system shutdown.
This is a total waste of time and effort on a filesystem that orders
data writes properly, but can be useful for filesystems that do not use
journalling (traditional UNIX filesystems) or that only journal metadata
and not file contents (OS X's HFS+, or Linux ext3 with "data=writeback").
core.preloadIndex::
Enable parallel index preload for operations like 'git diff'
@ -721,10 +615,8 @@ core.sparseCheckout::
core.sparseCheckoutCone::
Enables the "cone mode" of the sparse checkout feature. When the
sparse-checkout file contains a limited set of patterns, this
mode provides significant performance advantages. The "non-cone
mode" can be requested to allow specifying more flexible
patterns by setting this variable to 'false'. See
sparse-checkout file contains a limited set of patterns, then this
mode provides significant performance advantages. See
linkgit:git-sparse-checkout[1] for more information.
core.abbrev::

View File

@ -178,6 +178,21 @@ diff.<driver>.cachetextconv::
Set this option to true to make the diff driver cache the text
conversion outputs. See linkgit:gitattributes[5] for details.
diff.tool::
Controls which diff tool is used by linkgit:git-difftool[1].
This variable overrides the value configured in `merge.tool`.
The list below shows the valid built-in values.
Any other value is treated as a custom diff tool and requires
that a corresponding difftool.<tool>.cmd variable is defined.
diff.guitool::
Controls which diff tool is used by linkgit:git-difftool[1] when
the -g/--gui flag is specified. This variable overrides the value
configured in `merge.guitool`. The list below shows the valid
built-in values. Any other value is treated as a custom diff tool
and requires that a corresponding difftool.<guitool>.cmd variable
is defined.
include::../mergetools-diff.txt[]
diff.indentHeuristic::

View File

@ -1,17 +1,6 @@
diff.tool::
Controls which diff tool is used by linkgit:git-difftool[1].
This variable overrides the value configured in `merge.tool`.
The list below shows the valid built-in values.
Any other value is treated as a custom diff tool and requires
that a corresponding difftool.<tool>.cmd variable is defined.
diff.guitool::
Controls which diff tool is used by linkgit:git-difftool[1] when
the -g/--gui flag is specified. This variable overrides the value
configured in `merge.guitool`. The list below shows the valid
built-in values. Any other value is treated as a custom diff tool
and requires that a corresponding difftool.<guitool>.cmd variable
is defined.
difftool.<tool>.path::
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
difftool.<tool>.cmd::
Specify the command to invoke the specified diff tool.
@ -20,17 +9,6 @@ difftool.<tool>.cmd::
file containing the contents of the diff pre-image and 'REMOTE'
is set to the name of the temporary file containing the contents
of the diff post-image.
+
See the `--tool=<tool>` option in linkgit:git-difftool[1] for more details.
difftool.<tool>.path::
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
difftool.trustExitCode::
Exit difftool if the invoked diff tool returns a non-zero exit status.
+
See the `--trust-exit-code` option in linkgit:git-difftool[1] for more details.
difftool.prompt::
Prompt before each invocation of the diff tool.

View File

@ -6,34 +6,3 @@ extensions.objectFormat::
Note that this setting should only be set by linkgit:git-init[1] or
linkgit:git-clone[1]. Trying to change it after initialization will not
work and will produce hard-to-diagnose issues.
extensions.worktreeConfig::
If enabled, then worktrees will load config settings from the
`$GIT_DIR/config.worktree` file in addition to the
`$GIT_COMMON_DIR/config` file. Note that `$GIT_COMMON_DIR` and
`$GIT_DIR` are the same for the main working tree, while other
working trees have `$GIT_DIR` equal to
`$GIT_COMMON_DIR/worktrees/<id>/`. The settings in the
`config.worktree` file will override settings from any other
config files.
+
When enabling `extensions.worktreeConfig`, you must be careful to move
certain values from the common config file to the main working tree's
`config.worktree` file, if present:
+
* `core.worktree` must be moved from `$GIT_COMMON_DIR/config` to
`$GIT_COMMON_DIR/config.worktree`.
* If `core.bare` is true, then it must be moved from `$GIT_COMMON_DIR/config`
to `$GIT_COMMON_DIR/config.worktree`.
+
It may also be beneficial to adjust the locations of `core.sparseCheckout`
and `core.sparseCheckoutCone` depending on your desire for customizable
sparse-checkout settings for each worktree. By default, the `git
sparse-checkout` builtin enables `extensions.worktreeConfig`, assigns
these config values on a per-worktree basis, and uses the
`$GIT_DIR/info/sparse-checkout` file to specify the sparsity for each
worktree independently. See linkgit:git-sparse-checkout[1] for more
details.
+
For historical reasons, `extensions.worktreeConfig` is respected
regardless of the `core.repositoryFormatVersion` setting.

View File

@ -56,19 +56,18 @@ fetch.output::
OUTPUT in linkgit:git-fetch[1] for detail.
fetch.negotiationAlgorithm::
Control how information about the commits in the local repository
is sent when negotiating the contents of the packfile to be sent by
the server. Set to "consecutive" to use an algorithm that walks
over consecutive commits checking each one. Set to "skipping" to
use an algorithm that skips commits in an effort to converge
faster, but may result in a larger-than-necessary packfile; or set
to "noop" to not send any information at all, which will almost
certainly result in a larger-than-necessary packfile, but will skip
the negotiation step. Set to "default" to override settings made
previously and use the default behaviour. The default is normally
"consecutive", but if `feature.experimental` is true, then the
default is "skipping". Unknown values will cause 'git fetch' to
error out.
Control how information about the commits in the local repository is
sent when negotiating the contents of the packfile to be sent by the
server. Set to "skipping" to use an algorithm that skips commits in an
effort to converge faster, but may result in a larger-than-necessary
packfile; or set to "noop" to not send any information at all, which
will almost certainly result in a larger-than-necessary packfile, but
will skip the negotiation step.
The default is "default" which instructs Git to use the default algorithm
that never skips commits (unless the server has acknowledged it or one
of its descendants). If `feature.experimental` is enabled, then this
setting defaults to "skipping".
Unknown values will cause 'git fetch' to error out.
+
See also the `--negotiate-only` and `--negotiation-tip` options to
linkgit:git-fetch[1].

View File

@ -15,10 +15,6 @@ format.from::
different. If set to a non-boolean value, format-patch uses that
value instead of your committer identity. Defaults to false.
format.forceInBodyFrom::
Provides the default value for the `--[no-]force-in-body-from`
option to format-patch. Defaults to false.
format.numbered::
A boolean which can enable or disable sequence numbers in patch
subjects. It defaults to "auto" which enables it only if there

View File

@ -81,21 +81,14 @@ gc.packRefs::
to enable it within all non-bare repos or it can be set to a
boolean value. The default is `true`.
gc.cruftPacks::
Store unreachable objects in a cruft pack (see
linkgit:git-repack[1]) instead of as loose objects. The default
is `false`.
gc.pruneExpire::
When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'
(and 'repack --cruft --cruft-expiration 2.weeks.ago' if using
cruft packs via `gc.cruftPacks` or `--cruft`). Override the
grace period with this config variable. The value "now" may be
used to disable this grace period and always prune unreachable
objects immediately, or "never" may be used to suppress pruning.
This feature helps prevent corruption when 'git gc' runs
concurrently with another process writing to the repository; see
the "NOTES" section of linkgit:git-gc[1].
When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'.
Override the grace period with this config variable. The value
"now" may be used to disable this grace period and always prune
unreachable objects immediately, or "never" may be used to
suppress pruning. This feature helps prevent corruption when
'git gc' runs concurrently with another process writing to the
repository; see the "NOTES" section of linkgit:git-gc[1].
gc.worktreePruneExpire::
When 'git gc' is run, it calls

View File

@ -36,12 +36,9 @@ gpg.minTrustLevel::
gpg.ssh.defaultKeyCommand::
This command that will be run when user.signingkey is not set and a ssh
signature is requested. On successful exit a valid ssh public key
prefixed with `key::` is expected in the first line of its output.
This allows for a script doing a dynamic lookup of the correct public
key when it is impractical to statically configure `user.signingKey`.
For example when keys or SSH Certificates are rotated frequently or
selection of the right key depends on external factors unknown to git.
signature is requested. On successful exit a valid ssh public key is
expected in the first line of its output. To automatically use the first
available key from your ssh-agent set this to "ssh-add -L".
gpg.ssh.allowedSignersFile::
A file containing ssh public keys which you are willing to trust.
@ -69,7 +66,7 @@ This way only committers with an already valid key can add or change keys in the
+
Since OpensSSH 8.8 this file allows specifying a key lifetime using valid-after &
valid-before options. Git will mark signatures as valid if the signing key was
valid at the time of the signature's creation. This allows users to change a
valid at the time of the signatures creation. This allows users to change a
signing key without invalidating all previously made signatures.
+
Using a SSH CA key with the cert-authority option

View File

@ -17,11 +17,8 @@ grep.extendedRegexp::
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.
Number of grep worker threads to use.
See `grep.threads` in linkgit:git-grep[1] for more information.
grep.fallbackToNoIndex::
If set to true, fall back to git grep --no-index if git grep

View File

@ -98,22 +98,6 @@ http.version::
- HTTP/2
- HTTP/1.1
http.curloptResolve::
Hostname resolution information that will be used first by
libcurl when sending HTTP requests. This information should
be in one of the following formats:
- [+]HOST:PORT:ADDRESS[,ADDRESS]
- -HOST:PORT
+
The first format redirects all requests to the given `HOST:PORT`
to the provided `ADDRESS`(s). The second format clears all
previous config values for that `HOST:PORT` combination. To
allow easy overriding of all the settings inherited from the
system config, an empty value will reset all resolution
information to the empty list.
http.sslVersion::
The SSL version to use when negotiating an SSL connection, if you
want to force the default. The available and default version
@ -203,7 +187,7 @@ http.schannelUseSSLCAInfo::
when the `schannel` backend was configured via `http.sslBackend`,
unless `http.schannelUseSSLCAInfo` overrides this behavior.
http.pinnedPubkey::
http.pinnedpubkey::
Public key of the https service. It may either be the filename of
a PEM or DER encoded public key file or a string starting with
'sha256//' followed by the base64 encoded sha256 hash of the

View File

@ -1,6 +0,0 @@
include.path::
includeIf.<condition>.path::
Special variables to include other configuration files. See
the "CONFIGURATION FILE" section in the main
linkgit:git-config[1] documentation,
specifically the "Includes" and "Conditional Includes" subsections.

View File

@ -7,10 +7,6 @@ log.date::
Set the default date-time mode for the 'log' command.
Setting a value for log.date is similar to using 'git log''s
`--date` option. See linkgit:git-log[1] for details.
+
If the format is set to "auto:foo" and the pager is in use, format
"foo" will be the used for the date format. Otherwise "default" will
be used.
log.decorate::
Print out the ref names of any commits that are shown by the log
@ -22,11 +18,6 @@ log.decorate::
names are shown. This is the same as the `--decorate` option
of the `git log`.
log.initialDecorationSet::
By default, `git log` only shows decorations for certain known ref
namespaces. If 'all' is specified, then show all refs as
decorations.
log.excludeDecoration::
Exclude the specified patterns from the log decorations. This is
similar to the `--decorate-refs-exclude` command-line option, but

View File

@ -1,7 +1,7 @@
lsrefs.unborn::
May be "advertise" (the default), "allow", or "ignore". If "advertise",
the server will respond to the client sending "unborn" (as described in
linkgit:gitprotocol-v2[5]) and will advertise support for this feature during the
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

View File

@ -45,15 +45,6 @@ mergetool.meld.useAutoMerge::
value of `false` avoids using `--auto-merge` altogether, and is the
default value.
mergetool.vimdiff.layout::
The vimdiff backend uses this variable to control how its split
windows look like. Applies even if you are using Neovim (`nvim`) or
gVim (`gvim`) as the merge tool. See BACKEND SPECIFIC HINTS section
ifndef::git-mergetool[]
in linkgit:git-mergetool[1].
endif::[]
for details.
mergetool.hideResolved::
During a merge Git will automatically resolve as many conflicts as
possible and write the 'MERGED' file containing conflict markers around

View File

@ -3,9 +3,6 @@ notes.mergeStrategy::
conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or
`cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES"
section of linkgit:git-notes[1] for more information on each strategy.
+
This setting can be overridden by passing the `--strategy` option to
linkgit:git-notes[1].
notes.<name>.mergeStrategy::
Which merge strategy to choose when doing a notes merge into
@ -14,35 +11,28 @@ notes.<name>.mergeStrategy::
linkgit:git-notes[1] for more information on the available strategies.
notes.displayRef::
Which ref (or refs, if a glob or specified more than once), in
addition to the default set by `core.notesRef` or
`GIT_NOTES_REF`, to read notes from when showing commit
messages with the 'git log' family of commands.
The (fully qualified) refname from which to show notes when
showing commit messages. The value of this variable can be set
to a glob, in which case notes from all matching refs will be
shown. You may also specify this configuration variable
several times. A warning will be issued for refs that do not
exist, but a glob that does not match any refs is silently
ignored.
+
This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
environment variable, which must be a colon separated list of refs or
globs.
+
A warning will be issued for refs that do not exist,
but a glob that does not match any refs is silently ignored.
+
This setting can be disabled by the `--no-notes` option to the 'git
log' family of commands, or by the `--notes=<ref>` option accepted by
those commands.
+
The effective value of "core.notesRef" (possibly overridden by
GIT_NOTES_REF) is also implicitly added to the list of refs to be
displayed.
notes.rewrite.<command>::
When rewriting commits with <command> (currently `amend` or
`rebase`), if this variable is `false`, git will not copy
notes from the original to the rewritten commit. Defaults to
`true`. See also "`notes.rewriteRef`" below.
+
This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
environment variable, which must be a colon separated list of refs or
globs.
`rebase`) and this variable is set to `true`, Git
automatically copies your notes from the original to the
rewritten commit. Defaults to `true`, but see
"notes.rewriteRef" below.
notes.rewriteMode::
When copying notes during a rewrite (see the
@ -56,13 +46,14 @@ environment variable.
notes.rewriteRef::
When copying notes during a rewrite, specifies the (fully
qualified) ref whose notes should be copied. May be a glob,
in which case notes in all matching refs will be copied. You
may also specify this configuration several times.
qualified) ref whose notes should be copied. The ref may be a
glob, in which case notes in all matching refs will be copied.
You may also specify this configuration several times.
+
Does not have a default value; you must configure this variable to
enable note rewriting. Set it to `refs/notes/commits` to enable
rewriting for the default commit notes.
+
Can be overridden with the `GIT_NOTES_REWRITE_REF` environment variable.
See `notes.rewrite.<command>` above for a further description of its format.
This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
environment variable, which must be a colon separated list of refs or
globs.

View File

@ -164,16 +164,9 @@ When writing a multi-pack reachability bitmap, no new namehashes are
computed; instead, any namehashes stored in an existing bitmap are
permuted into their appropriate location when writing a new bitmap.
pack.writeBitmapLookupTable::
When true, Git will include a "lookup table" section in the
bitmap index (if one is written). This table is used to defer
loading individual bitmaps as late as possible. This can be
beneficial in repositories that have relatively large bitmap
indexes. Defaults to false.
pack.writeReverseIndex::
When true, git will write a corresponding .rev file (see:
linkgit:gitformat-pack[5])
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.

View File

@ -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
policy of `user`. Supported policies:
default policy of `never`, and all other protocols (including file)
have a default policy of `user`. Supported policies:
+
--
@ -58,6 +58,6 @@ protocol.version::
* `1` - the original wire protocol with the addition of a version string
in the initial response from the server.
* `2` - Wire protocol version 2, see linkgit:gitprotocol-v2[5].
* `2` - link:technical/protocol-v2.html[wire protocol version 2].
--

View File

@ -1,14 +1,3 @@
push.autoSetupRemote::
If set to "true" assume `--set-upstream` on default push when no
upstream tracking exists for the current branch; this option
takes effect with push.default options 'simple', 'upstream',
and 'current'. It is useful if by default you want new branches
to be pushed to the default remote (like the behavior of
'push.default=current') and you also want the upstream tracking
to be set. Workflows most likely to benefit from this option are
'simple' central workflows where all branches are expected to
have the same name on the remote.
push.default::
Defines the action `git push` should take if no refspec is
given (whether from the command-line, config, or elsewhere).
@ -137,8 +126,3 @@ push.negotiate::
server attempt to find commits in common. If "false", Git will
rely solely on the server's ref advertisement to find commits
in common.
push.useBitmaps::
If set to "false", disable use of bitmaps for "git push" even if
`pack.useBitmaps` is "true", without preventing other git operations
from using bitmaps. Default is true.

View File

@ -21,9 +21,6 @@ rebase.autoStash::
`--autostash` options of linkgit:git-rebase[1].
Defaults to false.
rebase.updateRefs::
If set to true enable `--update-refs` option by default.
rebase.missingCommitsCheck::
If set to "warn", git rebase -i will print a warning if some
commits are removed (e.g. a line was deleted), however the

View File

@ -82,7 +82,5 @@ remote.<name>.promisor::
objects.
remote.<name>.partialclonefilter::
The filter that will be applied when fetching from this promisor remote.
Changing or clearing this value will only affect fetches for new commits.
To fetch associated objects for commits already present in the local object
database, use the `--refetch` option of linkgit:git-fetch[1].
The filter that will be applied when fetching from this
promisor remote.

View File

@ -25,17 +25,3 @@ repack.writeBitmaps::
space and extra time spent on the initial repack. This has
no effect if multiple packfiles are created.
Defaults to true on bare repos, false otherwise.
repack.updateServerInfo::
If set to false, linkgit:git-repack[1] will not run
linkgit:git-update-server-info[1]. Defaults to true. Can be overridden
when true by the `-n` option of linkgit:git-repack[1].
repack.cruftWindow::
repack.cruftWindowMemory::
repack.cruftDepth::
repack.cruftThreads::
Parameters used by linkgit:git-pack-objects[1] when generating
a cruft pack and the respective parameters are not given over
the command line. See similarly named `pack.*` configuration
variables for defaults and meaning.

View File

@ -0,0 +1,2 @@
reset.quiet::
When set to true, 'git reset' will default to the '--quiet' option.

View File

@ -1,3 +0,0 @@
revert.reference::
Setting this variable to true makes `git revert` behave
as if the `--reference` option is given.

View File

@ -1,22 +1,3 @@
safe.bareRepository::
Specifies which bare repositories Git will work with. The currently
supported values are:
+
* `all`: Git works with all bare repositories. This is the default.
* `explicit`: Git only works with bare repositories specified via
the top-level `--git-dir` command-line option, or the `GIT_DIR`
environment variable (see linkgit:git[1]).
+
If you do not use bare repositories in your workflow, then it may be
beneficial to set `safe.bareRepository` to `explicit` in your global
config. This will protect you from attacks that involve cloning a
repository that contains a bare repository and running a Git command
within that directory.
+
This config setting is only respected in protected configuration (see
<<SCOPES>>). This prevents the untrusted repository from tampering with
this value.
safe.directory::
These config entries specify Git-tracked directories that are
considered safe even if they are owned by someone other than the
@ -31,9 +12,9 @@ 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 in protected configuration (see
<<SCOPES>>). This prevents the untrusted repository from tampering with this
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

View File

@ -18,49 +18,17 @@ sendemail.<identity>.*::
identity is selected, through either the command-line or
`sendemail.identity`.
sendemail.multiEdit::
If true (default), a single editor instance will be spawned to edit
files you have to edit (patches when `--annotate` is used, and the
summary when `--compose` is used). If false, files will be edited one
after the other, spawning a new editor each time.
sendemail.confirm::
Sets the default for whether to confirm before sending. Must be
one of 'always', 'never', 'cc', 'compose', or 'auto'. See `--confirm`
in the linkgit:git-send-email[1] documentation for the meaning of these
values.
sendemail.aliasesFile::
To avoid typing long email addresses, point this to one or more
email aliases files. You must also supply `sendemail.aliasFileType`.
sendemail.aliasFileType::
Format of the file(s) specified in sendemail.aliasesFile. Must be
one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus', or 'sendmail'.
+
What an alias file in each format looks like can be found in
the documentation of the email program of the same name. The
differences and limitations from the standard formats are
described below:
+
--
sendmail;;
* Quoted aliases and quoted addresses are not supported: lines that
contain a `"` symbol are ignored.
* Redirection to a file (`/path/name`) or pipe (`|command`) is not
supported.
* File inclusion (`:include: /path/name`) is not supported.
* Warnings are printed on the standard error output for any
explicitly unsupported constructs, and any other lines that are not
recognized by the parser.
--
sendemail.annotate::
sendemail.bcc::
sendemail.cc::
sendemail.ccCmd::
sendemail.chainReplyTo::
sendemail.confirm::
sendemail.envelopeSender::
sendemail.from::
sendemail.multiEdit::
sendemail.signedoffbycc::
sendemail.smtpPass::
sendemail.suppresscc::
@ -76,9 +44,7 @@ sendemail.thread::
sendemail.transferEncoding::
sendemail.validate::
sendemail.xmailer::
These configuration variables all provide a default for
linkgit:git-send-email[1] command-line options. See its
documentation for details.
See linkgit:git-send-email[1] for description.
sendemail.signedoffcc (deprecated)::
Deprecated alias for `sendemail.signedoffbycc`.

View File

@ -1,27 +0,0 @@
sparse.expectFilesOutsideOfPatterns::
Typically with sparse checkouts, files not matching any
sparsity patterns are marked with a SKIP_WORKTREE bit in the
index and are missing from the working tree. Accordingly, Git
will ordinarily check whether files with the SKIP_WORKTREE bit
are in fact present in the working tree contrary to
expectations. If Git finds any, it marks those paths as
present by clearing the relevant SKIP_WORKTREE bits. This
option can be used to tell Git that such
present-despite-skipped files are expected and to stop
checking for them.
+
The default is `false`, which allows Git to automatically recover
from the list of files in the index and working tree falling out of
sync.
+
Set this to `true` if you are in a setup where some external factor
relieves Git of the responsibility for maintaining the consistency
between the presence of working tree files and sparsity patterns. For
example, if you have a Git-aware virtual file system that has a robust
mechanism for keeping the working tree and the sparsity patterns up to
date based on access patterns.
+
Regardless of this setting, Git does not check for
present-despite-skipped files unless sparse checkout is enabled, so
this config option has no effect unless `core.sparseCheckout` is
`true`.

View File

@ -1,3 +1,10 @@
stash.useBuiltin::
Unused configuration variable. Used in Git versions 2.22 to
2.26 as an escape hatch to enable the legacy shellscript
implementation of stash. 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.
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

View File

@ -59,33 +59,18 @@ submodule.active::
submodule.recurse::
A boolean indicating if commands should enable the `--recurse-submodules`
option by default. Defaults to false.
+
When set to true, it can be deactivated via the
`--no-recurse-submodules` option. Note that some Git commands
lacking this option may call some of the above commands affected by
`submodule.recurse`; for instance `git remote update` will call
`git fetch` but does not have a `--no-recurse-submodules` option.
For these commands a workaround is to temporarily change the
configuration value by using `git -c submodule.recurse=0`.
+
The following list shows the commands that accept
`--recurse-submodules` and whether they are supported by this
setting.
* `checkout`, `fetch`, `grep`, `pull`, `push`, `read-tree`,
`reset`, `restore` and `switch` are always supported.
* `clone` and `ls-files` are not supported.
* `branch` is supported only if `submodule.propagateBranches` is
enabled
submodule.propagateBranches::
[EXPERIMENTAL] A boolean that enables branching support when
using `--recurse-submodules` or `submodule.recurse=true`.
Enabling this will allow certain commands to accept
`--recurse-submodules` and certain commands that already accept
`--recurse-submodules` will now consider branches.
option by default.
Applies to all commands that support this option
(`checkout`, `fetch`, `grep`, `pull`, `push`, `read-tree`, `reset`,
`restore` and `switch`) except `clone` and `ls-files`.
Defaults to false.
When set to true, it can be deactivated via the
`--no-recurse-submodules` option. Note that some Git commands
lacking this option may call some of the above commands affected by
`submodule.recurse`; for instance `git remote update` will call
`git fetch` but does not have a `--no-recurse-submodules` option.
For these commands a workaround is to temporarily change the
configuration value by using `git -c submodule.recurse=0`.
submodule.fetchJobs::
Specifies how many submodules are fetched/cloned at the same time.

View File

@ -1,41 +1,3 @@
transfer.credentialsInUrl::
A configured URL can contain plaintext credentials in the form
`<protocol>://<user>:<password>@<domain>/<path>`. You may want
to warn or forbid the use of such configuration (in favor of
using linkgit:git-credential[1]). This will be used on
linkgit:git-clone[1], linkgit:git-fetch[1], linkgit:git-push[1],
and any other direct use of the configured URL.
+
Note that this is currently limited to detecting credentials in
`remote.<name>.url` configuration, it won't detect credentials in
`remote.<name>.pushurl` configuration.
+
You might want to enable this to prevent inadvertent credentials
exposure, e.g. because:
+
* The OS or system where you're running git may not provide a way or
otherwise allow you to configure the permissions of the
configuration file where the username and/or password are stored.
* Even if it does, having such data stored "at rest" might expose you
in other ways, e.g. a backup process might copy the data to another
system.
* The git programs will pass the full URL to one another as arguments
on the command-line, meaning the credentials will be exposed to other
users on OS's or systems that allow other users to see the full
process list of other users. On linux the "hidepid" setting
documented in procfs(5) allows for configuring this behavior.
+
If such concerns don't apply to you then you probably don't need to be
concerned about credentials exposure due to storing that sensitive
data in git's configuration files. If you do want to use this, set
`transfer.credentialsInUrl` to one of these values:
+
* `allow` (default): Git will proceed with its activity without warning.
* `warn`: Git will write a warning message to `stderr` when parsing a URL
with a plaintext credential.
* `die`: Git will write a failure message to `stderr` when parsing a URL
with a plaintext credential.
transfer.fsckObjects::
When `fetch.fsckObjects` or `receive.fsckObjects` are
not set, the value of this variable is used instead.

View File

@ -49,9 +49,9 @@ uploadpack.packObjectsHook::
`pack-objects` to the hook, and expects a completed packfile on
stdout.
+
Note that this configuration variable is only respected when it is specified
in protected configuration (see <<SCOPES>>). This is a safety measure
against fetching from untrusted repositories.
Note that this configuration variable is ignored if it is seen in the
repository-level config (this is a safety measure against fetching from
untrusted repositories).
uploadpack.allowFilter::
If this option is set, `upload-pack` will support partial

View File

@ -43,7 +43,7 @@ That is, from the left to the right:
. a space.
. sha1 for "src"; 0\{40\} if creation or unmerged.
. a space.
. sha1 for "dst"; 0\{40\} if deletion, unmerged or "work tree out of sync with the index".
. sha1 for "dst"; 0\{40\} if creation, unmerged or "look at work tree".
. a space.
. status, followed by optional "score" number.
. a tab or a NUL when `-z` option is used.
@ -69,8 +69,8 @@ percentage of similarity between the source and target of the move or
copy). Status letter M may be followed by a score (denoting the
percentage of dissimilarity) for file rewrites.
The sha1 for "dst" is shown as all 0's if a file on the filesystem
is out of sync with the index.
<sha1> is shown as all 0's if a file is new on the filesystem
and it is out of sync with the index.
Example:

View File

@ -34,7 +34,7 @@ endif::git-diff[]
endif::git-format-patch[]
ifdef::git-log[]
--diff-merges=(off|none|on|first-parent|1|separate|m|combined|c|dense-combined|cc|remerge|r)::
--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
@ -64,18 +64,6 @@ ifdef::git-log[]
each of the parents. Separate log entry and diff is generated
for each parent.
+
--diff-merges=remerge:::
--diff-merges=r:::
--remerge-diff:::
With this option, two-parent merge commits are remerged to
create a temporary tree object -- potentially containing files
with conflict markers and such. A diff is then shown between
that temporary tree and the actual merge commit.
+
The output emitted when this option is used is subject to change, and
so is its interaction with other options (unless explicitly
documented).
+
--diff-merges=combined:::
--diff-merges=c:::
-c:::
@ -628,8 +616,11 @@ ifndef::git-format-patch[]
Also, these upper-case letters can be downcased to exclude. E.g.
`--diff-filter=ad` excludes added and deleted paths.
+
Note that not all diffs can feature all types. For instance, copied and
renamed entries cannot appear if detection for those types is disabled.
Note that not all diffs can feature all types. For instance, diffs
from the index to the working tree can never have Added entries
(because the set of paths included in the diff is limited by what is in
the index). Similarly, copied and renamed entries cannot appear if
detection for those types is disabled.
-S<string>::
Look for differences that change the number of occurrences of

View File

@ -71,7 +71,6 @@ configuration variables documented in linkgit:git-config[1], and the
ancestors of the provided `--negotiation-tip=*` arguments,
which we have in common with the server.
+
This is incompatible with `--recurse-submodules=[yes|on-demand]`.
Internally this is used to implement the `push.negotiate` option, see
linkgit:git-config[1].
@ -163,16 +162,6 @@ endif::git-pull[]
behavior for a remote may be specified with the remote.<name>.tagOpt
setting. See linkgit:git-config[1].
ifndef::git-pull[]
--refetch::
Instead of negotiating with the server to avoid transferring commits and
associated objects that are already present locally, this option fetches
all objects as a fresh clone would. Use this to reapply a partial clone
filter from configuration or using `--filter=` when the filter
definition has changed. Automatic post-fetch maintenance will perform
object database pack consolidation to remove any duplicate objects.
endif::git-pull[]
--refmap=<refspec>::
When fetching refs listed on the command line, use the
specified refspec (can be given more than once) to map the
@ -196,23 +185,15 @@ endif::git-pull[]
ifndef::git-pull[]
--recurse-submodules[=yes|on-demand|no]::
This option controls if and under what conditions new commits of
submodules should be fetched too. When recursing through submodules,
`git fetch` always attempts to fetch "changed" submodules, that is, a
submodule that has commits that are referenced by a newly fetched
superproject commit but are missing in the local submodule clone. A
changed submodule can be fetched as long as it is present locally e.g.
in `$GIT_DIR/modules/` (see linkgit:gitsubmodules[7]); if the upstream
adds a new submodule, that submodule cannot be fetched until it is
cloned e.g. by `git submodule update`.
+
When set to 'on-demand', only changed submodules are fetched. When set
to 'yes', all populated submodules are fetched and submodules that are
both unpopulated and changed are fetched. When set to 'no', submodules
are never fetched.
+
When unspecified, this uses the value of `fetch.recurseSubmodules` if it
is set (see linkgit:git-config[1]), defaulting to 'on-demand' if unset.
When this option is used without any value, it defaults to 'yes'.
populated submodules should be fetched too. It can be used as a
boolean option to completely disable recursion when set to 'no' or to
unconditionally recurse into all populated submodules when set to
'yes', which is the default when this option is used without any
value. Use 'on-demand' to only recurse into a populated submodule
when the superproject retrieves a commit that updates the submodule's
reference to a commit that isn't already in the local submodule
clone. By default, 'on-demand' is used, unless
`fetch.recurseSubmodules` is set (see linkgit:git-config[1]).
endif::git-pull[]
-j::

View File

@ -188,9 +188,7 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files.
forcibly add them again to the index. This is useful after
changing `core.autocrlf` configuration or the `text` attribute
in order to correct files added with wrong CRLF/LF line endings.
This option implies `-u`. Lone CR characters are untouched, thus
while a CRLF cleans to LF, a CRCRLF sequence is only partially
cleaned to CRLF.
This option implies `-u`.
--chmod=(+|-)x::
Override the executable bit of the added files. The executable
@ -433,13 +431,6 @@ they will make the patch impossible to apply:
* deleting context or removal lines
* modifying the contents of context or removal lines
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/add.txt[]
SEE ALSO
--------
linkgit:git-status[1]

View File

@ -112,7 +112,10 @@ default. You can use `--no-utf8` to override this.
am.threeWay configuration variable. For more information,
see am.threeWay in linkgit:git-config[1].
include::rerere-options.txt[]
--rerere-autoupdate::
--no-rerere-autoupdate::
Allow the rerere mechanism to update the index with the
result of auto-conflict resolution if possible.
--ignore-space-change::
--ignore-whitespace::
@ -258,13 +261,6 @@ This command can run `applypatch-msg`, `pre-applypatch`,
and `post-applypatch` hooks. See linkgit:githooks[5] for more
information.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/am.txt[]
SEE ALSO
--------
linkgit:git-apply[1].

View File

@ -263,9 +263,13 @@ has no effect when `--index` or `--cached` is in use.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/apply.txt[]
apply.ignoreWhitespace::
Set to 'change' if you want changes in whitespace to be ignored by default.
Set to one of: no, none, never, false if you want changes in
whitespace to be significant.
apply.whitespace::
When no `--whitespace` flag is given from the command
line, this configuration item is used as the default.
SUBMODULES
----------

View File

@ -34,12 +34,10 @@ OPTIONS
-------
--format=<fmt>::
Format of the resulting archive. Possible values are `tar`,
`zip`, `tar.gz`, `tgz`, and any format defined using the
configuration option `tar.<format>.command`. If `--format`
Format of the resulting archive: 'tar' or 'zip'. If this option
is not given, and the output file is specified, the format is
inferred from the filename if possible (e.g. writing to `foo.zip`
makes the output to be in the `zip` format). Otherwise the output
inferred from the filename if possible (e.g. writing to "foo.zip"
makes the output to be in the zip format). Otherwise the output
format is `tar`.
-l::
@ -51,9 +49,7 @@ OPTIONS
Report progress to stderr.
--prefix=<prefix>/::
Prepend <prefix>/ to paths in the archive. Can be repeated; its
rightmost value is used for all tracked files. See below which
value gets used by `--add-file` and `--add-virtual-file`.
Prepend <prefix>/ to each filename in the archive.
-o <file>::
--output=<file>::
@ -61,26 +57,9 @@ OPTIONS
--add-file=<file>::
Add a non-tracked file to the archive. Can be repeated to add
multiple files. The path of the file in the archive is built by
concatenating the value of the last `--prefix` option (if any)
before this `--add-file` and the basename of <file>.
--add-virtual-file=<path>:<content>::
Add the specified contents to the archive. Can be repeated to add
multiple files. The path of the file in the archive is built
by concatenating the value of the last `--prefix` option (if any)
before this `--add-virtual-file` and `<path>`.
+
The `<path>` argument can start and end with a literal double-quote
character; the contained file name is interpreted as a C-style string,
i.e. the backslash is interpreted as escape character. The path must
be quoted if it contains a colon, to avoid the colon from being
misinterpreted as the separator between the path and the contents, or
if the path begins or ends with a double-quote character.
+
The file mode is limited to a regular file, and the option may be
subject to platform-dependent command-line limits. For non-trivial
cases, write an untracked file and use `--add-file` instead.
by concatenating the value for `--prefix` (if any) and the
basename of <file>.
--worktree-attributes::
Look for attributes in .gitattributes files in the working tree
@ -145,16 +124,17 @@ tar.<format>.command::
is executed using the shell with the generated tar file on its
standard input, and should produce the final output on its
standard output. Any compression-level options will be passed
to the command (e.g., `-9`).
to the command (e.g., "-9"). An output file with the same
extension as `<format>` will be use this format if no other
format is given.
+
The `tar.gz` and `tgz` formats are defined automatically and use the
magic command `git archive gzip` by default, which invokes an internal
implementation of gzip.
The "tar.gz" and "tgz" formats are defined automatically and default to
`gzip -cn`. You may override them with custom commands.
tar.<format>.remote::
If true, enable the format for use by remote clients via
If true, enable `<format>` for use by remote clients via
linkgit:git-upload-archive[1]. Defaults to false for
user-defined formats, but true for the `tar.gz` and `tgz`
user-defined formats, but true for the "tar.gz" and "tgz"
formats.
[[ATTRIBUTES]]
@ -214,12 +194,6 @@ EXAMPLES
commit on the current branch. Note that the output format is
inferred by the extension of the output file.
`git archive -o latest.tar --prefix=build/ --add-file=configure --prefix= HEAD`::
Creates a tar archive that contains the contents of the latest
commit on the current branch with no prefix and the untracked
file 'configure' with the prefix 'build/'.
`git config tar.tar.xz.command "xz -c"`::
Configure a "tar.xz" format for making LZMA-compressed tarfiles.

View File

@ -241,12 +241,6 @@ MAPPING AUTHORS
See linkgit:gitmailmap[5].
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/blame.txt[]
SEE ALSO
--------

View File

@ -16,8 +16,7 @@ SYNOPSIS
[--points-at <object>] [--format=<format>]
[(-r | --remotes) | (-a | --all)]
[--list] [<pattern>...]
'git branch' [--track[=(direct|inherit)] | --no-track] [-f]
[--recurse-submodules] <branchname> [<start-point>]
'git branch' [--track[=(direct|inherit)] | --no-track] [-f] <branchname> [<start-point>]
'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
'git branch' --unset-upstream [<branchname>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
@ -221,17 +220,13 @@ The exact upstream branch is chosen depending on the optional argument:
itself as the upstream; `--track=inherit` means to copy the upstream
configuration of the start-point branch.
+
The branch.autoSetupMerge configuration variable specifies how `git switch`,
`git checkout` and `git branch` should behave when neither `--track` nor
`--no-track` are specified:
+
The default option, `true`, behaves as though `--track=direct`
were given whenever the start-point is a remote-tracking branch.
`false` behaves as if `--no-track` were given. `always` behaves as though
`--track=direct` were given. `inherit` behaves as though `--track=inherit`
were given. `simple` behaves as though `--track=direct` were given only when
the start-point is a remote-tracking branch and the new branch has the same
name as the remote branch.
`--track=direct` is the default when the start point is a remote-tracking branch.
Set the branch.autoSetupMerge configuration variable to `false` if you
want `git switch`, `git checkout` and `git branch` to always behave as if `--no-track`
were given. Set it to `always` if you want this behavior when the
start-point is either a local or remote-tracking branch. Set it to
`inherit` if you want to copy the tracking configuration from the
branch point.
+
See linkgit:git-pull[1] and linkgit:git-config[1] for additional discussion on
how the `branch.<name>.remote` and `branch.<name>.merge` options are used.
@ -240,22 +235,6 @@ how the `branch.<name>.remote` and `branch.<name>.merge` options are used.
Do not set up "upstream" configuration, even if the
branch.autoSetupMerge configuration variable is set.
--recurse-submodules::
THIS OPTION IS EXPERIMENTAL! Causes the current command to
recurse into submodules if `submodule.propagateBranches` is
enabled. See `submodule.propagateBranches` in
linkgit:git-config[1]. Currently, only branch creation is
supported.
+
When used in branch creation, a new branch <branchname> will be created
in the superproject and all of the submodules in the superproject's
<start-point>. In submodules, the branch will point to the submodule
commit in the superproject's <start-point> but the branch's tracking
information will be set up based on the submodule's branches and remotes
e.g. `git branch --recurse-submodules topic origin/main` will create the
submodule branch "topic" that points to the submodule commit in the
superproject's "origin/main", but tracks the submodule's "origin/main".
--set-upstream::
As this option had confusing syntax, it is no longer supported.
Please use `--track` or `--set-upstream-to` instead.
@ -336,10 +315,6 @@ CONFIGURATION
`--list` is used or implied. The default is to use a pager.
See linkgit:git-config[1].
include::includes/cmd-config-section-rest.txt[]
include::config/branch.txt[]
EXAMPLES
--------

View File

@ -9,7 +9,6 @@ SYNOPSIS
--------
[verse]
'git bugreport' [(-o | --output-directory) <path>] [(-s | --suffix) <format>]
[--diagnose[=<mode>]]
DESCRIPTION
-----------
@ -32,10 +31,6 @@ The following information is captured automatically:
- A list of enabled hooks
- $SHELL
Additional information may be gathered into a separate zip archive using the
`--diagnose` option, and can be attached alongside the bugreport document to
provide additional context to readers.
This tool is invoked via the typical Git setup process, which means that in some
cases, it might not be able to launch - for example, if a relevant config file
is unreadable. In this kind of scenario, it may be helpful to manually gather
@ -54,19 +49,6 @@ OPTIONS
named 'git-bugreport-<formatted suffix>'. This should take the form of a
strftime(3) format string; the current local time will be used.
--no-diagnose::
--diagnose[=<mode>]::
Create a zip archive of supplemental information about the user's
machine, Git client, and repository state. The archive is written to the
same output directory as the bug report and is named
'git-diagnostics-<formatted suffix>'.
+
Without `mode` specified, the diagnostic archive will contain the default set of
statistics reported by `git diagnose`. An optional `mode` value may be specified
to change which information is included in the archive. See
linkgit:git-diagnose[1] for the list of valid values for `mode` and details
about their usage.
GIT
---
Part of the linkgit:git[1] suite

View File

@ -42,7 +42,7 @@ BUNDLE FORMAT
Bundles are `.pack` files (see linkgit:git-pack-objects[1]) with a
header indicating what references are contained within the bundle.
Like the packed archive format itself bundles can either be
Like the the packed archive format itself bundles can either be
self-contained, or be created using exclusions.
See the "OBJECT PREREQUISITES" section below.
@ -56,8 +56,10 @@ using "thin packs", bundles created using exclusions are smaller in
size. That they're "thin" under the hood is merely noted here as a
curiosity, and as a reference to other documentation.
See linkgit:gitformat-bundle[5] for more details and the discussion of
"thin pack" in linkgit:gitformat-pack[5] for further details.
See link:technical/bundle-format.html[the `bundle-format`
documentation] for more details and the discussion of "thin pack" in
link:technical/pack-format.html[the pack format documentation] for
further details.
OPTIONS
-------
@ -73,11 +75,8 @@ verify <file>::
cleanly to the current repository. This includes checks on the
bundle format itself as well as checking that the prerequisite
commits exist and are fully linked in the current repository.
Then, 'git bundle' prints a list of missing commits, if any.
Finally, information about additional capabilities, such as "object
filter", is printed. See "Capabilities" in linkgit:gitformat-bundle[5]
for more information. The exit code is zero for success, but will
be nonzero if the bundle file is invalid.
'git bundle' prints a list of missing commits, if any, and exits
with a non-zero status.
list-heads <file>::
Lists the references defined in the bundle. If followed by a
@ -335,11 +334,6 @@ You can also see what references it offers:
$ git ls-remote mybundle
----------------
FILE FORMAT
-----------
See linkgit:gitformat-bundle[5].
GIT
---
Part of the linkgit:git[1] suite

View File

@ -9,14 +9,8 @@ git-cat-file - Provide content or type and size information for repository objec
SYNOPSIS
--------
[verse]
'git cat-file' <type> <object>
'git cat-file' (-e | -p) <object>
'git cat-file' (-t | -s) [--allow-unknown-type] <object>
'git cat-file' (--batch | --batch-check | --batch-command) [--batch-all-objects]
[--buffer] [--follow-symlinks] [--unordered]
[--textconv | --filters] [-z]
'git cat-file' (--textconv | --filters)
[<rev>:<path|tree-ish> | --path=<path|tree-ish> <rev>]
'git cat-file' (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e | -p | <type> | --textconv | --filters ) [--path=<path>] <object>
'git cat-file' (--batch[=<format>] | --batch-check[=<format>]) [ --textconv | --filters ] [--follow-symlinks]
DESCRIPTION
-----------
@ -63,12 +57,6 @@ OPTIONS
or to ask for a "blob" with `<object>` being a tag object that
points at it.
--[no-]mailmap::
--[no-]use-mailmap::
Use mailmap file to map author, committer and tagger names
and email addresses to canonical real names and email addresses.
See linkgit:git-shortlog[1].
--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
@ -102,33 +90,6 @@ OPTIONS
need to specify the path, separated by whitespace. See the
section `BATCH OUTPUT` below for details.
--batch-command::
--batch-command=<format>::
Enter a command mode that reads commands and arguments from stdin. May
only be combined with `--buffer`, `--textconv` or `--filters`. In the
case of `--textconv` or `--filters`, the input lines also need to specify
the path, separated by whitespace. See the section `BATCH OUTPUT` below
for details.
+
`--batch-command` recognizes the following commands:
+
--
contents <object>::
Print object contents for object reference `<object>`. This corresponds to
the output of `--batch`.
info <object>::
Print object info for object reference `<object>`. This corresponds to the
output of `--batch-check`.
flush::
Used with `--buffer` to execute all preceding commands that were issued
since the beginning or since the last flush was issued. When `--buffer`
is used, no output will come until a `flush` is issued. When `--buffer`
is not used, commands are flushed each time without issuing `flush`.
--
+
--batch-all-objects::
Instead of reading a list of objects on stdin, perform the
requested batch operation on all objects in the repository and
@ -143,7 +104,7 @@ flush::
that a process can interactively read and write from
`cat-file`. With this option, the output uses normal stdio
buffering; this is much more efficient when invoking
`--batch-check` or `--batch-command` on a large number of objects.
`--batch-check` on a large number of objects.
--unordered::
When `--batch-all-objects` is in use, visit objects in an
@ -213,11 +174,6 @@ respectively print:
/etc/passwd
--
-z::
Only meaningful with `--batch`, `--batch-check`, or
`--batch-command`; input is NUL-delimited instead of
newline-delimited.
OUTPUT
------
@ -240,13 +196,6 @@ from stdin, one per line, and print information about them. By default,
the whole line is considered as an object, as if it were fed to
linkgit:git-rev-parse[1].
When `--batch-command` is given, `cat-file` will read commands from stdin,
one per line, and print information based on the command given. With
`--batch-command`, the `info` command followed by an object will print
information about the object the same way `--batch-check` would, and the
`contents` command followed by an object prints contents in the same way
`--batch` would.
You can specify the information shown for each object by using a custom
`<format>`. The `<format>` is copied literally to stdout for each
object, with placeholders of the form `%(atom)` expanded, followed by a
@ -282,9 +231,9 @@ newline. The available atoms are:
If no format is specified, the default format is `%(objectname)
%(objecttype) %(objectsize)`.
If `--batch` is specified, or if `--batch-command` is used with the `contents`
command, the object information is followed by the object contents (consisting
of `%(objectsize)` bytes), followed by a newline.
If `--batch` is specified, the object information is followed by the
object contents (consisting of `%(objectsize)` bytes), followed by a
newline.
For example, `--batch` without a custom format would produce:

View File

@ -33,7 +33,7 @@ OPTIONS
Instead of printing the paths that are excluded, for each path
that matches an exclude pattern, print the exclude pattern
together with the path. (Matching an exclude pattern usually
means the path is excluded, but if the pattern begins with "`!`"
means the path is excluded, but if the pattern begins with '!'
then it is a negated pattern and matching it means the path is
NOT excluded.)
+
@ -77,7 +77,7 @@ If `--verbose` is specified, the output is a series of lines of the form:
<pathname> is the path of a file being queried, <pattern> is the
matching pattern, <source> is the pattern's source file, and <linenum>
is the line number of the pattern within that source. If the pattern
contained a "`!`" prefix or "`/`" suffix, it will be preserved in the
contained a `!` prefix or `/` suffix, it will be preserved in the
output. <source> will be an absolute path when referring to the file
configured by `core.excludesFile`, or relative to the repository root
when referring to `.git/info/exclude` or a per-directory exclude file.

View File

@ -12,7 +12,6 @@ SYNOPSIS
'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
[--stage=<number>|all]
[--temp]
[--ignore-skip-worktree-bits]
[-z] [--stdin]
[--] [<file>...]
@ -38,9 +37,8 @@ OPTIONS
-a::
--all::
checks out all files in the index except for those with the
skip-worktree bit set (see `--ignore-skip-worktree-bits`).
Cannot be used together with explicit filenames.
checks out all files in the index. Cannot be used
together with explicit filenames.
-n::
--no-create::
@ -61,10 +59,6 @@ OPTIONS
write the content to temporary files. The temporary name
associations will be written to stdout.
--ignore-skip-worktree-bits::
Check out all files, including those with the skip-worktree bit
set.
--stdin::
Instead of taking list of paths from the command line,
read list of paths from the standard input. Paths are

View File

@ -600,13 +600,6 @@ $ edit frotz
$ git add frotz
------------
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/checkout.txt[]
SEE ALSO
--------
linkgit:git-switch[1],

View File

@ -156,7 +156,10 @@ effect to your index in a row.
Pass the merge strategy-specific option through to the
merge strategy. See linkgit:git-merge[1] for details.
include::rerere-options.txt[]
--rerere-autoupdate::
--no-rerere-autoupdate::
Allow the rerere mechanism to update the index with the
result of auto-conflict resolution if possible.
SEQUENCER SUBCOMMANDS
---------------------

View File

@ -133,13 +133,6 @@ help::
Show brief usage of interactive git-clean.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/clean.txt[]
SEE ALSO
--------
linkgit:gitignore[5]

View File

@ -16,7 +16,7 @@ SYNOPSIS
[--depth <depth>] [--[no-]single-branch] [--no-tags]
[--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
[--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow]
[--filter=<filter> [--also-filter-submodules]] [--] <repository>
[--filter=<filter>] [--] <repository>
[<directory>]
DESCRIPTION
@ -182,11 +182,6 @@ objects from the source repository into a pack in the cloned repository.
at least `<size>`. For more details on filter specifications, see
the `--filter` option in linkgit:git-rev-list[1].
--also-filter-submodules::
Also apply the partial clone filter to any submodules in the repository.
Requires `--filter` and `--recurse-submodules`. This can be turned on by
default by setting the `clone.filterSubmodules` config option.
--mirror::
Set up a mirror of the source repository. This implies `--bare`.
Compared to `--bare`, `--mirror` not only maps local branches of the
@ -323,13 +318,6 @@ or `--mirror` is given)
for `host.xz:foo/.git`). Cloning into an existing directory
is only allowed if the directory is empty.
--bundle-uri=<uri>::
Before fetching from the remote, fetch a bundle from the given
`<uri>` and unbundle the data into the local repository. The refs
in the bundle will be stored under the hidden `refs/bundle/*`
namespace. This option is incompatible with `--depth`,
`--shallow-since`, and `--shallow-exclude`.
:git-clone: 1
include::urls.txt[]
@ -370,15 +358,6 @@ $ cd my-linux
$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
------------
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/init.txt[]
include::config/clone.txt[]
GIT
---

View File

@ -74,13 +74,6 @@ v2.4.3 v2.4.4 v2.4.5 v2.4.6 v2.4.7
v2.4.8 v2.4.9
------------
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/column.txt[]
GIT
---
Part of the linkgit:git[1] suite

View File

@ -142,18 +142,6 @@ $ git show-ref -s | git commit-graph write --stdin-commits
$ git rev-parse HEAD | git commit-graph write --stdin-commits --append
------------------------------------------------
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/commitgraph.txt[]
FILE FORMAT
-----------
see linkgit:gitformat-commit-graph[5].
GIT
---

View File

@ -557,10 +557,6 @@ The editor used to edit the commit log message will be chosen from the
`VISUAL` environment variable, or the `EDITOR` environment variable (in that
order). See linkgit:git-var[1] for details.
include::includes/cmd-config-section-rest.txt[]
include::config/commit.txt[]
HOOKS
-----
This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,

View File

@ -141,13 +141,9 @@ from all available files.
See also <<FILES>>.
--worktree::
Similar to `--local` except that `$GIT_DIR/config.worktree` is
Similar to `--local` except that `.git/config.worktree` is
read from or written to if `extensions.worktreeConfig` is
enabled. If not it's the same as `--local`. Note that `$GIT_DIR`
is equal to `$GIT_COMMON_DIR` for the main working tree, but is of
the form `$GIT_DIR/worktrees/<id>/` for other working trees. See
linkgit:git-worktree[1] to learn how to enable
`extensions.worktreeConfig`.
present. If not it's the same as `--local`.
-f <config-file>::
--file <config-file>::
@ -248,7 +244,7 @@ Valid `<type>`'s include:
--show-scope::
Similar to `--show-origin` in that it augments the output of
all queried config options with the scope of that value
(worktree, local, global, system, command).
(local, global, system, command).
--get-colorbool <name> [<stdout-is-tty>]::
@ -297,20 +293,23 @@ The default is to use a pager.
FILES
-----
By default, 'git config' will read configuration options from multiple
files:
If not set explicitly with `--file`, there are four files where
'git config' will search for configuration options:
$(prefix)/etc/gitconfig::
System-wide configuration file.
$XDG_CONFIG_HOME/git/config::
Second user-specific configuration file. If $XDG_CONFIG_HOME is not set
or empty, `$HOME/.config/git/config` will be used. Any single-valued
variable set in this file will be overwritten by whatever is in
`~/.gitconfig`. It is a good idea not to create this file if
you sometimes use older versions of Git, as support for this
file was added fairly recently.
~/.gitconfig::
User-specific configuration files. When the XDG_CONFIG_HOME environment
variable is not set or empty, $HOME/.config/ is used as
$XDG_CONFIG_HOME.
+
These are also called "global" configuration files. If both files exist, both
files are read in the order given above.
User-specific configuration file. Also called "global"
configuration file.
$GIT_DIR/config::
Repository specific configuration file.
@ -319,80 +318,28 @@ $GIT_DIR/config.worktree::
This is optional and is only searched when
`extensions.worktreeConfig` is present in $GIT_DIR/config.
You may also provide additional configuration parameters when running any
git command by using the `-c` option. See linkgit:git[1] for details.
Options will be read from all of these files that are available. If the
global or the system-wide configuration files are missing or unreadable they
will be ignored. If the repository configuration file is missing or unreadable,
'git config' will exit with a non-zero error code. An error message is produced
if the file is unreadable, but not if it is missing.
If no further options are given, all reading options will read all of these
files that are available. If the global or the system-wide configuration
file are not available they will be ignored. If the repository configuration
file is not available or readable, 'git config' will exit with a non-zero
error code. However, in neither case will an error message be issued.
The files are read in the order given above, with last value found taking
precedence over values read earlier. When multiple values are taken then all
values of a key from all files will be used.
By default, options are only written to the repository specific
You may override individual configuration parameters when running any git
command by using the `-c` option. See linkgit:git[1] for details.
All writing options will per default write to the repository specific
configuration file. Note that this also affects options like `--replace-all`
and `--unset`. *'git config' will only ever change one file at a time*.
You can limit which configuration sources are read from or written to by
specifying the path of a file with the `--file` option, or by specifying a
configuration scope with `--system`, `--global`, `--local`, or `--worktree`.
For more, see <<OPTIONS>> above.
You can override these rules using the `--global`, `--system`,
`--local`, `--worktree`, and `--file` command-line options; see
<<OPTIONS>> above.
[[SCOPES]]
SCOPES
------
Each configuration source falls within a configuration scope. The scopes
are:
system::
$(prefix)/etc/gitconfig
global::
$XDG_CONFIG_HOME/git/config
+
~/.gitconfig
local::
$GIT_DIR/config
worktree::
$GIT_DIR/config.worktree
command::
GIT_CONFIG_{COUNT,KEY,VALUE} environment variables (see <<ENVIRONMENT>>
below)
+
the `-c` option
With the exception of 'command', each scope corresponds to a command line
option: `--system`, `--global`, `--local`, `--worktree`.
When reading options, specifying a scope will only read options from the
files within that scope. When writing options, specifying a scope will write
to the files within that scope (instead of the repository specific
configuration file). See <<OPTIONS>> above for a complete description.
Most configuration options are respected regardless of the scope it is
defined in, but some options are only respected in certain scopes. See the
respective option's documentation for the full details.
Protected configuration
~~~~~~~~~~~~~~~~~~~~~~~
Protected configuration refers to the 'system', 'global', and 'command' scopes.
For security reasons, certain options are only respected when they are
specified in protected configuration, and ignored otherwise.
Git treats these scopes as if they are controlled by the user or a trusted
administrator. This is because an attacker who controls these scopes can do
substantial harm without using Git, so it is assumed that the user's environment
protects these scopes against attackers.
[[ENVIRONMENT]]
ENVIRONMENT
-----------

View File

@ -1,5 +1,5 @@
git-credential-cache{litdd}daemon(1)
====================================
git-credential-cache--daemon(1)
===============================
NAME
----
@ -8,7 +8,7 @@ git-credential-cache--daemon - Temporarily store user credentials in memory
SYNOPSIS
--------
[verse]
'git credential-cache{litdd}daemon' [--debug] <socket>
git credential-cache--daemon [--debug] <socket>
DESCRIPTION
-----------

View File

@ -63,10 +63,11 @@ Print version information and exit
Print usage information and exit
<directory>::
The remaining arguments provide a list of directories. If no directories
are given, then all are allowed. Repositories within these directories
still require the `gitcvs.enabled` config option, unless `--export-all`
is specified.
You can specify a list of allowed directories. If no directories
are given, all are allowed. This is an additional restriction, gitcvs
access still needs to be enabled by the `gitcvs.enabled` config option
unless `--export-all` was given, too.
LIMITATIONS
-----------
@ -310,13 +311,11 @@ ENVIRONMENT
These variables obviate the need for command-line options in some
circumstances, allowing easier restricted usage through git-shell.
GIT_CVSSERVER_BASE_PATH::
This variable replaces the argument to --base-path.
GIT_CVSSERVER_BASE_PATH takes the place of the argument to --base-path.
GIT_CVSSERVER_ROOT::
This variable specifies a single directory, replacing the
`<directory>...` argument list. The repository still requires the
`gitcvs.enabled` config option, unless `--export-all` is specified.
GIT_CVSSERVER_ROOT specifies a single-directory whitelist. The
repository must still be configured to allow access through
git-cvsserver, as described above.
When these environment variables are set, the corresponding
command-line arguments may not be used.

View File

@ -32,8 +32,8 @@ that service if it is enabled.
It verifies that the directory has the magic file "git-daemon-export-ok", and
it will refuse to export any Git directory that hasn't explicitly been marked
for export this way (unless the `--export-all` parameter is specified). If you
pass some directory paths as 'git daemon' arguments, the offers are limited to
repositories within those directories.
pass some directory paths as 'git daemon' arguments, you can further restrict
the offers to a whitelist comprising of those.
By default, only `upload-pack` service is enabled, which serves
'git fetch-pack' and 'git ls-remote' clients, which are invoked
@ -50,7 +50,7 @@ OPTIONS
Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
"/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
'git daemon' will refuse to start when this option is enabled and no
directory arguments are provided.
whitelist is specified.
--base-path=<path>::
Remap all the path requests as relative to the given path.
@ -73,7 +73,7 @@ OPTIONS
%IP for the server's IP address, %P for the port number,
and %D for the absolute path of the named repository.
After interpolation, the path is validated against the directory
list.
whitelist.
--export-all::
Allow pulling from all directories that look like Git repositories
@ -218,11 +218,9 @@ standard output to be sent to the requestor as an error message when
it declines the service.
<directory>::
The remaining arguments provide a list of directories. If any
directories are specified, then the `git-daemon` process will
serve a requested directory only if it is contained in one of
these directories. If `--strict-paths` is specified, then the
requested directory must match one of these directories exactly.
A directory to add to the whitelist of allowed directories. Unless
--strict-paths is specified this will also include subdirectories
of each named directory.
SERVICES
--------
@ -266,8 +264,9 @@ git 9418/tcp # Git Version Control System
'git daemon' as inetd server::
To set up 'git daemon' as an inetd service that handles any
repository within `/pub/foo` or `/pub/bar`, place an entry like
the following into `/etc/inetd` all on one line:
repository under the whitelisted set of directories, /pub/foo
and /pub/bar, place an entry like the following into
/etc/inetd all on one line:
+
------------------------------------------------
git stream tcp nowait nobody /usr/bin/git

View File

@ -1,65 +0,0 @@
git-diagnose(1)
================
NAME
----
git-diagnose - Generate a zip archive of diagnostic information
SYNOPSIS
--------
[verse]
'git diagnose' [(-o | --output-directory) <path>] [(-s | --suffix) <format>]
[--mode=<mode>]
DESCRIPTION
-----------
Collects detailed information about the user's machine, Git client, and
repository state and packages that information into a zip archive. The
generated archive can then, for example, be shared with the Git mailing list to
help debug an issue or serve as a reference for independent debugging.
By default, the following information is captured in the archive:
* 'git version --build-options'
* The path to the repository root
* The available disk space on the filesystem
* The name and size of each packfile, including those in alternate object
stores
* The total count of loose objects, as well as counts broken down by
`.git/objects` subdirectory
Additional information can be collected by selecting a different diagnostic mode
using the `--mode` option.
This tool differs from linkgit:git-bugreport[1] in that it collects much more
detailed information with a greater focus on reporting the size and data shape
of repository contents.
OPTIONS
-------
-o <path>::
--output-directory <path>::
Place the resulting diagnostics archive in `<path>` instead of the
current directory.
-s <format>::
--suffix <format>::
Specify an alternate suffix for the diagnostics archive name, to create
a file named 'git-diagnostics-<formatted suffix>'. This should take the
form of a strftime(3) format string; the current local time will be
used.
--mode=(stats|all)::
Specify the type of diagnostics that should be collected. The default behavior
of 'git diagnose' is equivalent to `--mode=stats`.
+
The `--mode=all` option collects everything included in `--mode=stats`, as well
as copies of `.git`, `.git/hooks`, `.git/info`, `.git/logs`, and
`.git/objects/info` directories. This additional information may be sensitive,
as it can be used to reconstruct the full contents of the diagnosed repository.
Users should exercise caution when sharing an archive generated with
`--mode=all`.
GIT
---
Part of the linkgit:git[1] suite

View File

@ -69,8 +69,8 @@ done an `update-index` to make that effective in the index file.
matches my working directory. But doing a 'git diff-index' does:
torvalds@ppc970:~/git> git diff-index --cached HEAD
:100644 000000 4161aecc6700a2eb579e842af0b7f22b98443f74 0000000000000000000000000000000000000000 D commit.c
:000000 100644 0000000000000000000000000000000000000000 4161aecc6700a2eb579e842af0b7f22b98443f74 A git-commit.c
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
You can see easily that the above is a rename.
@ -103,7 +103,7 @@ have not actually done a 'git update-index' on it yet - there is no
"object" associated with the new state, and you get:
torvalds@ppc970:~/v2.6/linux> git diff-index --abbrev HEAD
:100644 100644 7476bb5ba 000000000 M kernel/sched.c
:100644 100664 7476bb... 000000... kernel/sched.c
i.e., it shows that the tree has changed, and that `kernel/sched.c` is
not up to date and may contain new stuff. The all-zero sha1 means that to

View File

@ -213,13 +213,6 @@ $ git diff -R <2>
rewrites (very expensive).
<2> Output diff in reverse.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/diff.txt[]
SEE ALSO
--------
diff(1),

View File

@ -113,14 +113,33 @@ instead. `--no-symlinks` is the default on Windows.
See linkgit:git-diff[1] for the full list of supported options.
CONFIGURATION
-------------
CONFIG VARIABLES
----------------
'git difftool' falls back to 'git mergetool' config variables when the
difftool equivalents have not been defined.
include::includes/cmd-config-section-rest.txt[]
diff.tool::
The default diff tool to use.
include::config/difftool.txt[]
diff.guitool::
The default diff tool to use when `--gui` is specified.
difftool.<tool>.path::
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
difftool.<tool>.cmd::
Specify the command to invoke the specified diff tool.
+
See the `--tool=<tool>` option above for more details.
difftool.prompt::
Prompt before each invocation of the diff tool.
difftool.trustExitCode::
Exit difftool if the invoked diff tool returns a non-zero exit status.
+
See the `--trust-exit-code` option above for more details.
SEE ALSO
--------

View File

@ -1564,13 +1564,6 @@ operator can use this facility to peek at the objects and refs from an
import in progress, at the cost of some added running time and worse
compression.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/fastimport.txt[]
SEE ALSO
--------
linkgit:git-fast-export[1]

View File

@ -101,10 +101,6 @@ be in a separate packet, and the list must end with a flush packet.
current shallow boundary instead of from the tip of each
remote branch history.
--refetch::
Skips negotiating commits with the server in order to fetch all matching
objects. Use to reapply a new partial clone blob/tree filter.
--no-progress::
Do not show the progress.

View File

@ -285,19 +285,14 @@ linkgit:git-gc[1]).
include::transfer-data-leaks.txt[]
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/fetch.txt[]
BUGS
----
Using --recurse-submodules can only fetch new commits in submodules that are
present locally e.g. in `$GIT_DIR/modules/`. If the upstream adds a new
submodule, that submodule cannot be fetched until it is cloned e.g. by `git
submodule update`. This is expected to be fixed in a future Git version.
Using --recurse-submodules can only fetch new commits in already checked
out submodules right now. When e.g. upstream added a new submodule in the
just fetched commits of the superproject the submodule itself cannot be
fetched, making it impossible to check out that submodule later without
having to do a fetch again. This is expected to be fixed in a future Git
version.
SEE ALSO
--------

View File

@ -275,17 +275,6 @@ header). Note also that `git send-email` already handles this
transformation for you, and this option should not be used if you are
feeding the result to `git send-email`.
--[no-]force-in-body-from::
With the e-mail sender specified via the `--from` option, by
default, an in-body "From:" to identify the real author of
the commit is added at the top of the commit log message if
the sender is different from the author. With this option,
the in-body "From:" is added even when the sender and the
author have the same name and address, which may help if the
mailing list software mangles the sender's identity.
Defaults to the value of the `format.forceInBodyFrom`
configuration variable.
--add-header=<header>::
Add an arbitrary header to the email headers. This is in addition
to any configured headers, and may be used multiple times.

View File

@ -107,8 +107,6 @@ care about this output and want to speed it up further.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
include::config/fsck.txt[]
DISCUSSION

View File

@ -1,75 +0,0 @@
git-fsmonitor{litdd}daemon(1)
=============================
NAME
----
git-fsmonitor--daemon - A Built-in File System Monitor
SYNOPSIS
--------
[verse]
'git fsmonitor{litdd}daemon' start
'git fsmonitor{litdd}daemon' run
'git fsmonitor{litdd}daemon' stop
'git fsmonitor{litdd}daemon' status
DESCRIPTION
-----------
A daemon to watch the working directory for file and directory
changes using platform-specific file system notification facilities.
This daemon communicates directly with commands like `git status`
using the link:technical/api-simple-ipc.html[simple IPC] interface
instead of the slower linkgit:githooks[5] interface.
This daemon is built into Git so that no third-party tools are
required.
OPTIONS
-------
start::
Starts a daemon in the background.
run::
Runs a daemon in the foreground.
stop::
Stops the daemon running in the current working
directory, if present.
status::
Exits with zero status if a daemon is watching the
current working directory.
REMARKS
-------
This daemon is a long running process used to watch a single working
directory and maintain a list of the recently changed files and
directories. Performance of commands such as `git status` can be
increased if they just ask for a summary of changes to the working
directory and can avoid scanning the disk.
When `core.fsmonitor` is set to `true` (see linkgit:git-config[1])
commands, such as `git status`, will ask the daemon for changes and
automatically start it (if necessary).
For more information see the "File System Monitor" section in
linkgit:git-update-index[1].
CAVEATS
-------
The fsmonitor daemon does not currently know about submodules and does
not know to filter out file system events that happen within a
submodule. If fsmonitor daemon is watching a super repo and a file is
modified within the working directory of a submodule, it will report
the change (as happening against the super repo). However, the client
will properly ignore these extra events, so performance may be affected
but it will not cause an incorrect result.
GIT
---
Part of the linkgit:git[1] suite

View File

@ -54,10 +54,6 @@ other housekeeping tasks (e.g. rerere, working trees, reflog...) will
be performed as well.
--cruft::
When expiring unreachable objects, pack them separately into a
cruft pack instead of storing them as loose objects.
--prune=<date>::
Prune loose objects older than date (default is 2 weeks ago,
overridable by the config variable `gc.pruneExpire`).
@ -110,7 +106,8 @@ users and their repositories.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
The below documentation is the same as what's found in
linkgit:git-config[1]:
include::config/gc.txt[]

View File

@ -23,7 +23,6 @@ SYNOPSIS
[--break] [--heading] [-p | --show-function]
[-A <post-context>] [-B <pre-context>] [-C <context>]
[-W | --function-context]
[(-m | --max-count) <num>]
[--threads <num>]
[-f <file>] [-e] <pattern>
[--and|--or|--not|(|)|-e <pattern>...]
@ -239,14 +238,6 @@ providing this option will cause it to die.
`git diff` works out patch hunk headers (see 'Defining a
custom hunk-header' in linkgit:gitattributes[5]).
-m <num>::
--max-count <num>::
Limit the amount of matches per file. When using the `-v` or
`--invert-match` option, the search stops after the specified
number of non-matches. A value of -1 will return unlimited
results (the default). A value of 0 will exit immediately with
a non-zero status.
--threads <num>::
Number of grep worker threads to use.
See `grep.threads` in 'CONFIGURATION' for more information.
@ -343,9 +334,34 @@ performance in this case, it might be desirable to use `--threads=1`.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.txt[]
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.
include::config/grep.txt[]
GIT
---

Some files were not shown because too many files have changed in this diff Show More