Compare commits

..

96 Commits

Author SHA1 Message Date
c735d7470e Git 2.21.4
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2021-02-12 15:49:36 +01:00
b1726b1a38 Sync with 2.20.5
* maint-2.20:
  Git 2.20.5
  Git 2.19.6
  Git 2.18.5
  Git 2.17.6
  unpack_trees(): start with a fresh lstat cache
  run-command: invalidate lstat cache after a command finished
  checkout: fix bug that makes checkout follow symlinks in leading path
2021-02-12 15:49:35 +01:00
8b1a5f33d3 Git 2.20.5
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2021-02-12 15:49:17 +01:00
804963848e Sync with 2.19.6
* maint-2.19:
  Git 2.19.6
  Git 2.18.5
  Git 2.17.6
  unpack_trees(): start with a fresh lstat cache
  run-command: invalidate lstat cache after a command finished
  checkout: fix bug that makes checkout follow symlinks in leading path
2021-02-12 15:49:17 +01:00
9fb2a1fb08 Git 2.19.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2021-02-12 15:47:48 +01:00
fb049fd85b Sync with 2.18.5
* maint-2.18:
  Git 2.18.5
  Git 2.17.6
  unpack_trees(): start with a fresh lstat cache
  run-command: invalidate lstat cache after a command finished
  checkout: fix bug that makes checkout follow symlinks in leading path
2021-02-12 15:47:47 +01:00
6eed462c8f Git 2.18.5
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2021-02-12 15:47:43 +01:00
9b77cec89b Sync with 2.17.6
* maint-2.17:
  Git 2.17.6
  unpack_trees(): start with a fresh lstat cache
  run-command: invalidate lstat cache after a command finished
  checkout: fix bug that makes checkout follow symlinks in leading path
2021-02-12 15:47:42 +01:00
6b82d3eea6 Git 2.17.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2021-02-12 15:47:02 +01:00
22539ec3b5 unpack_trees(): start with a fresh lstat cache
We really want to avoid relying on stale information.

Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2021-02-12 15:47:02 +01:00
0d58fef58a run-command: invalidate lstat cache after a command finished
In the previous commit, we intercepted calls to `rmdir()` to invalidate
the lstat cache in the successful case, so that the lstat cache could
not have the idea that a directory exists where there is none.

The same situation can arise, of course, when a separate process is
spawned (most notably, this is the case in `submodule_move_head()`).
Obviously, we cannot know whether a directory was removed in that
process, therefore we must invalidate the lstat cache afterwards.

Note: in contrast to `lstat_cache_aware_rmdir()`, we invalidate the
lstat cache even in case of an error: the process might have removed a
directory and still have failed afterwards.

Co-authored-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2021-02-12 15:47:02 +01:00
684dd4c2b4 checkout: fix bug that makes checkout follow symlinks in leading path
Before checking out a file, we have to confirm that all of its leading
components are real existing directories. And to reduce the number of
lstat() calls in this process, we cache the last leading path known to
contain only directories. However, when a path collision occurs (e.g.
when checking out case-sensitive files in case-insensitive file
systems), a cached path might have its file type changed on disk,
leaving the cache on an invalid state. Normally, this doesn't bring
any bad consequences as we usually check out files in index order, and
therefore, by the time the cached path becomes outdated, we no longer
need it anyway (because all files in that directory would have already
been written).

But, there are some users of the checkout machinery that do not always
follow the index order. In particular: checkout-index writes the paths
in the same order that they appear on the CLI (or stdin); and the
delayed checkout feature -- used when a long-running filter process
replies with "status=delayed" -- postpones the checkout of some entries,
thus modifying the checkout order.

When we have to check out an out-of-order entry and the lstat() cache is
invalid (due to a previous path collision), checkout_entry() may end up
using the invalid data and thrusting that the leading components are
real directories when, in reality, they are not. In the best case
scenario, where the directory was replaced by a regular file, the user
will get an error: "fatal: unable to create file 'foo/bar': Not a
directory". But if the directory was replaced by a symlink, checkout
could actually end up following the symlink and writing the file at a
wrong place, even outside the repository. Since delayed checkout is
affected by this bug, it could be used by an attacker to write
arbitrary files during the clone of a maliciously crafted repository.

Some candidate solutions considered were to disable the lstat() cache
during unordered checkouts or sort the entries before passing them to
the checkout machinery. But both ideas include some performance penalty
and they don't future-proof the code against new unordered use cases.

Instead, we now manually reset the lstat cache whenever we successfully
remove a directory. Note: We are not even checking whether the directory
was the same as the lstat cache points to because we might face a
scenario where the paths refer to the same location but differ due to
case folding, precomposed UTF-8 issues, or the presence of `..`
components in the path. Two regression tests, with case-collisions and
utf8-collisions, are also added for both checkout-index and delayed
checkout.

Note: to make the previously mentioned clone attack unfeasible, it would
be sufficient to reset the lstat cache only after the remove_subtree()
call inside checkout_entry(). This is the place where we would remove a
directory whose path collides with the path of another entry that we are
currently trying to check out (possibly a symlink). However, in the
interest of a thorough fix that does not leave Git open to
similar-but-not-identical attack vectors, we decided to intercept
all `rmdir()` calls in one fell swoop.

This addresses CVE-2021-21300.

Co-authored-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
2021-02-12 15:47:02 +01:00
9206d27eb5 Git 2.21.3
This merges up the security fix from v2.17.5.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2020-04-19 16:30:08 -07:00
041bc65923 Git 2.20.4
This merges up the security fix from v2.17.5.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2020-04-19 16:28:57 -07:00
76b54ee9b9 Git 2.19.5
This merges up the security fix from v2.17.5.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2020-04-19 16:26:41 -07:00
ba6f0905fd Git 2.18.4
This merges up the security fix from v2.17.5.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2020-04-19 16:24:14 -07:00
df5be6dc3f Git 2.17.5
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2020-04-19 16:10:58 -07:00
1a3609e402 fsck: reject URL with empty host in .gitmodules
Git's URL parser interprets

	https:///example.com/repo.git

to have no host and a path of "example.com/repo.git".  Curl, on the
other hand, internally redirects it to https://example.com/repo.git.  As
a result, until "credential: parse URL without host as empty host, not
unset", tricking a user into fetching from such a URL would cause Git to
send credentials for another host to example.com.

Teach fsck to block and detect .gitmodules files using such a URL to
prevent sharing them with Git versions that are not yet protected.

A relative URL in a .gitmodules file could also be used to trigger this.
The relative URL resolver used for .gitmodules does not normalize
sequences of slashes and can follow ".." components out of the path part
and to the host part of a URL, meaning that such a relative URL can be
used to traverse from a https://foo.example.com/innocent superproject to
a https:///attacker.example.com/exploit submodule. Fortunately,
redundant extra slashes in .gitmodules are rare, so we can catch this by
detecting one after a leading sequence of "./" and "../" components.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
2020-04-19 16:10:58 -07:00
e7fab62b73 credential: treat URL with empty scheme as invalid
Until "credential: refuse to operate when missing host or protocol",
Git's credential handling code interpreted URLs with empty scheme to
mean "give me credentials matching this host for any protocol".

Luckily libcurl does not recognize such URLs (it tries to look for a
protocol named "" and fails). Just in case that changes, let's reject
them within Git as well. This way, credential_from_url is guaranteed to
always produce a "struct credential" with protocol and host set.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2020-04-19 16:10:58 -07:00
c44088ecc4 credential: treat URL without scheme as invalid
libcurl permits making requests without a URL scheme specified.  In
this case, it guesses the URL from the hostname, so I can run

	git ls-remote http::ftp.example.com/path/to/repo

and it would make an FTP request.

Any user intentionally using such a URL is likely to have made a typo.
Unfortunately, credential_from_url is not able to determine the host and
protocol in order to determine appropriate credentials to send, and
until "credential: refuse to operate when missing host or protocol",
this resulted in another host's credentials being leaked to the named
host.

Teach credential_from_url_gently to consider such a URL to be invalid
so that fsck can detect and block gitmodules files with such URLs,
allowing server operators to avoid serving them to downstream users
running older versions of Git.

This also means that when such URLs are passed on the command line, Git
will print a clearer error so affected users can switch to the simpler
URL that explicitly specifies the host and protocol they intend.

One subtlety: .gitmodules files can contain relative URLs, representing
a URL relative to the URL they were cloned from.  The relative URL
resolver used for .gitmodules can follow ".." components out of the path
part and past the host part of a URL, meaning that such a relative URL
can be used to traverse from a https://foo.example.com/innocent
superproject to a https::attacker.example.com/exploit submodule.
Fortunately a leading ':' in the first path component after a series of
leading './' and '../' components is unlikely to show up in other
contexts, so we can catch this by detecting that pattern.

Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
2020-04-19 16:10:58 -07:00
fe29a9b7b0 credential: die() when parsing invalid urls
When we try to initialize credential loading by URL and find that the
URL is invalid, we set all fields to NULL in order to avoid acting on
malicious input. Later when we request credentials, we diagonse the
erroneous input:

	fatal: refusing to work with credential missing host field

This is problematic in two ways:

- The message doesn't tell the user *why* we are missing the host
  field, so they can't tell from this message alone how to recover.
  There can be intervening messages after the original warning of
  bad input, so the user may not have the context to put two and two
  together.

- The error only occurs when we actually need to get a credential.  If
  the URL permits anonymous access, the only encouragement the user gets
  to correct their bogus URL is a quiet warning.

  This is inconsistent with the check we perform in fsck, where any use
  of such a URL as a submodule is an error.

When we see such a bogus URL, let's not try to be nice and continue
without helpers. Instead, die() immediately. This is simpler and
obviously safe. And there's very little chance of disrupting a normal
workflow.

It's _possible_ that somebody has a legitimate URL with a raw newline in
it. It already wouldn't work with credential helpers, so this patch
steps that up from an inconvenience to "we will refuse to work with it
at all". If such a case does exist, we should figure out a way to work
with it (especially if the newline is only in the path component, which
we normally don't even pass to helpers). But until we see a real report,
we're better off being defensive.

Reported-by: Carlo Arenas <carenas@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2020-04-19 16:10:58 -07:00
a2b26ffb1a fsck: convert gitmodules url to URL passed to curl
In 07259e74ec (fsck: detect gitmodules URLs with embedded newlines,
2020-03-11), git fsck learned to check whether URLs in .gitmodules could
be understood by the credential machinery when they are handled by
git-remote-curl.

However, the check is overbroad: it checks all URLs instead of only
URLs that would be passed to git-remote-curl. In principle a git:// or
file:/// URL does not need to follow the same conventions as an http://
URL; in particular, git:// and file:// protocols are not succeptible to
issues in the credential API because they do not support attaching
credentials.

In the HTTP case, the URL in .gitmodules does not always match the URL
that would be passed to git-remote-curl and the credential machinery:
Git's URL syntax allows specifying a remote helper followed by a "::"
delimiter and a URL to be passed to it, so that

	git ls-remote http::https://example.com/repo.git

invokes git-remote-http with https://example.com/repo.git as its URL
argument. With today's checks, that distinction does not make a
difference, but for a check we are about to introduce (for empty URL
schemes) it will matter.

.gitmodules files also support relative URLs. To ensure coverage for the
https based embedded-newline attack, urldecode and check them directly
for embedded newlines.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
2020-04-19 16:10:58 -07:00
8ba8ed568e credential: refuse to operate when missing host or protocol
The credential helper protocol was designed to be very flexible: the
fields it takes as input are treated as a pattern, and any missing
fields are taken as wildcards. This allows unusual things like:

  echo protocol=https | git credential reject

to delete all stored https credentials (assuming the helpers themselves
treat the input that way). But when helpers are invoked automatically by
Git, this flexibility works against us. If for whatever reason we don't
have a "host" field, then we'd match _any_ host. When you're filling a
credential to send to a remote server, this is almost certainly not what
you want.

Prevent this at the layer that writes to the credential helper. Add a
check to the credential API that the host and protocol are always passed
in, and add an assertion to the credential_write function that speaks
credential helper protocol to be doubly sure.

There are a few ways this can be triggered in practice:

  - the "git credential" command passes along arbitrary credential
    parameters it reads from stdin.

  - until the previous patch, when the host field of a URL is empty, we
    would leave it unset (rather than setting it to the empty string)

  - a URL like "example.com/foo.git" is treated by curl as if "http://"
    was present, but our parser sees it as a non-URL and leaves all
    fields unset

  - the recent fix for URLs with embedded newlines blanks the URL but
    otherwise continues. Rather than having the desired effect of
    looking up no credential at all, many helpers will return _any_
    credential

Our earlier test for an embedded newline didn't catch this because it
only checked that the credential was cleared, but didn't configure an
actual helper. Configuring the "verbatim" helper in the test would show
that it is invoked (it's obviously a silly helper which doesn't look at
its input, but the point is that it shouldn't be run at all). Since
we're switching this case to die(), we don't need to bother with a
helper. We can see the new behavior just by checking that the operation
fails.

We'll add new tests covering partial input as well (these can be
triggered through various means with url-parsing, but it's simpler to
just check them directly, as we know we are covered even if the url
parser changes behavior in the future).

[jn: changed to die() instead of logging and showing a manual
 username/password prompt]

Reported-by: Carlo Arenas <carenas@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2020-04-19 16:10:58 -07:00
24036686c4 credential: parse URL without host as empty host, not unset
We may feed a URL like "cert:///path/to/cert.pem" into the credential
machinery to get the key for a client-side certificate. That
credential has no hostname field, which is about to be disallowed (to
avoid confusion with protocols where a helper _would_ expect a
hostname).

This means as of the next patch, credential helpers won't work for
unlocking certs. Let's fix that by doing two things:

  - when we parse a url with an empty host, set the host field to the
    empty string (asking only to match stored entries with an empty
    host) rather than NULL (asking to match _any_ host).

  - when we build a cert:// credential by hand, similarly assign an
    empty string

It's the latter that is more likely to impact real users in practice,
since it's what's used for http connections. But we don't have good
infrastructure to test it.

The url-parsing version will help anybody using git-credential in a
script, and is easy to test.

Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2020-04-19 16:10:57 -07:00
73aafe9bc2 t0300: use more realistic inputs
Many of the tests in t0300 give partial inputs to git-credential,
omitting a protocol or hostname. We're checking only high-level things
like whether and how helpers are invoked at all, and we don't care about
specific hosts. However, in preparation for tightening up the rules
about when we're willing to run a helper, let's start using input that's
a bit more realistic: pretend as if http://example.com is being
examined.

This shouldn't change the point of any of the tests, but do note we have
to adjust the expected output to accommodate this (filling a credential
will repeat back the protocol/host fields to stdout, and the helper
debug messages and askpass prompt will change on stderr).

Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2020-04-19 16:10:57 -07:00
a88dbd2f8c t0300: make "quit" helper more realistic
We test a toy credential helper that writes "quit=1" and confirms that
we stop running other helpers. However, that helper is unrealistic in
that it does not bother to read its stdin at all.

For now we don't send any input to it, because we feed git-credential a
blank credential. But that will change in the next patch, which will
cause this test to racily fail, as git-credential will get SIGPIPE
writing to the helper rather than exiting because it was asked to.

Let's make this one-off helper more like our other sample helpers, and
have it source the "dump" script. That will read stdin, fixing the
SIGPIPE problem. But it will also write what it sees to stderr. We can
make the test more robust by checking that output, which confirms that
we do run the quit helper, don't run any other helpers, and exit for the
reason we expected.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2020-04-19 16:10:52 -07:00
fe22686494 Git 2.21.2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17 14:16:08 -07:00
d1259ce117 Git 2.20.3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17 13:46:10 -07:00
a5979d7009 Git 2.19.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17 13:43:08 -07:00
21a3e5016b Git 2.18.3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17 13:34:12 -07:00
c42c0f1297 Git 2.17.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17 13:25:33 -07:00
07259e74ec fsck: detect gitmodules URLs with embedded newlines
The credential protocol can't handle values with newlines. We already
detect and block any such URLs from being used with credential helpers,
but let's also add an fsck check to detect and block gitmodules files
with such URLs. That will let us notice the problem earlier when
transfer.fsckObjects is turned on. And in particular it will prevent bad
objects from spreading, which may protect downstream users running older
versions of Git.

We'll file this under the existing gitmodulesUrl flag, which covers URLs
with option injection. There's really no need to distinguish the exact
flaw in the URL in this context. Likewise, I've expanded the description
of t7416 to cover all types of bogus URLs.
2020-03-12 02:56:50 -04:00
c716fe4bd9 credential: detect unrepresentable values when parsing urls
The credential protocol can't represent newlines in values, but URLs can
embed percent-encoded newlines in various components. A previous commit
taught the low-level writing routines to die() when encountering this,
but we can be a little friendlier to the user by detecting them earlier
and handling them gracefully.

This patch teaches credential_from_url() to notice such components,
issue a warning, and blank the credential (which will generally result
in prompting the user for a username and password). We blank the whole
credential in this case. Another option would be to blank only the
invalid component. However, we're probably better off not feeding a
partially-parsed URL result to a credential helper. We don't know how a
given helper would handle it, so we're better off to err on the side of
matching nothing rather than something unexpected.

The die() call in credential_write() is _probably_ impossible to reach
after this patch. Values should end up in credential structs only by URL
parsing (which is covered here), or by reading credential protocol input
(which by definition cannot read a newline into a value). But we should
definitely keep the low-level check, as it's our final and most accurate
line of defense against protocol injection attacks. Arguably it could
become a BUG(), but it probably doesn't matter much either way.

Note that the public interface of credential_from_url() grows a little
more than we need here. We'll use the extra flexibility in a future
patch to help fsck catch these cases.
2020-03-12 02:55:24 -04:00
17f1c0b8c7 t/lib-credential: use test_i18ncmp to check stderr
The credential tests have a "check" function which feeds some input to
git-credential and checks the stdout and stderr. We look for exact
matches in the output. For stdout, this makes sense; the output is
the credential protocol. But for stderr, we may be showing various
diagnostic messages, or the prompts fed to the askpass program, which
could be translated. Let's mark them as such.
2020-03-12 02:55:17 -04:00
9a6bbee800 credential: avoid writing values with newlines
The credential protocol that we use to speak to helpers can't represent
values with newlines in them. This was an intentional design choice to
keep the protocol simple, since none of the values we pass should
generally have newlines.

However, if we _do_ encounter a newline in a value, we blindly transmit
it in credential_write(). Such values may break the protocol syntax, or
worse, inject new valid lines into the protocol stream.

The most likely way for a newline to end up in a credential struct is by
decoding a URL with a percent-encoded newline. However, since the bug
occurs at the moment we write the value to the protocol, we'll catch it
there. That should leave no possibility of accidentally missing a code
path that can trigger the problem.

At this level of the code we have little choice but to die(). However,
since we'd not ever expect to see this case outside of a malicious URL,
that's an acceptable outcome.

Reported-by: Felix Wilhelm <fwilhelm@google.com>
2020-03-12 02:55:16 -04:00
367f12b7e9 Git 2.21.1
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:31:15 +01:00
20c71bcf67 Merge branch 'fix-msys2-quoting-bugs'
These patches fix several bugs in quoting arguments when spawning shell
scripts on Windows.

Note: these bugs are Windows-only, as we have to construct a command
line for the process-to-spawn, unlike Linux/macOS, where `execv()`
accepts an already-split command line.

Furthermore, these fixes were not included in the CVE-2019-1350 part of
v2.14.6 because the Windows-specific quoting when spawning shell scripts
was contributed from Git for Windows into Git only in the v2.21.x era.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:31:15 +01:00
7d8b676992 mingw: sh arguments need quoting in more circumstances
Previously, we failed to quote characters such as '*', '(' and the
likes. Let's fix this.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:31:15 +01:00
d9061ed9da t7415: drop v2.20.x-specific work-around
This reverts the work-around that was introduced just for the v2.20.x
release train in "t7415: adjust test for dubiously-nested submodule
gitdirs for v2.20.x"; It is not necessary for v2.21.x.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:31:14 +01:00
04522edbd4 mingw: fix quoting of empty arguments for sh
When constructing command-lines to spawn processes, it is an unfortunate
but necessary decision to quote arguments differently: MSYS2 has
different dequoting rules (inherited from Cygwin) than the rest of
Windows.

To accommodate that, Git's Windows compatibility layer has two separate
quoting helpers, one for MSYS2 (which it uses exclusively when spawning
`sh`) and the other for regular Windows executables.

The MSYS2 one had an unfortunate bug where a `,` somehow slipped in,
instead of the `;`. As a consequence, empty arguments would not be
enclosed in a pair of double quotes, but the closing double quote was
skipped.

Let's fix this.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:31:14 +01:00
49f7a76d57 mingw: use MSYS2 quoting even when spawning shell scripts
At the point where `mingw_spawn_fd()` is called, we already have a full
path to the script interpreter in that scenario, and we pass it in as
the executable to run, while the `argv` reflect what the script should
receive as command-line.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:31:14 +01:00
e2ba3d6f6d mingw: detect when MSYS2's sh is to be spawned more robustly
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:31:14 +01:00
fc346cb292 Sync with 2.20.2
* maint-2.20: (36 commits)
  Git 2.20.2
  t7415: adjust test for dubiously-nested submodule gitdirs for v2.20.x
  Git 2.19.3
  Git 2.18.2
  Git 2.17.3
  Git 2.16.6
  test-drop-caches: use `has_dos_drive_prefix()`
  Git 2.15.4
  Git 2.14.6
  mingw: handle `subst`-ed "DOS drives"
  mingw: refuse to access paths with trailing spaces or periods
  mingw: refuse to access paths with illegal characters
  unpack-trees: let merged_entry() pass through do_add_entry()'s errors
  quote-stress-test: offer to test quoting arguments for MSYS2 sh
  t6130/t9350: prepare for stringent Win32 path validation
  quote-stress-test: allow skipping some trials
  quote-stress-test: accept arguments to test via the command-line
  tests: add a helper to stress test argument quoting
  mingw: fix quoting of arguments
  Disallow dubiously-nested submodule git directories
  ...
2019-12-06 16:31:12 +01:00
4cd1cf31ef Git 2.20.2
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:30:51 +01:00
c154745074 submodule: defend against submodule.update = !command in .gitmodules
In v2.15.4, we started to reject `submodule.update` settings in
`.gitmodules`. Let's raise a BUG if it somehow still made it through
from anywhere but the Git config.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2019-12-06 16:30:50 +01:00
4cfc47de25 t7415: adjust test for dubiously-nested submodule gitdirs for v2.20.x
In v2.20.x, Git clones submodules recursively by first creating the
submodules' gitdirs and _then_ "updating" the submodules. This can lead
to the situation where the clone path is taken because the directory
(while it exists already) is not a git directory, but then the clone
fails because that gitdir is unexpectedly already a directory.

This _also_ works around the vulnerability that was fixed in "Disallow
dubiously-nested submodule git directories", but it produces a different
error message than the one expected by the test case, therefore we
adjust the test case accordingly.

Note: as the two submodules "race each other", there are actually two
possible error messages, therefore we have to teach the test case to
expect _two_ possible (and good) outcomes in addition to the one it
expected before.

Note: this workaround is only necessary for the v2.20.x release train;
The behavior changed again in v2.21.x so that the original test case's
expectations are met again.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:30:50 +01:00
d851d94151 Sync with 2.19.3
* maint-2.19: (34 commits)
  Git 2.19.3
  Git 2.18.2
  Git 2.17.3
  Git 2.16.6
  test-drop-caches: use `has_dos_drive_prefix()`
  Git 2.15.4
  Git 2.14.6
  mingw: handle `subst`-ed "DOS drives"
  mingw: refuse to access paths with trailing spaces or periods
  mingw: refuse to access paths with illegal characters
  unpack-trees: let merged_entry() pass through do_add_entry()'s errors
  quote-stress-test: offer to test quoting arguments for MSYS2 sh
  t6130/t9350: prepare for stringent Win32 path validation
  quote-stress-test: allow skipping some trials
  quote-stress-test: accept arguments to test via the command-line
  tests: add a helper to stress test argument quoting
  mingw: fix quoting of arguments
  Disallow dubiously-nested submodule git directories
  protect_ntfs: turn on NTFS protection by default
  path: also guard `.gitmodules` against NTFS Alternate Data Streams
  ...
2019-12-06 16:30:49 +01:00
caccc527ca Git 2.19.3
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:30:40 +01:00
7c9fbda6e2 Sync with 2.18.2
* maint-2.18: (33 commits)
  Git 2.18.2
  Git 2.17.3
  Git 2.16.6
  test-drop-caches: use `has_dos_drive_prefix()`
  Git 2.15.4
  Git 2.14.6
  mingw: handle `subst`-ed "DOS drives"
  mingw: refuse to access paths with trailing spaces or periods
  mingw: refuse to access paths with illegal characters
  unpack-trees: let merged_entry() pass through do_add_entry()'s errors
  quote-stress-test: offer to test quoting arguments for MSYS2 sh
  t6130/t9350: prepare for stringent Win32 path validation
  quote-stress-test: allow skipping some trials
  quote-stress-test: accept arguments to test via the command-line
  tests: add a helper to stress test argument quoting
  mingw: fix quoting of arguments
  Disallow dubiously-nested submodule git directories
  protect_ntfs: turn on NTFS protection by default
  path: also guard `.gitmodules` against NTFS Alternate Data Streams
  is_ntfs_dotgit(): speed it up
  ...
2019-12-06 16:30:38 +01:00
9877106b01 Git 2.18.2
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:29:17 +01:00
14af7ed5a9 Sync with 2.17.3
* maint-2.17: (32 commits)
  Git 2.17.3
  Git 2.16.6
  test-drop-caches: use `has_dos_drive_prefix()`
  Git 2.15.4
  Git 2.14.6
  mingw: handle `subst`-ed "DOS drives"
  mingw: refuse to access paths with trailing spaces or periods
  mingw: refuse to access paths with illegal characters
  unpack-trees: let merged_entry() pass through do_add_entry()'s errors
  quote-stress-test: offer to test quoting arguments for MSYS2 sh
  t6130/t9350: prepare for stringent Win32 path validation
  quote-stress-test: allow skipping some trials
  quote-stress-test: accept arguments to test via the command-line
  tests: add a helper to stress test argument quoting
  mingw: fix quoting of arguments
  Disallow dubiously-nested submodule git directories
  protect_ntfs: turn on NTFS protection by default
  path: also guard `.gitmodules` against NTFS Alternate Data Streams
  is_ntfs_dotgit(): speed it up
  mingw: disallow backslash characters in tree objects' file names
  ...
2019-12-06 16:29:15 +01:00
a5ab8d0317 Git 2.17.3
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:27:38 +01:00
bb92255ebe fsck: reject submodule.update = !command in .gitmodules
This allows hosting providers to detect whether they are being used
to attack users using malicious 'update = !command' settings in
.gitmodules.

Since ac1fbbda20 (submodule: do not copy unknown update mode from
.gitmodules, 2013-12-02), in normal cases such settings have been
treated as 'update = none', so forbidding them should not produce any
collateral damage to legitimate uses.  A quick search does not reveal
any repositories making use of this construct, either.

Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:27:38 +01:00
bdfef0492c Sync with 2.16.6
* maint-2.16: (31 commits)
  Git 2.16.6
  test-drop-caches: use `has_dos_drive_prefix()`
  Git 2.15.4
  Git 2.14.6
  mingw: handle `subst`-ed "DOS drives"
  mingw: refuse to access paths with trailing spaces or periods
  mingw: refuse to access paths with illegal characters
  unpack-trees: let merged_entry() pass through do_add_entry()'s errors
  quote-stress-test: offer to test quoting arguments for MSYS2 sh
  t6130/t9350: prepare for stringent Win32 path validation
  quote-stress-test: allow skipping some trials
  quote-stress-test: accept arguments to test via the command-line
  tests: add a helper to stress test argument quoting
  mingw: fix quoting of arguments
  Disallow dubiously-nested submodule git directories
  protect_ntfs: turn on NTFS protection by default
  path: also guard `.gitmodules` against NTFS Alternate Data Streams
  is_ntfs_dotgit(): speed it up
  mingw: disallow backslash characters in tree objects' file names
  path: safeguard `.git` against NTFS Alternate Streams Accesses
  ...
2019-12-06 16:27:36 +01:00
eb288bc455 Git 2.16.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:27:20 +01:00
68440496c7 test-drop-caches: use has_dos_drive_prefix()
This is a companion patch to 'mingw: handle `subst`-ed "DOS drives"':
use the DOS drive prefix handling that is already provided by
`compat/mingw.c` (and which just learned to handle non-alphabetical
"drive letters").

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:27:20 +01:00
9ac92fed5b Sync with 2.15.4
* maint-2.15: (29 commits)
  Git 2.15.4
  Git 2.14.6
  mingw: handle `subst`-ed "DOS drives"
  mingw: refuse to access paths with trailing spaces or periods
  mingw: refuse to access paths with illegal characters
  unpack-trees: let merged_entry() pass through do_add_entry()'s errors
  quote-stress-test: offer to test quoting arguments for MSYS2 sh
  t6130/t9350: prepare for stringent Win32 path validation
  quote-stress-test: allow skipping some trials
  quote-stress-test: accept arguments to test via the command-line
  tests: add a helper to stress test argument quoting
  mingw: fix quoting of arguments
  Disallow dubiously-nested submodule git directories
  protect_ntfs: turn on NTFS protection by default
  path: also guard `.gitmodules` against NTFS Alternate Data Streams
  is_ntfs_dotgit(): speed it up
  mingw: disallow backslash characters in tree objects' file names
  path: safeguard `.git` against NTFS Alternate Streams Accesses
  clone --recurse-submodules: prevent name squatting on Windows
  is_ntfs_dotgit(): only verify the leading segment
  ...
2019-12-06 16:27:18 +01:00
7cdafcaacf Git 2.15.4
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:26:58 +01:00
e904deb89d submodule: reject submodule.update = !command in .gitmodules
Since ac1fbbda20 (submodule: do not copy unknown update mode from
.gitmodules, 2013-12-02), Git has been careful to avoid copying

	[submodule "foo"]
		update = !run an arbitrary scary command

from .gitmodules to a repository's local config, copying in the
setting 'update = none' instead.  The gitmodules(5) manpage documents
the intention:

	The !command form is intentionally ignored here for security
	reasons

Unfortunately, starting with v2.20.0-rc0 (which integrated ee69b2a9
(submodule--helper: introduce new update-module-mode helper,
2018-08-13, first released in v2.20.0-rc0)), there are scenarios where
we *don't* ignore it: if the config store contains no
submodule.foo.update setting, the submodule-config API falls back to
reading .gitmodules and the repository-supplied !command gets run
after all.

This was part of a general change over time in submodule support to
read more directly from .gitmodules, since unlike .git/config it
allows a project to change values between branches and over time
(while still allowing .git/config to override things).  But it was
never intended to apply to this kind of dangerous configuration.

The behavior change was not advertised in ee69b2a9's commit message
and was missed in review.

Let's take the opportunity to make the protection more robust, even in
Git versions that are technically not affected: instead of quietly
converting 'update = !command' to 'update = none', noisily treat it as
an error.  Allowing the setting but treating it as meaning something
else was just confusing; users are better served by seeing the error
sooner.  Forbidding the construct makes the semantics simpler and
means we can check for it in fsck (in a separate patch).

As a result, the submodule-config API cannot read this value from
.gitmodules under any circumstance, and we can declare with confidence

	For security reasons, the '!command' form is not accepted
	here.

Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2019-12-06 16:26:58 +01:00
d3ac8c3f27 Sync with 2.14.6
* maint-2.14: (28 commits)
  Git 2.14.6
  mingw: handle `subst`-ed "DOS drives"
  mingw: refuse to access paths with trailing spaces or periods
  mingw: refuse to access paths with illegal characters
  unpack-trees: let merged_entry() pass through do_add_entry()'s errors
  quote-stress-test: offer to test quoting arguments for MSYS2 sh
  t6130/t9350: prepare for stringent Win32 path validation
  quote-stress-test: allow skipping some trials
  quote-stress-test: accept arguments to test via the command-line
  tests: add a helper to stress test argument quoting
  mingw: fix quoting of arguments
  Disallow dubiously-nested submodule git directories
  protect_ntfs: turn on NTFS protection by default
  path: also guard `.gitmodules` against NTFS Alternate Data Streams
  is_ntfs_dotgit(): speed it up
  mingw: disallow backslash characters in tree objects' file names
  path: safeguard `.git` against NTFS Alternate Streams Accesses
  clone --recurse-submodules: prevent name squatting on Windows
  is_ntfs_dotgit(): only verify the leading segment
  test-path-utils: offer to run a protectNTFS/protectHFS benchmark
  ...
2019-12-06 16:26:55 +01:00
66d2a6159f Git 2.14.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-06 16:26:15 +01:00
2ddcccf97a Merge branch 'win32-accommodate-funny-drive-names'
While the only permitted drive letters for physical drives on Windows
are letters of the US-English alphabet, this restriction does not apply
to virtual drives assigned via `subst <letter>: <path>`.

To prevent targeted attacks against systems where "funny" drive letters
such as `1` or `!` are assigned, let's handle them as regular drive
letters on Windows.

This fixes CVE-2019-1351.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:09 +01:00
65d30a19de Merge branch 'win32-filenames-cannot-have-trailing-spaces-or-periods'
On Windows, filenames cannot have trailing spaces or periods, when
opening such paths, they are stripped automatically. Read: you can open
the file `README` via the file name `README . . .`. This ambiguity can
be used in combination with other security bugs to cause e.g. remote
code execution during recursive clones. This patch series fixes that.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:09 +01:00
5532ebdeb7 Merge branch 'fix-mingw-quoting-bug'
This patch fixes a vulnerability in the Windows-specific code where a
submodule names ending in a backslash were quoted incorrectly, and that
bug could be abused to insert command-line parameters e.g. to `ssh` in a
recursive clone.

Note: this bug is Windows-only, as we have to construct a command line
for the process-to-spawn, unlike Linux/macOS, where `execv()` accepts an
already-split command line.

While at it, other quoting issues are fixed as well.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:08 +01:00
76a681ce9c Merge branch 'dubiously-nested-submodules'
Recursive clones are currently affected by a vulnerability that is
caused by too-lax validation of submodule names.

This topic branch fixes that.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:08 +01:00
dd53ea7220 Merge branch 'turn-on-protectntfs-by-default'
This patch series makes it safe to use Git on Windows drives, even if
running on a mounted network share or within the Windows Subsystem for
Linux (WSL).

This topic branch addresses CVE-2019-1353.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:08 +01:00
f82a97eb91 mingw: handle subst-ed "DOS drives"
Over a decade ago, in 25fe217b86 (Windows: Treat Windows style path
names., 2008-03-05), Git was taught to handle absolute Windows paths,
i.e. paths that start with a drive letter and a colon.

Unbeknownst to us, while drive letters of physical drives are limited to
letters of the English alphabet, there is a way to assign virtual drive
letters to arbitrary directories, via the `subst` command, which is
_not_ limited to English letters.

It is therefore possible to have absolute Windows paths of the form
`1:\what\the\hex.txt`. Even "better": pretty much arbitrary Unicode
letters can also be used, e.g. `ä:\tschibät.sch`.

While it can be sensibly argued that users who set up such funny drive
letters really seek adverse consequences, the Windows Operating System
is known to be a platform where many users are at the mercy of
administrators who have their very own idea of what constitutes a
reasonable setup.

Therefore, let's just make sure that such funny paths are still
considered absolute paths by Git, on Windows.

In addition to Unicode characters, pretty much any character is a valid
drive letter, as far as `subst` is concerned, even `:` and `"` or even a
space character. While it is probably the opposite of smart to use them,
let's safeguard `is_dos_drive_prefix()` against all of them.

Note: `[::1]:repo` is a valid URL, but not a valid path on Windows.
As `[` is now considered a valid drive letter, we need to be very
careful to avoid misinterpreting such a string as valid local path in
`url_is_local_not_ssh()`. To do that, we use the just-introduced
function `is_valid_path()` (which will label the string as invalid file
name because of the colon characters).

This fixes CVE-2019-1351.

Reported-by: Nicolas Joly <Nicolas.Joly@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:07 +01:00
7f3551dd68 Merge branch 'disallow-dotgit-via-ntfs-alternate-data-streams'
This patch series plugs an attack vector we had overlooked in our
December 2014 work on `core.protectNTFS`.

Essentially, the path `.git::$INDEX_ALLOCATION/config` is interpreted as
`.git/config` when NTFS Alternate Data Streams are available (which they
are on Windows, and at least on network shares that are SMB-mounted on
macOS).

Needless to say: we don't want that.

In fact, we want to stay on the very safe side and not even special-case
the `$INDEX_ALLOCATION` stream type: let's just prevent Git from
touching _any_ explicitly specified Alternate Data Stream of `.git`.

In essence, we'll prevent Git from tracking, or writing to, any path
with a segment of the form `.git:<anything>`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:07 +01:00
d2c84dad1c mingw: refuse to access paths with trailing spaces or periods
When creating a directory on Windows whose path ends in a space or a
period (or chains thereof), the Win32 API "helpfully" trims those. For
example, `mkdir("abc ");` will return success, but actually create a
directory called `abc` instead.

This stems back to the DOS days, when all file names had exactly 8
characters plus exactly 3 characters for the file extension, and the
only way to have shorter names was by padding with spaces.

Sadly, this "helpful" behavior is a bit inconsistent: after a successful
`mkdir("abc ");`, a `mkdir("abc /def")` will actually _fail_ (because
the directory `abc ` does not actually exist).

Even if it would work, we now have a serious problem because a Git
repository could contain directories `abc` and `abc `, and on Windows,
they would be "merged" unintentionally.

As these paths are illegal on Windows, anyway, let's disallow any
accesses to such paths on that Operating System.

For practical reasons, this behavior is still guarded by the
config setting `core.protectNTFS`: it is possible (and at least two
regression tests make use of it) to create commits without involving the
worktree. In such a scenario, it is of course possible -- even on
Windows -- to create such file names.

Among other consequences, this patch disallows submodules' paths to end
in spaces on Windows (which would formerly have confused Git enough to
try to write into incorrect paths, anyway).

While this patch does not fix a vulnerability on its own, it prevents an
attack vector that was exploited in demonstrations of a number of
recently-fixed security bugs.

The regression test added to `t/t7417-submodule-path-url.sh` reflects
that attack vector.

Note that we have to adjust the test case "prevent git~1 squatting on
Windows" in `t/t7415-submodule-names.sh` because of a very subtle issue.
It tries to clone two submodules whose names differ only in a trailing
period character, and as a consequence their git directories differ in
the same way. Previously, when Git tried to clone the second submodule,
it thought that the git directory already existed (because on Windows,
when you create a directory with the name `b.` it actually creates `b`),
but with this patch, the first submodule's clone will fail because of
the illegal name of the git directory. Therefore, when cloning the
second submodule, Git will take a different code path: a fresh clone
(without an existing git directory). Both code paths fail to clone the
second submodule, both because the the corresponding worktree directory
exists and is not empty, but the error messages are worded differently.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:06 +01:00
379e51d1ae quote-stress-test: offer to test quoting arguments for MSYS2 sh
It is unfortunate that we need to quote arguments differently on
Windows, depending whether we build a command-line for MSYS2's `sh` or
for other Windows executables.

We already have a test helper to verify the latter, with this patch we
can also verify the former.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:06 +01:00
817ddd64c2 mingw: refuse to access paths with illegal characters
Certain characters are not admissible in file names on Windows, even if
Cygwin/MSYS2 (and therefore, Git for Windows' Bash) pretend that they
are, e.g. `:`, `<`, `>`, etc

Let's disallow those characters explicitly in Windows builds of Git.

Note: just like trailing spaces or periods, it _is_ possible on Windows
to create commits adding files with such illegal characters, as long as
the operation leaves the worktree untouched. To allow for that, we
continue to guard `is_valid_win32_path()` behind the config setting
`core.protectNTFS`, so that users _can_ continue to do that, as long as
they turn the protections off via that config setting.

Among other problems, this prevents Git from trying to write to an "NTFS
Alternate Data Stream" (which refers to metadata stored alongside a
file, under a special name: "<filename>:<stream-name>"). This fix
therefore also prevents an attack vector that was exploited in
demonstrations of a number of recently-fixed security bugs.

Further reading on illegal characters in Win32 filenames:
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:06 +01:00
cc756edda6 unpack-trees: let merged_entry() pass through do_add_entry()'s errors
A `git clone` will end with exit code 0 when `merged_entry()` returns a
positive value during a call of `unpack_trees()` to `traverse_trees()`.
The reason is that `unpack_trees()` will interpret a positive value not
to be an error.

The problem is, however, that `add_index_entry()` (which is called by
`merged_entry()` can report an error, and we really should fail the
entire clone in such a case.

Let's fix this problem, in preparation for a Windows-specific patch
disallowing `mkdir()` with directory names that contain a trailing space
(which is illegal on NTFS): we want `git clone` to abort when a path
cannot be checked out due to that condition.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:06 +01:00
7530a6287e quote-stress-test: allow skipping some trials
When the, say, 93rd trial run fails, it is a good idea to have a way to
skip the first 92 trials and dig directly into the 93rd in a debugger.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:06 +01:00
35edce2056 t6130/t9350: prepare for stringent Win32 path validation
On Windows, file names cannot contain asterisks nor newline characters.
In an upcoming commit, we will make this limitation explicit,
disallowing even the creation of commits that introduce such file names.

However, in the test scripts touched by this patch, we _know_ that those
paths won't be checked out, so we _want_ to allow such file names.

Happily, the stringent path validation will be guarded via the
`core.protectNTFS` flag, so all we need to do is to force that flag off
temporarily.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:37:06 +01:00
55953c77c0 quote-stress-test: accept arguments to test via the command-line
When the stress test reported a problem with quoting certain arguments,
it is helpful to have a facility to play with those arguments in order
to find out whether variations of those arguments are affected, too.

Let's allow `test-run-command quote-stress-test -- <args>` to be used
for that purpose.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:36:53 +01:00
ad15592529 tests: add a helper to stress test argument quoting
On Windows, we have to do all the command-line argument quoting
ourselves. Worse: we have to have two versions of said quoting, one for
MSYS2 programs (which have their own dequoting rules) and the rest.

We care mostly about the rest, and to make sure that that works, let's
have a stress test that comes up with all kinds of awkward arguments,
verifying that a spawned sub-process receives those unharmed.

Signed-off-by: Garima Singh <garima.singh@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:36:52 +01:00
a8dee3ca61 Disallow dubiously-nested submodule git directories
Currently it is technically possible to let a submodule's git
directory point right into the git dir of a sibling submodule.

Example: the git directories of two submodules with the names `hippo`
and `hippo/hooks` would be `.git/modules/hippo/` and
`.git/modules/hippo/hooks/`, respectively, but the latter is already
intended to house the former's hooks.

In most cases, this is just confusing, but there is also a (quite
contrived) attack vector where Git can be fooled into mistaking remote
content for file contents it wrote itself during a recursive clone.

Let's plug this bug.

To do so, we introduce the new function `validate_submodule_git_dir()`
which simply verifies that no git dir exists for any leading directories
of the submodule name (if there are any).

Note: this patch specifically continues to allow sibling modules names
of the form `core/lib`, `core/doc`, etc, as long as `core` is not a
submodule name.

This fixes CVE-2019-1387.

Reported-by: Nicolas Joly <Nicolas.Joly@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:36:51 +01:00
9102f958ee protect_ntfs: turn on NTFS protection by default
Back in the DOS days, in the FAT file system, file names always
consisted of a base name of length 8 plus a file extension of length 3.
Shorter file names were simply padded with spaces to the full 8.3
format.

Later, the FAT file system was taught to support _also_ longer names,
with an 8.3 "short name" as primary file name. While at it, the same
facility allowed formerly illegal file names, such as `.git` (empty base
names were not allowed), which would have the "short name" `git~1`
associated with it.

For backwards-compatibility, NTFS supports alternative 8.3 short
filenames, too, even if starting with Windows Vista, they are only
generated on the system drive by default.

We addressed the problem that the `.git/` directory can _also_ be
accessed via `git~1/` (when short names are enabled) in 2b4c6efc82
(read-cache: optionally disallow NTFS .git variants, 2014-12-16), i.e.
since Git v1.9.5, by introducing the config setting `core.protectNTFS`
and enabling it by default on Windows.

In the meantime, Windows 10 introduced the "Windows Subsystem for Linux"
(short: WSL), i.e. a way to run Linux applications/distributions in a
thinly-isolated subsystem on Windows (giving rise to many a "2016 is the
Year of Linux on the Desktop" jokes). WSL is getting increasingly
popular, also due to the painless way Linux application can operate
directly ("natively") on files on Windows' file system: the Windows
drives are mounted automatically (e.g. `C:` as `/mnt/c/`).

Taken together, this means that we now have to enable the safe-guards of
Git v1.9.5 also in WSL: it is possible to access a `.git` directory
inside `/mnt/c/` via the 8.3 name `git~1` (unless short name generation
was disabled manually). Since regular Linux distributions run in WSL,
this means we have to enable `core.protectNTFS` at least on Linux, too.

To enable Services for Macintosh in Windows NT to store so-called
resource forks, NTFS introduced "Alternate Data Streams". Essentially,
these constitute additional metadata that are connected to (and copied
with) their associated files, and they are accessed via pseudo file
names of the form `filename:<stream-name>:<stream-type>`.

In a recent patch, we extended `core.protectNTFS` to also protect
against accesses via NTFS Alternate Data Streams, e.g. to prevent
contents of the `.git/` directory to be "tracked" via yet another
alternative file name.

While it is not possible (at least by default) to access files via NTFS
Alternate Data Streams from within WSL, the defaults on macOS when
mounting network shares via SMB _do_ allow accessing files and
directories in that way. Therefore, we need to enable `core.protectNTFS`
on macOS by default, too, and really, on any Operating System that can
mount network shares via SMB/CIFS.

A couple of approaches were considered for fixing this:

1. We could perform a dynamic NTFS check similar to the `core.symlinks`
   check in `init`/`clone`: instead of trying to create a symbolic link
   in the `.git/` directory, we could create a test file and try to
   access `.git/config` via 8.3 name and/or Alternate Data Stream.

2. We could simply "flip the switch" on `core.protectNTFS`, to make it
   "on by default".

The obvious downside of 1. is that it won't protect worktrees that were
clone with a vulnerable Git version already. We considered patching code
paths that check out files to check whether we're running on an NTFS
system dynamically and persist the result in the repository-local config
setting `core.protectNTFS`, but in the end decided that this solution
would be too fragile, and too involved.

The obvious downside of 2. is that everybody will have to "suffer" the
performance penalty incurred from calling `is_ntfs_dotgit()` on every
path, even in setups where.

After the recent work to accelerate `is_ntfs_dotgit()` in most cases,
it looks as if the time spent on validating ten million random
file names increases only negligibly (less than 20ms, well within the
standard deviation of ~50ms). Therefore the benefits outweigh the cost.

Another downside of this is that paths that might have been acceptable
previously now will be forbidden. Realistically, though, this is an
improvement because public Git hosters already would reject any `git
push` that contains such file names.

Note: There might be a similar problem mounting HFS+ on Linux. However,
this scenario has been considered unlikely and in light of the cost (in
the aforementioned benchmark, `core.protectHFS = true` increased the
time from ~440ms to ~610ms), it was decided _not_ to touch the default
of `core.protectHFS`.

This change addresses CVE-2019-1353.

Reported-by: Nicolas Joly <Nicolas.Joly@microsoft.com>
Helped-by: Garima Singh <garima.singh@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:36:51 +01:00
91bd46588e path: also guard .gitmodules against NTFS Alternate Data Streams
We just safe-guarded `.git` against NTFS Alternate Data Stream-related
attack vectors, and now it is time to do the same for `.gitmodules`.

Note: In the added regression test, we refrain from verifying all kinds
of variations between short names and NTFS Alternate Data Streams: as
the new code disallows _all_ Alternate Data Streams of `.gitmodules`, it
is enough to test one in order to know that all of them are guarded
against.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:36:51 +01:00
6d8684161e mingw: fix quoting of arguments
We need to be careful to follow proper quoting rules. For example, if an
argument contains spaces, we have to quote them. Double-quotes need to
be escaped. Backslashes need to be escaped, but only if they are
followed by a double-quote character.

We need to be _extra_ careful to consider the case where an argument
ends in a backslash _and_ needs to be quoted: in this case, we append a
double-quote character, i.e. the backslash now has to be escaped!

The current code, however, fails to recognize that, and therefore can
turn an argument that ends in a single backslash into a quoted argument
that now ends in an escaped double-quote character. This allows
subsequent command-line parameters to be split and part of them being
mistaken for command-line options, e.g. through a maliciously-crafted
submodule URL during a recursive clone.

Technically, we would not need to quote _all_ arguments which end in a
backslash _unless_ the argument needs to be quoted anyway. For example,
`test\` would not need to be quoted, while `test \` would need to be.

To keep the code simple, however, and therefore easier to reason about
and ensure its correctness, we now _always_ quote an argument that ends
in a backslash.

This addresses CVE-2019-1350.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:36:51 +01:00
3a85dc7d53 is_ntfs_dotgit(): speed it up
Previously, this function was written without focusing on speed,
intending to make reviewing the code as easy as possible, to avoid any
bugs in this critical code.

Turns out: we can do much better on both accounts. With this patch, we
make it as fast as this developer can make it go:

- We avoid the call to `is_dir_sep()` and make all the character
  comparisons explicit.

- We avoid the cost of calling `strncasecmp()` and unroll the test for
  `.git` and `git~1`, not even using `tolower()` because it is faster to
  compare against two constant values.

- We look for `.git` and `.git~1` first thing, and return early if not
  found.

- We also avoid calling a separate function for detecting chains of
  spaces and periods.

Each of these improvements has a noticeable impact on the speed of
`is_ntfs_dotgit()`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:36:51 +01:00
7c3745fc61 path: safeguard .git against NTFS Alternate Streams Accesses
Probably inspired by HFS' resource streams, NTFS supports "Alternate
Data Streams": by appending `:<stream-name>` to the file name,
information in addition to the file contents can be written and read,
information that is copied together with the file (unless copied to a
non-NTFS location).

These Alternate Data Streams are typically used for things like marking
an executable as having just been downloaded from the internet (and
hence not necessarily being trustworthy).

In addition to a stream name, a stream type can be appended, like so:
`:<stream-name>:<stream-type>`. Unless specified, the default stream
type is `$DATA` for files and `$INDEX_ALLOCATION` for directories. In
other words, `.git::$INDEX_ALLOCATION` is a valid way to reference the
`.git` directory!

In our work in Git v2.2.1 to protect Git on NTFS drives under
`core.protectNTFS`, we focused exclusively on NTFS short names, unaware
of the fact that NTFS Alternate Data Streams offer a similar attack
vector.

Let's fix this.

Seeing as it is better to be safe than sorry, we simply disallow paths
referring to *any* NTFS Alternate Data Stream of `.git`, not just
`::$INDEX_ALLOCATION`. This also simplifies the implementation.

This closes CVE-2019-1352.

Further reading about NTFS Alternate Data Streams:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c54dec26-1551-4d3a-a0ea-4fa40f848eb3

Reported-by: Nicolas Joly <Nicolas.Joly@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:36:50 +01:00
288a74bcd2 is_ntfs_dotgit(): only verify the leading segment
The config setting `core.protectNTFS` is specifically designed to work
not only on Windows, but anywhere, to allow for repositories hosted on,
say, Linux servers to be protected against NTFS-specific attack vectors.

As a consequence, `is_ntfs_dotgit()` manually splits backslash-separated
paths (but does not do the same for paths separated by forward slashes),
under the assumption that the backslash might not be a valid directory
separator on the _current_ Operating System.

However, the two callers, `verify_path()` and `fsck_tree()`, are
supposed to feed only individual path segments to the `is_ntfs_dotgit()`
function.

This causes a lot of duplicate scanning (and very inefficient scanning,
too, as the inner loop of `is_ntfs_dotgit()` was optimized for
readability rather than for speed.

Let's simplify the design of `is_ntfs_dotgit()` by putting the burden of
splitting the paths by backslashes as directory separators on the
callers of said function.

Consequently, the `verify_path()` function, which already splits the
path by directory separators, now treats backslashes as directory
separators _explicitly_ when `core.protectNTFS` is turned on, even on
platforms where the backslash is _not_ a directory separator.

Note that we have to repeat some code in `verify_path()`: if the
backslash is not a directory separator on the current Operating System,
we want to allow file names like `\`, but we _do_ want to disallow paths
that are clearly intended to cause harm when the repository is cloned on
Windows.

The `fsck_tree()` function (the other caller of `is_ntfs_dotgit()`) now
needs to look for backslashes in tree entries' names specifically when
`core.protectNTFS` is turned on. While it would be tempting to
completely disallow backslashes in that case (much like `fsck` reports
names containing forward slashes as "full paths"), this would be
overzealous: when `core.protectNTFS` is turned on in a non-Windows
setup, backslashes are perfectly valid characters in file names while we
_still_ want to disallow tree entries that are clearly designed to
exploit NTFS-specific behavior.

This simplification will make subsequent changes easier to implement,
such as turning `core.protectNTFS` on by default (not only on Windows)
or protecting against attack vectors involving NTFS Alternate Data
Streams.

Incidentally, this change allows for catching malicious repositories
that contain tree entries of the form `dir\.gitmodules` already on the
server side rather than only on the client side (and previously only on
Windows): in contrast to `is_ntfs_dotgit()`, the
`is_ntfs_dotgitmodules()` function already expects the caller to split
the paths by directory separators.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:36:50 +01:00
a62f9d1ace test-path-utils: offer to run a protectNTFS/protectHFS benchmark
In preparation to flipping the default on `core.protectNTFS`, let's have
some way to measure the speed impact of this config setting reliably
(and for comparison, the `core.protectHFS` config setting).

For now, this is a manual performance benchmark:

	./t/helper/test-path-utils protect_ntfs_hfs [arguments...]

where the arguments are an optional number of file names to test with,
optionally followed by minimum and maximum length of the random file
names. The default values are one million, 3 and 20, respectively.

Just like `sqrti()` in `bisect.c`, we introduce a very simple function
to approximation the square root of a given value, in order to avoid
having to introduce the first user of `<math.h>` in Git's source code.

Note: this is _not_ implemented as a Unix shell script in t/perf/
because we really care about _very_ precise timings here, and Unix shell
scripts are simply unsuited for precise and consistent benchmarking.

Signed-off-by: Garima Singh <garima.singh@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-05 15:36:40 +01:00
4778452597 Merge branch 'prevent-name-squatting-on-windows'
This patch series fixes an issue where Git could formerly have been
tricked into creating a `.git` file with an unexpected (and therefore
unprotected) NTFS short name.

Incidentally, it also fixes an issue where a tree entry containing a
backslash could be tricked into following a symbolic link, i.e. Git
could be tricked into writing files outside the worktree.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-04 13:23:22 +01:00
a7b1ad3b05 Merge branch 'jk/fast-import-unsafe'
The `--export-marks` option of `git fast-import` is exposed also via the
in-stream command `feature export-marks=...` and it allows overwriting
arbitrary paths.

This topic branch prevents the in-stream version, to prevent arbitrary
file accesses by `git fast-import` streams coming from untrusted sources
(e.g. in remote helpers that are based on `git fast-import`).

This fixes CVE-2019-1348.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-04 13:23:22 +01:00
525e7fba78 path.c: document the purpose of is_ntfs_dotgit()
Previously, this function was completely undocumented. It is worth,
though, to explain what is going on, as it is not really obvious at all.

Suggested-by: Garima Singh <garima.singh@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-04 13:20:05 +01:00
e1d911dd4c mingw: disallow backslash characters in tree objects' file names
The backslash character is not a valid part of a file name on Windows.
Hence it is dangerous to allow writing files that were unpacked from
tree objects, when the stored file name contains a backslash character:
it will be misinterpreted as directory separator.

This not only causes ambiguity when a tree contains a blob `a\b` and a
tree `a` that contains a blob `b`, but it also can be used as part of an
attack vector to side-step the careful protections against writing into
the `.git/` directory during a clone of a maliciously-crafted
repository.

Let's prevent that, addressing CVE-2019-1354.

Note: we guard against backslash characters in tree objects' file names
_only_ on Windows (because on other platforms, even on those where NTFS
volumes can be mounted, the backslash character is _not_ a directory
separator), and _only_ when `core.protectNTFS = true` (because users
might need to generate tree objects for other platforms, of course
without touching the worktree, e.g. using `git update-index
--cacheinfo`).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-04 13:20:05 +01:00
0060fd1511 clone --recurse-submodules: prevent name squatting on Windows
In addition to preventing `.git` from being tracked by Git, on Windows
we also have to prevent `git~1` from being tracked, as the default NTFS
short name (also known as the "8.3 filename") for the file name `.git`
is `git~1`, otherwise it would be possible for malicious repositories to
write directly into the `.git/` directory, e.g. a `post-checkout` hook
that would then be executed _during_ a recursive clone.

When we implemented appropriate protections in 2b4c6efc82 (read-cache:
optionally disallow NTFS .git variants, 2014-12-16), we had analyzed
carefully that the `.git` directory or file would be guaranteed to be
the first directory entry to be written. Otherwise it would be possible
e.g. for a file named `..git` to be assigned the short name `git~1` and
subsequently, the short name generated for `.git` would be `git~2`. Or
`git~3`. Or even `~9999999` (for a detailed explanation of the lengths
we have to go to protect `.gitmodules`, see the commit message of
e7cb0b4455 (is_ntfs_dotgit: match other .git files, 2018-05-11)).

However, by exploiting two issues (that will be addressed in a related
patch series close by), it is currently possible to clone a submodule
into a non-empty directory:

- On Windows, file names cannot end in a space or a period (for
  historical reasons: the period separating the base name from the file
  extension was not actually written to disk, and the base name/file
  extension was space-padded to the full 8/3 characters, respectively).
  Helpfully, when creating a directory under the name, say, `sub.`, that
  trailing period is trimmed automatically and the actual name on disk
  is `sub`.

  This means that while Git thinks that the submodule names `sub` and
  `sub.` are different, they both access `.git/modules/sub/`.

- While the backslash character is a valid file name character on Linux,
  it is not so on Windows. As Git tries to be cross-platform, it
  therefore allows backslash characters in the file names stored in tree
  objects.

  Which means that it is totally possible that a submodule `c` sits next
  to a file `c\..git`, and on Windows, during recursive clone a file
  called `..git` will be written into `c/`, of course _before_ the
  submodule is cloned.

Note that the actual exploit is not quite as simple as having a
submodule `c` next to a file `c\..git`, as we have to make sure that the
directory `.git/modules/b` already exists when the submodule is checked
out, otherwise a different code path is taken in `module_clone()` that
does _not_ allow a non-empty submodule directory to exist already.

Even if we will address both issues nearby (the next commit will
disallow backslash characters in tree entries' file names on Windows,
and another patch will disallow creating directories/files with trailing
spaces or periods), it is a wise idea to defend in depth against this
sort of attack vector: when submodules are cloned recursively, we now
_require_ the directory to be empty, addressing CVE-2019-1349.

Note: the code path we patch is shared with the code path of `git
submodule update --init`, which must not expect, in general, that the
directory is empty. Hence we have to introduce the new option
`--force-init` and hand it all the way down from `git submodule` to the
actual `git submodule--helper` process that performs the initial clone.

Reported-by: Nicolas Joly <Nicolas.Joly@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-12-04 13:20:05 +01:00
a52ed76142 fast-import: disallow "feature import-marks" by default
As with export-marks in the previous commit, import-marks can access the
filesystem. This is significantly less dangerous than export-marks
because it only involves reading from arbitrary paths, rather than
writing them. However, it could still be surprising and have security
implications (e.g., exfiltrating data from a service that accepts
fast-import streams).

Let's lump it (and its "if-exists" counterpart) in with export-marks,
and enable the in-stream version only if --allow-unsafe-features is set.

Signed-off-by: Jeff King <peff@peff.net>
2019-12-04 13:20:04 +01:00
68061e3470 fast-import: disallow "feature export-marks" by default
The fast-import stream command "feature export-marks=<path>" lets the
stream write marks to an arbitrary path. This may be surprising if you
are running fast-import against an untrusted input (which otherwise
cannot do anything except update Git objects and refs).

Let's disallow the use of this feature by default, and provide a
command-line option to re-enable it (you can always just use the
command-line --export-marks as well, but the in-stream version provides
an easy way for exporters to control the process).

This is a backwards-incompatible change, since the default is flipping
to the new, safer behavior. However, since the main users of the
in-stream versions would be import/export-based remote helpers, and
since we trust remote helpers already (which are already running
arbitrary code), we'll pass the new option by default when reading a
remote helper's stream. This should minimize the impact.

Note that the implementation isn't totally simple, as we have to work
around the fact that fast-import doesn't parse its command-line options
until after it has read any "feature" lines from the stream. This is how
it lets command-line options override in-stream. But in our case, it's
important to parse the new --allow-unsafe-features first.

There are three options for resolving this:

  1. Do a separate "early" pass over the options. This is easy for us to
     do because there are no command-line options that allow the
     "unstuck" form (so there's no chance of us mistaking an argument
     for an option), though it does introduce a risk of incorrect
     parsing later (e.g,. if we convert to parse-options).

  2. Move the option parsing phase back to the start of the program, but
     teach the stream-reading code never to override an existing value.
     This is tricky, because stream "feature" lines override each other
     (meaning we'd have to start tracking the source for every option).

  3. Accept that we might parse a "feature export-marks" line that is
     forbidden, as long we don't _act_ on it until after we've parsed
     the command line options.

     This would, in fact, work with the current code, but only because
     the previous patch fixed the export-marks parser to avoid touching
     the filesystem.

     So while it works, it does carry risk of somebody getting it wrong
     in the future in a rather subtle and unsafe way.

I've gone with option (1) here as simple, safe, and unlikely to cause
regressions.

This fixes CVE-2019-1348.

Signed-off-by: Jeff King <peff@peff.net>
2019-12-04 13:20:04 +01:00
019683025f fast-import: delay creating leading directories for export-marks
When we parse the --export-marks option, we don't immediately open the
file, but we do create any leading directories. This can be especially
confusing when a command-line option overrides an in-stream one, in
which case we'd create the leading directory for the in-stream file,
even though we never actually write the file.

Let's instead create the directories just before opening the file, which
means we'll create only useful directories. Note that this could change
the handling of relative paths if we chdir() in between, but we don't
actually do so; the only permanent chdir is from setup_git_directory()
which runs before either code path (potentially we should take the
pre-setup dir into account to avoid surprising the user, but that's an
orthogonal change).

The test just adapts the existing "override" test to use paths with
leading directories. This checks both that the correct directory is
created (which worked before but was not tested), and that the
overridden one is not (our new fix here).

While we're here, let's also check the error result of
safe_create_leading_directories(). We'd presumably notice any failure
immediately after when we try to open the file itself, but we can give a
more specific error message in this case.

Signed-off-by: Jeff King <peff@peff.net>
2019-12-04 13:20:04 +01:00
e075dba372 fast-import: stop creating leading directories for import-marks
When asked to import marks from "subdir/file.marks", we create the
leading directory "subdir" if it doesn't exist. This makes no sense for
importing marks, where we only ever open the path for reading.

Most of the time this would be a noop, since if the marks file exists,
then the leading directories exist, too. But if it doesn't (e.g.,
because --import-marks-if-exists was used), then we'd create the useless
directory.

This dates back to 580d5f83e7 (fast-import: always create marks_file
directories, 2010-03-29). Even then it was useless, so it seems to have
been added in error alongside the --export-marks case (which _is_
helpful).

Signed-off-by: Jeff King <peff@peff.net>
2019-12-04 13:20:04 +01:00
11e934d56e fast-import: tighten parsing of boolean command line options
We parse options like "--max-pack-size=" using skip_prefix(), which
makes sense to get at the bytes after the "=". However, we also parse
"--quiet" and "--stats" with skip_prefix(), which allows things like
"--quiet-nonsense" to behave like "--quiet".

This was a mistaken conversion in 0f6927c229 (fast-import: put option
parsing code in separate functions, 2009-12-04). Let's tighten this to
an exact match, which was the original intent.

Signed-off-by: Jeff King <peff@peff.net>
2019-12-04 13:20:04 +01:00
816f806786 t9300: create marks files for double-import-marks test
Our tests confirm that providing two "import-marks" options in a
fast-import stream is an error. However, the invoked command would fail
even without covering this case, because the marks files themselves do
not actually exist.  Let's create the files to make sure we fail for the
right reason (we actually do, because the option parsing happens before
we open anything, but this future-proofs our test).

Signed-off-by: Jeff King <peff@peff.net>
2019-12-04 13:20:03 +01:00
f94804c1f2 t9300: drop some useless uses of cat
These waste a process, and make the line longer than it needs to be.

Signed-off-by: Jeff King <peff@peff.net>
2019-12-04 13:20:03 +01:00
840 changed files with 50634 additions and 84066 deletions

View File

@ -148,21 +148,8 @@ SpacesInSquareBrackets: false
Cpp11BracedListStyle: false
# A list of macros that should be interpreted as foreach loops instead of as
# function calls. Taken from:
# git grep -h '^#define [^[:space:]]*for_each[^[:space:]]*(' \
# | sed "s,^#define \([^[:space:]]*for_each[^[:space:]]*\)(.*$, - '\1'," \
# | sort | uniq
ForEachMacros:
- 'for_each_abbrev'
- 'for_each_builtin'
- 'for_each_string_list_item'
- 'for_each_ut'
- 'for_each_wanted_builtin'
- 'list_for_each'
- 'list_for_each_dir'
- 'list_for_each_prev'
- 'list_for_each_prev_safe'
- 'list_for_each_safe'
# function calls.
ForEachMacros: ['for_each_string_list_item']
# The maximum number of consecutive empty lines to keep.
MaxEmptyLinesToKeep: 1

1
.gitattributes vendored
View File

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

View File

@ -5,7 +5,7 @@ Git community does not use github.com for their contributions. Instead, we use
a mailing list (git@vger.kernel.org) for code submissions, code
reviews, and bug reports.
Nevertheless, you can use [GitGitGadget](https://gitgitgadget.github.io/) to
Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to
conveniently send your Pull Requests commits to our mailing list.
Please read ["A note from the maintainer"](https://git.kernel.org/pub/scm/git/git.git/plain/MaintNotes?h=todo)

View File

@ -1,7 +1,7 @@
Thanks for taking the time to contribute to Git! Please be advised that the
Git community does not use github.com for their contributions. Instead, we use
a mailing list (git@vger.kernel.org) for code submissions, code reviews, and
bug reports. Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/)
to conveniently send your Pull Requests commits to our mailing list.
bug reports. Nevertheless, you can use submitGit to conveniently send your Pull
Requests commits to our mailing list.
Please read the "guidelines for contributing" linked above!

14
.gitignore vendored
View File

@ -58,7 +58,6 @@
/git-difftool
/git-difftool--helper
/git-describe
/git-env--helper
/git-fast-export
/git-fast-import
/git-fetch
@ -83,7 +82,7 @@
/git-init-db
/git-interpret-trailers
/git-instaweb
/git-legacy-stash
/git-legacy-rebase
/git-log
/git-ls-files
/git-ls-remote
@ -123,6 +122,9 @@
/git-range-diff
/git-read-tree
/git-rebase
/git-rebase--am
/git-rebase--common
/git-rebase--interactive
/git-rebase--preserve-merges
/git-receive-pack
/git-reflog
@ -133,6 +135,7 @@
/git-remote-ftps
/git-remote-fd
/git-remote-ext
/git-remote-testgit
/git-remote-testpy
/git-remote-testsvn
/git-repack
@ -140,7 +143,6 @@
/git-request-pull
/git-rerere
/git-reset
/git-restore
/git-rev-list
/git-rev-parse
/git-revert
@ -165,7 +167,6 @@
/git-submodule
/git-submodule--helper
/git-svn
/git-switch
/git-symbolic-ref
/git-tag
/git-unpack-file
@ -226,11 +227,6 @@
*.user
*.idb
*.pdb
*.ilk
*.iobj
*.ipdb
*.dll
.vs/
/Debug/
/Release/
*.dSYM

View File

@ -21,10 +21,16 @@ matrix:
compiler:
addons:
before_install:
- env: jobname=linux-gcc-4.8
- env: jobname=Windows
os: linux
dist: trusty
compiler:
addons:
before_install:
script:
- >
test "$TRAVIS_REPO_SLUG" != "git/git" ||
ci/run-windows-build.sh $TRAVIS_BRANCH $(git rev-parse HEAD)
after_failure:
- env: jobname=Linux32
os: linux
compiler:

View File

@ -13,5 +13,3 @@ mergetools-*.txt
manpage-base-url.xsl
SubmittingPatches.txt
tmp-doc-diff/
GIT-ASCIIDOCFLAGS
/GIT-EXCLUDED-PROGRAMS

View File

@ -195,30 +195,10 @@ For C programs:
by e.g. "echo DEVELOPER=1 >>config.mak".
- We try to support a wide range of C compilers to compile Git with,
including old ones. You should not use features from newer C
standard, even if your compiler groks them.
including old ones. That means that you should not use C99
initializers, even if a lot of compilers grok it.
There are a few exceptions to this guideline:
. since early 2012 with e1327023ea, we have been using an enum
definition whose last element is followed by a comma. This, like
an array initializer that ends with a trailing comma, can be used
to reduce the patch noise when adding a new identifer at the end.
. since mid 2017 with cbc0f81d, we have been using designated
initializers for struct (e.g. "struct t v = { .val = 'a' };").
. since mid 2017 with 512f41cf, we have been using designated
initializers for array (e.g. "int array[10] = { [5] = 2 }").
These used to be forbidden, but we have not heard any breakage
report, and they are assumed to be safe.
- Variables have to be declared at the beginning of the block, before
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.
- Variables have to be declared at the beginning of the block.
- NULL pointers shall be written as NULL, not as 0.
@ -432,12 +412,6 @@ For C programs:
must be declared with "extern" in header files. However, function
declarations should not use "extern", as that is already the default.
- You can launch gdb around your program using the shorthand GIT_DEBUGGER.
Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
For Perl programs:
- Most of the C guidelines above apply.
@ -606,14 +580,11 @@ Writing Documentation:
or commands:
Literal examples (e.g. use of command-line options, command names,
branch names, URLs, pathnames (files and directories), configuration and
environment variables) must be typeset in monospace (i.e. wrapped with
backticks):
branch names, configuration and environment variables) must be
typeset in monospace (i.e. wrapped with backticks):
`--pretty=oneline`
`git rev-list`
`remote.pushDefault`
`http://git.example.com`
`.git/config`
`GIT_DIR`
`HEAD`

View File

@ -7,14 +7,12 @@ ARTICLES =
SP_ARTICLES =
OBSOLETE_HTML =
-include GIT-EXCLUDED-PROGRAMS
MAN1_TXT += $(filter-out \
$(patsubst %,%.txt,$(EXCLUDED_PROGRAMS)) \
$(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt))
MAN1_TXT += git.txt
MAN1_TXT += gitk.txt
MAN1_TXT += gitremote-helpers.txt
MAN1_TXT += gitweb.txt
MAN5_TXT += gitattributes.txt
@ -32,7 +30,6 @@ MAN7_TXT += gitdiffcore.txt
MAN7_TXT += giteveryday.txt
MAN7_TXT += gitglossary.txt
MAN7_TXT += gitnamespaces.txt
MAN7_TXT += gitremote-helpers.txt
MAN7_TXT += gitrevisions.txt
MAN7_TXT += gitsubmodules.txt
MAN7_TXT += gittutorial-2.txt
@ -76,7 +73,6 @@ SP_ARTICLES += howto/maintain-git
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 += MyFirstContribution
TECH_DOCS += SubmittingPatches
TECH_DOCS += technical/hash-function-transition
TECH_DOCS += technical/http-protocol
@ -335,15 +331,6 @@ mergetools-list.made: ../git-mergetool--lib.sh $(wildcard ../mergetools/*)
show_tool_names can_merge "* " || :' >mergetools-merge.txt && \
date >$@
TRACK_ASCIIDOCFLAGS = $(subst ','\'',$(ASCIIDOC_COMMON):$(ASCIIDOC_HTML):$(ASCIIDOC_DOCBOOK))
GIT-ASCIIDOCFLAGS: FORCE
@FLAGS='$(TRACK_ASCIIDOCFLAGS)'; \
if test x"$$FLAGS" != x"`cat GIT-ASCIIDOCFLAGS 2>/dev/null`" ; then \
echo >&2 " * new asciidoc flags"; \
echo "$$FLAGS" >GIT-ASCIIDOCFLAGS; \
fi
clean:
$(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7
$(RM) *.texi *.texi+ *.texi++ git.info gitman.info
@ -353,14 +340,13 @@ clean:
$(RM) SubmittingPatches.txt
$(RM) $(cmds_txt) $(mergetools_txt) *.made
$(RM) manpage-base-url.xsl
$(RM) GIT-ASCIIDOCFLAGS
$(MAN_HTML): %.html : %.txt asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS
$(MAN_HTML): %.html : %.txt asciidoc.conf
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(TXT_TO_HTML) -d manpage -o $@+ $< && \
mv $@+ $@
$(OBSOLETE_HTML): %.html : %.txto asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS
$(OBSOLETE_HTML): %.html : %.txto asciidoc.conf
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(TXT_TO_HTML) -o $@+ $< && \
mv $@+ $@
@ -368,16 +354,16 @@ $(OBSOLETE_HTML): %.html : %.txto asciidoc.conf asciidoctor-extensions.rb GIT-AS
manpage-base-url.xsl: manpage-base-url.xsl.in
$(QUIET_GEN)sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@
%.1 %.5 %.7 : %.xml manpage-base-url.xsl $(wildcard manpage*.xsl)
%.1 %.5 %.7 : %.xml manpage-base-url.xsl
$(QUIET_XMLTO)$(RM) $@ && \
$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<
%.xml : %.txt asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS
%.xml : %.txt asciidoc.conf
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(TXT_TO_XML) -d manpage -o $@+ $< && \
mv $@+ $@
user-manual.xml: user-manual.txt user-manual.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS
user-manual.xml: user-manual.txt user-manual.conf
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(TXT_TO_XML) -d book -o $@+ $< && \
mv $@+ $@
@ -387,8 +373,7 @@ technical/api-index.txt: technical/api-index-skel.txt \
$(QUIET_GEN)cd technical && '$(SHELL_PATH_SQ)' ./api-index.sh
technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../
$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt \
asciidoc.conf GIT-ASCIIDOCFLAGS
$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt asciidoc.conf
$(QUIET_ASCIIDOC)$(TXT_TO_HTML) $*.txt
SubmittingPatches.txt: SubmittingPatches
@ -445,7 +430,7 @@ $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
WEBDOC_DEST = /pub/software/scm/git/docs
howto/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../
$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt GIT-ASCIIDOCFLAGS
$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
sed -e '1,/^$$/d' $< | \
$(TXT_TO_HTML) - >$@+ && \

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,54 @@
Git v2.14.6 Release Notes
=========================
This release addresses the security issues CVE-2019-1348,
CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387.
Fixes since v2.14.5
-------------------
* CVE-2019-1348:
The --export-marks option of git fast-import is exposed also via
the in-stream command feature export-marks=... and it allows
overwriting arbitrary paths.
* CVE-2019-1349:
When submodules are cloned recursively, under certain circumstances
Git could be fooled into using the same Git directory twice. We now
require the directory to be empty.
* CVE-2019-1350:
Incorrect quoting of command-line arguments allowed remote code
execution during a recursive clone in conjunction with SSH URLs.
* CVE-2019-1351:
While the only permitted drive letters for physical drives on
Windows are letters of the US-English alphabet, this restriction
does not apply to virtual drives assigned via subst <letter>:
<path>. Git mistook such paths for relative paths, allowing writing
outside of the worktree while cloning.
* CVE-2019-1352:
Git was unaware of NTFS Alternate Data Streams, allowing files
inside the .git/ directory to be overwritten during a clone.
* CVE-2019-1353:
When running Git in the Windows Subsystem for Linux (also known as
"WSL") while accessing a working directory on a regular Windows
drive, none of the NTFS protections were active.
* CVE-2019-1354:
Filenames on Linux/Unix can contain backslashes. On Windows,
backslashes are directory separators. Git did not use to refuse to
write out tracked files with such filenames.
* CVE-2019-1387:
Recursive clones are currently affected by a vulnerability that is
caused by too-lax validation of submodule names, allowing very
targeted attacks via remote code execution in recursive clones.
Credit for finding these vulnerabilities goes to Microsoft Security
Response Center, in particular to Nicolas Joly. The `fast-import`
fixes were provided by Jeff King, the other fixes by Johannes
Schindelin with help from Garima Singh.

View File

@ -0,0 +1,11 @@
Git v2.15.4 Release Notes
=========================
This release merges up the fixes that appear in v2.14.6 to address
the security issues CVE-2019-1348, CVE-2019-1349, CVE-2019-1350,
CVE-2019-1351, CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, and
CVE-2019-1387; see the release notes for that version for details.
In conjunction with a vulnerability that was fixed in v2.20.2,
`.gitmodules` is no longer allowed to contain entries of the form
`submodule.<name>.update=!command`.

View File

@ -0,0 +1,8 @@
Git v2.16.6 Release Notes
=========================
This release merges up the fixes that appear in v2.14.6 and in
v2.15.4 addressing the security issues CVE-2019-1348, CVE-2019-1349,
CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, CVE-2019-1353,
CVE-2019-1354, and CVE-2019-1387; see the release notes for those
versions for details.

View File

@ -0,0 +1,12 @@
Git v2.17.3 Release Notes
=========================
This release merges up the fixes that appear in v2.14.6 and in
v2.15.4 addressing the security issues CVE-2019-1348, CVE-2019-1349,
CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, CVE-2019-1353,
CVE-2019-1354, and CVE-2019-1387; see the release notes for those
versions for details.
In addition, `git fsck` was taught to identify `.gitmodules` entries
of the form `submodule.<name>.update=!command`, which have been
disallowed in v2.15.4.

View File

@ -0,0 +1,16 @@
Git v2.17.4 Release Notes
=========================
This release is to address the security issue: CVE-2020-5260
Fixes since v2.17.3
-------------------
* With a crafted URL that contains a newline in it, the credential
helper machinery can be fooled to give credential information for
a wrong host. The attack has been made impossible by forbidding
a newline character in any value passed via the credential
protocol.
Credit for finding the vulnerability goes to Felix Wilhelm of Google
Project Zero.

View File

@ -0,0 +1,22 @@
Git v2.17.5 Release Notes
=========================
This release is to address a security issue: CVE-2020-11008
Fixes since v2.17.4
-------------------
* With a crafted URL that contains a newline or empty host, or lacks
a scheme, the credential helper machinery can be fooled into
providing credential information that is not appropriate for the
protocol in use and host being contacted.
Unlike the vulnerability CVE-2020-5260 fixed in v2.17.4, the
credentials are not for a host of the attacker's choosing; instead,
they are for some unspecified host (based on how the configured
credential helper handles an absent "host" parameter).
The attack has been made impossible by refusing to work with
under-specified credential patterns.
Credit for finding the vulnerability goes to Carlo Arenas.

View File

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

View File

@ -0,0 +1,8 @@
Git v2.18.2 Release Notes
=========================
This release merges up the fixes that appear in v2.14.6, v2.15.4
and in v2.17.3, addressing the security issues CVE-2019-1348,
CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes
for those versions for details.

View File

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

View File

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

View File

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

View File

@ -0,0 +1,8 @@
Git v2.19.3 Release Notes
=========================
This release merges up the fixes that appear in v2.14.6, v2.15.4
and in v2.17.3, addressing the security issues CVE-2019-1348,
CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes
for those versions for details.

View File

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

View File

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

View File

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

View File

@ -0,0 +1,18 @@
Git v2.20.2 Release Notes
=========================
This release merges up the fixes that appear in v2.14.6, v2.15.4
and in v2.17.3, addressing the security issues CVE-2019-1348,
CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes
for those versions for details.
The change to disallow `submodule.<name>.update=!command` entries in
`.gitmodules` which was introduced v2.15.4 (and for which v2.17.3
added explicit fsck checks) fixes the vulnerability in v2.20.x where a
recursive clone followed by a submodule update could execute code
contained within the repository without the user explicitly having
asked for that (CVE-2019-19604).
Credit for finding this vulnerability goes to Joern Schneeweisz,
credit for the fixes goes to Jonathan Nieder.

View File

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

View File

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

View File

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

View File

@ -0,0 +1,12 @@
Git v2.21.1 Release Notes
=========================
This release merges up the fixes that appear in v2.14.6, v2.15.4,
v2.17.3 and in v2.20.2, addressing the security issues CVE-2019-1348,
CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and CVE-2019-19604;
see the release notes for those versions for details.
Additionally, this version also includes a couple of fixes for the
Windows-specific quoting of command-line arguments when Git executes
a Unix shell on Windows.

View File

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

View File

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

View File

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

View File

@ -1,597 +0,0 @@
Git 2.22 Release Notes
======================
Updates since v2.21
-------------------
Backward compatibility note
* The filter specification "--filter=sparse:path=<path>" used to
create a lazy/partial clone has been removed. Using a blob that is
part of the project as sparse specification is still supported with
the "--filter=sparse:oid=<blob>" option.
UI, Workflows & Features
* "git checkout --no-overlay" can be used to trigger a new mode of
checking out paths out of the tree-ish, that allows paths that
match the pathspec that are in the current index and working tree
and are not in the tree-ish.
* The %(trailers) formatter in "git log --format=..." now allows to
optionally pick trailers selectively by keyword, show only values,
etc.
* Four new configuration variables {author,committer}.{name,email}
have been introduced to override user.{name,email} in more specific
cases.
* Command-line completion (in contrib/) learned to tab-complete the
"git submodule absorbgitdirs" subcommand.
* "git branch" learned a new subcommand "--show-current".
* Output from "diff --cc" did not show the original paths when the
merge involved renames. A new option adds the paths in the
original trees to the output.
* The command line completion (in contrib/) has been taught to
complete more subcommand parameters.
* The final report from "git bisect" used to show the suspected
culprit using a raw "diff-tree", with which there is no output for
a merge commit. This has been updated to use a more modern and
human readable output that still is concise enough.
* "git rebase --rebase-merges" replaces its old "--preserve-merges"
option; the latter is now marked as deprecated.
* Error message given while cloning with --recurse-submodules has
been updated.
* The completion helper code now pays attention to repository-local
configuration (when available), which allows --list-cmds to honour
a repository specific setting of completion.commands, for example.
* "git mergetool" learned to offer Sublime Merge (smerge) as one of
its backends.
* A new hook "post-index-change" is called when the on-disk index
file changes, which can help e.g. a virtualized working tree
implementation.
* "git difftool" can now run outside a repository.
* "git checkout -m <other>" was about carrying the differences
between HEAD and the working-tree files forward while checking out
another branch, and ignored the differences between HEAD and the
index. The command has been taught to abort when the index and the
HEAD are different.
* A progress indicator has been added to the "index-pack" step, which
often makes users wait for completion during "git clone".
* "git submodule" learns "set-branch" subcommand that allows the
submodule.*.branch settings to be modified.
* "git merge-recursive" backend recently learned a new heuristics to
infer file movement based on how other files in the same directory
moved. As this is inherently less robust heuristics than the one
based on the content similarity of the file itself (rather than
based on what its neighbours are doing), it sometimes gives an
outcome unexpected by the end users. This has been toned down to
leave the renamed paths in higher/conflicted stages in the index so
that the user can examine and confirm the result.
* "git tag" learned to give an advice suggesting it might be a
mistake when creating an annotated or signed tag that points at
another tag.
* The "git pack-objects" command learned to report the number of
objects it packed via the trace2 mechanism.
* The list of conflicted paths shown in the editor while concluding a
conflicted merge was shown above the scissors line when the
clean-up mode is set to "scissors", even though it was commented
out just like the list of updated paths and other information to
help the user explain the merge better.
* The trace2 tracing facility learned to auto-generate a filename
when told to log to a directory.
* "git clone" learned a new --server-option option when talking over
the protocol version 2.
* The connectivity bitmaps are created by default in bare
repositories now; also the pathname hash-cache is created by
default to avoid making crappy deltas when repacking.
* "git branch new A...B" and "git checkout -b new A...B" have been
taught that in their contexts, the notation A...B means "the merge
base between these two commits", just like "git checkout A...B"
detaches HEAD at that commit.
* Update "git difftool" and "git mergetool" so that the combinations
of {diff,merge}.{tool,guitool} configuration variables serve as
fallback settings of each other in a sensible order.
* The "--dir-diff" mode of "git difftool" is not useful in "--no-index"
mode; they are now explicitly marked as mutually incompatible.
Performance, Internal Implementation, Development Support etc.
* The diff machinery, one of the oldest parts of the system, which
long predates the parse-options API, uses fairly long and complex
handcrafted option parser. This is being rewritten to use the
parse-options API.
* The implementation of pack-redundant has been updated for
performance in a repository with many packfiles.
* A more structured way to obtain execution trace has been added.
* "git prune" has been taught to take advantage of reachability
bitmap when able.
* The command line parser of "git commit-tree" has been rewritten to
use the parse-options API.
* Suggest GitGitGadget instead of submitGit as a way to submit
patches based on GitHub PR to us.
* The test framework has been updated to help developers by making it
easier to run most of the tests under different versions of
over-the-wire protocols.
* Dev support update to make it easier to compare two formatted
results from our documentation.
* The scripted "git rebase" implementation has been retired.
* "git multi-pack-index verify" did not scale well with the number of
packfiles, which is being improved.
* "git stash" has been rewritten in C.
* The "check-docs" Makefile target to support developers has been
updated.
* The tests have been updated not to rely on the abbreviated option
names the parse-options API offers, to protect us from an
abbreviated form of an option that used to be unique within the
command getting non-unique when a new option that share the same
prefix is added.
* The scripted version of "git rebase -i" wrote and rewrote the todo
list many times during a single step of its operation, and the
recent C-rewrite made a faithful conversion of the logic to C. The
implementation has been updated to carry necessary information
around in-core to avoid rewriting the same file over and over
unnecessarily.
* Test framework update to more robustly clean up leftover files and
processes after tests are done.
* Conversion from unsigned char[20] to struct object_id continues.
* While running "git diff" in a lazy clone, we can upfront know which
missing blobs we will need, instead of waiting for the on-demand
machinery to discover them one by one. The code learned to aim to
achieve better performance by batching the request for these
promised blobs.
* During an initial "git clone --depth=..." partial clone, it is
pointless to spend cycles for a large portion of the connectivity
check that enumerates and skips promisor objects (which by
definition is all objects fetched from the other side). This has
been optimized out.
* Mechanically and systematically drop "extern" from function
declaration.
* The script to aggregate perf result unconditionally depended on
libjson-perl even though it did not have to, which has been
corrected.
* The internal implementation of "git rebase -i" has been updated to
avoid forking a separate "rebase--interactive" process.
* Allow DEP and ASLR for Windows build to for security hardening.
* Performance test framework has been broken and measured the version
of Git that happens to be on $PATH, not the specified one to
measure, for a while, which has been corrected.
* Optionally "make coccicheck" can feed multiple source files to
spatch, gaining performance while spending more memory.
* Attempt to use an abbreviated option in "git clone --recurs" is
responded by a request to disambiguate between --recursive and
--recurse-submodules, which is bad because these two are synonyms.
The parse-options API has been extended to define such synonyms
more easily and not produce an unnecessary failure.
* A pair of private functions in http.c that had names similar to
fread/fwrite did not return the number of elements, which was found
to be confusing.
* Update collision-detecting SHA-1 code to build properly on HP-UX.
Fixes since v2.21
-----------------
* "git prune-packed" did not notice and complain against excess
arguments given from the command line, which now it does.
(merge 9b0bd87ed2 rj/prune-packed-excess-args later to maint).
* Split-index fix.
(merge 6e37c8ed3c nd/split-index-null-base-fix later to maint).
* "git diff --no-index" may still want to access Git goodies like
--ext-diff and --textconv, but so far these have been ignored,
which has been corrected.
(merge 287ab28bfa jk/diff-no-index-initialize later to maint).
* Unify RPC code for smart http in protocol v0/v1 and v2, which fixes
a bug in the latter (lack of authentication retry) and generally
improves the code base.
(merge a97d00799a jt/http-auth-proto-v2-fix later to maint).
* The include file compat/bswap.h has been updated so that it is safe
to (accidentally) include it more than once.
(merge 33aa579a55 jk/guard-bswap-header later to maint).
* The set of header files used by "make hdr-check" unconditionally
included sha256/gcrypt.h, even when it is not used, causing the
make target to fail. We now skip it when GCRYPT_SHA256 is not in
use.
(merge f23aa18e7f rj/hdr-check-gcrypt-fix later to maint).
* The Makefile uses 'find' utility to enumerate all the *.h header
files, which is expensive on platforms with slow filesystems; it
now optionally uses "ls-files" if working within a repository,
which is a trick similar to how all sources are enumerated to run
ETAGS on.
(merge 92b88eba9f js/find-lib-h-with-ls-files-when-possible later to maint).
* "git rebase" that was reimplemented in C did not set ORIG_HEAD
correctly, which has been corrected.
(merge cbd29ead92 js/rebase-orig-head-fix later to maint).
* Dev support.
(merge f545737144 js/stress-test-ui-tweak later to maint).
* CFLAGS now can be tweaked when invoking Make while using
DEVELOPER=YesPlease; this did not work well before.
(merge 6d5d4b4e93 ab/makefile-help-devs-more later to maint).
* "git fsck --connectivity-only" omits computation necessary to sift
the objects that are not reachable from any of the refs into
unreachable and dangling. This is now enabled when dangling
objects are requested (which is done by default, but can be
overridden with the "--no-dangling" option).
(merge 8d8c2a5aef jk/fsck-doc later to maint).
* On platforms where "git fetch" is killed with SIGPIPE (e.g. OSX),
the upload-pack that runs on the other end that hangs up after
detecting an error could cause "git fetch" to die with a signal,
which led to a flaky test. "git fetch" now ignores SIGPIPE during
the network portion of its operation (this is not a problem as we
check the return status from our write(2)s).
(merge 143588949c jk/no-sigpipe-during-network-transport later to maint).
* A recent update broke "is this object available to us?" check for
well-known objects like an empty tree (which should yield "yes",
even when there is no on-disk object for an empty tree), which has
been corrected.
(merge f06ab027ef jk/virtual-objects-do-exist later to maint).
* The setup code has been cleaned up to avoid leaks around the
repository_format structure.
(merge e8805af1c3 ma/clear-repository-format later to maint).
* "git config --type=color ..." is meant to replace "git config --get-color"
but there is a slight difference that wasn't documented, which is
now fixed.
(merge cd8e7593b9 jk/config-type-color-ends-with-lf later to maint).
* When the "clean" filter can reduce the size of a huge file in the
working tree down to a small "token" (a la Git LFS), there is no
point in allocating a huge scratch area upfront, but the buffer is
sized based on the original file size. The convert mechanism now
allocates very minimum and reallocates as it receives the output
from the clean filter process.
(merge 02156ab031 jh/resize-convert-scratch-buffer later to maint).
* "git rebase" uses the refs/rewritten/ hierarchy to store its
intermediate states, which inherently makes the hierarchy per
worktree, but it didn't quite work well.
(merge b9317d55a3 nd/rewritten-ref-is-per-worktree later to maint).
* "git log -L<from>,<to>:<path>" with "-s" did not suppress the patch
output as it should. This has been corrected.
(merge 05314efaea jk/line-log-with-patch later to maint).
* "git worktree add" used to do a "find an available name with stat
and then mkdir", which is race-prone. This has been fixed by using
mkdir and reacting to EEXIST in a loop.
(merge 7af01f2367 ms/worktree-add-atomic-mkdir later to maint).
* Build update for SHA-1 with collision detection.
(merge 07a20f569b jk/sha1dc later to maint).
* Build procedure has been fixed around use of asciidoctor instead of
asciidoc.
(merge 185f9a0ea0 ma/asciidoctor-fixes later to maint).
* remote-http transport did not anonymize URLs reported in its error
messages at places.
(merge c1284b21f2 js/anonymize-remote-curl-diag later to maint).
* Error messages given from the http transport have been updated so
that they can be localized.
(merge ed8b4132c8 js/remote-curl-i18n later to maint).
* "git init" forgot to read platform-specific repository
configuration, which made Windows port to ignore settings of
core.hidedotfiles, for example.
* A corner-case object name ambiguity while the sequencer machinery
is working (e.g. "rebase -i -x") has been fixed.
* "git format-patch" did not diagnose an error while opening the
output file for the cover-letter, which has been corrected.
(merge 2fe95f494c jc/format-patch-error-check later to maint).
* "git checkout -f <branch>" while the index has an unmerged path
incorrectly left some paths in an unmerged state, which has been
corrected.
* A corner case bug in the refs API has been corrected.
(merge d3322eb28b jk/refs-double-abort later to maint).
* Unicode update.
(merge 584b62c37b bb/unicode-12 later to maint).
* dumb-http walker has been updated to share more error recovery
strategy with the normal codepath.
* A buglet in configuration parser has been fixed.
(merge 19e7fdaa58 nd/include-if-wildmatch later to maint).
* The documentation for "git read-tree --reset -u" has been updated.
(merge b5a0bd694c nd/read-tree-reset-doc later to maint).
* Code clean-up around a much-less-important-than-it-used-to-be
update_server_info() function.
(merge b3223761c8 jk/server-info-rabbit-hole later to maint).
* The message given when "git commit -a <paths>" errors out has been
updated.
(merge 5a1dbd48bc nd/commit-a-with-paths-msg-update later to maint).
* "git cherry-pick --options A..B", after giving control back to the
user to ask help resolving a conflicted step, did not honor the
options it originally received, which has been corrected.
* Various glitches in "git gc" around reflog handling have been fixed.
* The code to read from commit-graph file has been cleanup with more
careful error checking before using data read from it.
* Performance fix around "git fetch" that grabs many refs.
(merge b764300912 jt/fetch-pack-wanted-refs-optim later to maint).
* Protocol v2 support in "git fetch-pack" of shallow clones has been
corrected.
* Performance fix around "git blame", especially in a linear history
(which is the norm we should optimize for).
(merge f892014943 dk/blame-keep-origin-blob later to maint).
* Performance fix for "rev-list --parents -- pathspec".
(merge 8320b1dbe7 jk/revision-rewritten-parents-in-prio-queue later to maint).
* Updating the display with progress message has been cleaned up to
deal better with overlong messages.
(merge 545dc345eb sg/overlong-progress-fix later to maint).
* "git blame -- path" in a non-bare repository starts blaming from
the working tree, and the same command in a bare repository errors
out because there is no working tree by definition. The command
has been taught to instead start blaming from the commit at HEAD,
which is more useful.
(merge a544fb08f8 sg/blame-in-bare-start-at-head later to maint).
* An underallocation in the code to read the untracked cache
extension has been corrected.
(merge 3a7b45a623 js/untracked-cache-allocfix later to maint).
* The code is updated to check the result of memory allocation before
it is used in more places, by using xmalloc and/or xcalloc calls.
(merge 999b951b28 jk/xmalloc later to maint).
* The GETTEXT_POISON test option has been quite broken ever since it
was made runtime-tunable, which has been fixed.
(merge f88b9cb603 jc/gettext-test-fix later to maint).
* Test fix on APFS that is incapable of store paths in Latin-1.
(merge 3889149619 js/iso8895-test-on-apfs later to maint).
* "git submodule foreach <command> --quiet" did not pass the option
down correctly, which has been corrected.
(merge a282f5a906 nd/submodule-foreach-quiet later to maint).
* "git send-email" has been taught to use quoted-printable when the
payload contains carriage-return. The use of the mechanism is in
line with the design originally added the codepath that chooses QP
when the payload has overly long lines.
(merge 74d76a1701 bc/send-email-qp-cr later to maint).
* The recently added feature to add addresses that are on
anything-by: trailers in 'git send-email' was found to be way too
eager and considered nonsense strings as if they can be legitimate
beginning of *-by: trailer. This has been tightened.
* Builds with gettext broke on recent macOS w/ Homebrew, which
seems to have stopped including from /usr/local/include; this
has been corrected.
(merge 92a1377a2a js/macos-gettext-build later to maint).
* Running "git add" on a repository created inside the current
repository is an explicit indication that the user wants to add it
as a submodule, but when the HEAD of the inner repository is on an
unborn branch, it cannot be added as a submodule. Worse, the files
in its working tree can be added as if they are a part of the outer
repository, which is not what the user wants. These problems are
being addressed.
(merge f937bc2f86 km/empty-repo-is-still-a-repo later to maint).
* "git cherry-pick" run with the "-x" or the "--signoff" option used
to (and more importantly, ought to) clean up the commit log message
with the --cleanup=space option by default, but this has been
broken since late 2017. This has been fixed.
* When given a tag that points at a commit-ish, "git replace --graft"
failed to peel the tag before writing a replace ref, which did not
make sense because the old graft mechanism the feature wants to
mimic only allowed to replace one commit object with another.
This has been fixed.
(merge ee521ec4cb cc/replace-graft-peel-tags later to maint).
* Code tightening against a "wrong" object appearing where an object
of a different type is expected, instead of blindly assuming that
the connection between objects are correctly made.
(merge 97dd512af7 tb/unexpected later to maint).
* An earlier update for MinGW and Cygwin accidentally broke MSVC build,
which has been fixed.
(merge 22c3634c0f ss/msvc-path-utils-fix later to maint).
* %(push:track) token used in the --format option to "git
for-each-ref" and friends was not showing the right branch, which
has been fixed.
(merge c646d0934e dr/ref-filter-push-track-fix later to maint).
* "make check-docs", "git help -a", etc. did not account for cases
where a particular build may deliberately omit some subcommands,
which has been corrected.
* The logic to tell if a Git repository has a working tree protects
"git branch -D" from removing the branch that is currently checked
out by mistake. The implementation of this logic was broken for
repositories with unusual name, which unfortunately is the norm for
submodules these days. This has been fixed.
(merge f3534c98e4 jt/submodule-repo-is-with-worktree later to maint).
* AIX shared the same build issues with other BSDs around fileno(fp),
which has been corrected.
(merge ee662bf5c6 cc/aix-has-fileno-as-a-macro later to maint).
* The autoconf generated configure script failed to use the right
gettext() implementations from -libintl by ignoring useless stub
implementations shipped in some C library, which has been
corrected.
(merge b71e56a683 vk/autoconf-gettext later to maint).
* Fix index-pack perf test so that the repeated invocations always
run in an empty repository, which emulates the initial clone
situation better.
(merge 775c71e16d jk/p5302-avoid-collision-check-cost later to maint).
* A "ls-files" that emulates "find" to enumerate files in the working
tree resulted in duplicated Makefile rules that caused the build to
issue an unnecessary warning during a trial build after merge
conflicts are resolved in working tree *.h files but before the
resolved results are added to the index. This has been corrected.
* "git cherry-pick" (and "revert" that shares the same runtime engine)
that deals with multiple commits got confused when the final step
gets stopped with a conflict and the user concluded the sequence
with "git commit". Attempt to fix it by cleaning up the state
files used by these commands in such a situation.
(merge 4a72486de9 pw/clean-sequencer-state-upon-final-commit later to maint).
* On a filesystem like HFS+, the names of the refs stored as filesystem
entities may become different from what the end-user expects, just
like files in the working tree get "renamed". Work around the
mismatch by paying attention to the core.precomposeUnicode
configuration.
(merge 8e712ef6fc en/unicode-in-refnames later to maint).
* The code to generate the multi-pack idx file was not prepared to
see too many packfiles and ran out of open file descriptor, which
has been corrected.
* To run tests for Git SVN, our scripts for CI used to install the
git-svn package (in the hope that it would bring in the right
dependencies). This has been updated to install the more direct
dependency, namely, libsvn-perl.
(merge db864306cf sg/ci-libsvn-perl later to maint).
* "git cvsexportcommit" running on msys did not expect cvsnt showed
"cvs status" output with CRLF line endings.
* The fsmonitor interface got out of sync after the in-core index
file gets discarded, which has been corrected.
(merge 398a3b0899 js/fsmonitor-refresh-after-discarding-index later to maint).
* "git status" did not know that the "label" instruction in the
todo-list "rebase -i -r" uses should not be shown as a hex object
name.
* A prerequisite check in the test suite to see if a working jgit is
available was made more robust.
(merge abd0f28983 tz/test-lib-check-working-jgit later to maint).
* The codepath to parse :<path> that obtains the object name for an
indexed object has been made more robust.
* Code cleanup, docfix, build fix, etc.
(merge 11f470aee7 jc/test-yes-doc later to maint).
(merge 90503a240b js/doc-symref-in-proto-v1 later to maint).
(merge 5c326d1252 jk/unused-params later to maint).
(merge 68cabbfda3 dl/doc-submodule-wo-subcommand later to maint).
(merge 9903623761 ab/receive-pack-use-after-free-fix later to maint).
(merge 1ede45e44b en/merge-options-doc later to maint).
(merge 3e14dd2c8e rd/doc-hook-used-in-sample later to maint).
(merge c271dc28fd nd/no-more-check-racy later to maint).
(merge e6e15194a8 yb/utf-16le-bom-spellfix later to maint).
(merge bb101aaf0c rd/attr.c-comment-typofix later to maint).
(merge 716a5af812 rd/gc-prune-doc-fix later to maint).
(merge 50b206371d js/untravis-windows later to maint).
(merge dbf47215e3 js/rebase-recreate-merge later to maint).
(merge 56cb2d30f8 dl/reset-doc-no-wrt-abbrev later to maint).
(merge 64eca306a2 ja/dir-rename-doc-markup-fix later to maint).
(merge af91b0230c dl/ignore-docs later to maint).
(merge 59a06e947b ra/t3600-test-path-funcs later to maint).
(merge e041d0781b ar/t4150-remove-cruft later to maint).
(merge 8d75a1d183 ma/asciidoctor-fixes-more later to maint).
(merge 74cc547b0f mh/pack-protocol-doc-fix later to maint).
(merge ed31851fa6 ab/doc-misc-typofixes later to maint).
(merge a7256debd4 nd/checkout-m-doc-update later to maint).
(merge 3a9e1ad78d jt/t5551-protocol-v2-does-not-have-half-auth later to maint).
(merge 0b918b75af sg/t5318-cleanup later to maint).
(merge 68ed71b53c cb/doco-mono later to maint).
(merge a34dca2451 nd/interpret-trailers-docfix later to maint).
(merge cf7b857a77 en/fast-import-parsing-fix later to maint).
(merge fe61ccbc35 po/rerere-doc-fmt later to maint).
(merge ffea0248bf po/describe-not-necessarily-7 later to maint).
(merge 7cb7283adb tg/ls-files-debug-format-fix later to maint).
(merge f64a21bd82 tz/doc-apostrophe-no-longer-needed later to maint).
(merge dbe7b41019 js/t3301-unbreak-notes-test later to maint).
(merge d8083e4180 km/t3000-retitle later to maint).
(merge 9e4cbccbd7 tz/git-svn-doc-markup-fix later to maint).
(merge da9ca955a7 jk/ls-files-doc-markup-fix later to maint).
(merge 6804ba3a58 cw/diff-highlight later to maint).
(merge 1a8787144d nd/submodule-helper-incomplete-line-fix later to maint).
(merge d9ef573837 jk/apache-lsan later to maint).
(merge c871fbee2b js/t6500-use-windows-pid-on-mingw later to maint).
(merge ce4c7bfc90 bl/t4253-exit-code-from-format-patch later to maint).
(merge 397a46db78 js/t5580-unc-alternate-test later to maint).
(merge d4907720a2 cm/notes-comment-fix later to maint).
(merge 9dde06de13 cb/http-push-null-in-message-fix later to maint).
(merge 4c785c0edc js/rebase-config-bitfix later to maint).
(merge 8e9fe16c87 es/doc-gitsubmodules-markup later to maint).

View File

@ -1,147 +0,0 @@
Git 2.22.1 Release Notes
========================
Fixes since v2.22
-----------------
* A relative pathname given to "git init --template=<path> <repo>"
ought to be relative to the directory "git init" gets invoked in,
but it instead was made relative to the repository, which has been
corrected.
* "git worktree add" used to fail when another worktree connected to
the same repository was corrupt, which has been corrected.
* The ownership rule for the file descriptor to fast-import remote
backend was mixed up, leading to unrelated file descriptor getting
closed, which has been fixed.
* "git update-server-info" used to leave stale packfiles in its
output, which has been corrected.
* The server side support for "git fetch" used to show incorrect
value for the HEAD symbolic ref when the namespace feature is in
use, which has been corrected.
* "git am -i --resolved" segfaulted after trying to see a commit as
if it were a tree, which has been corrected.
* "git bundle verify" needs to see if prerequisite objects exist in
the receiving repository, but the command did not check if we are
in a repository upfront, which has been corrected.
* "git merge --squash" is designed to update the working tree and the
index without creating the commit, and this cannot be countermanded
by adding the "--commit" option; the command now refuses to work
when both options are given.
* The data collected by fsmonitor was not properly written back to
the on-disk index file, breaking t7519 tests occasionally, which
has been corrected.
* Update to Unicode 12.1 width table.
* The command line to invoke a "git cat-file" command from inside
"git p4" was not properly quoted to protect a caret and running a
broken command on Windows, which has been corrected.
* "git request-pull" learned to warn when the ref we ask them to pull
from in the local repository and in the published repository are
different.
* When creating a partial clone, the object filtering criteria is
recorded for the origin of the clone, but this incorrectly used a
hardcoded name "origin" to name that remote; it has been corrected
to honor the "--origin <name>" option.
* "git fetch" into a lazy clone forgot to fetch base objects that are
necessary to complete delta in a thin packfile, which has been
corrected.
* The filter_data used in the list-objects-filter (which manages a
lazily sparse clone repository) did not use the dynamic array API
correctly---'nr' is supposed to point at one past the last element
of the array in use. This has been corrected.
* The description about slashes in gitignore patterns (used to
indicate things like "anchored to this level only" and "only
matches directories") has been revamped.
* The URL decoding code has been updated to avoid going past the end
of the string while parsing %-<hex>-<hex> sequence.
* The list of for-each like macros used by clang-format has been
updated.
* "git push --atomic" that goes over the transport-helper (namely,
the smart http transport) failed to prevent refs to be pushed when
it can locally tell that one of the ref update will fail without
having to consult the other end, which has been corrected.
* "git clean" silently skipped a path when it cannot lstat() it; now
it gives a warning.
* A codepath that reads from GPG for signed object verification read
past the end of allocated buffer, which has been fixed.
* "git rm" to resolve a conflicted path leaked an internal message
"needs merge" before actually removing the path, which was
confusing. This has been corrected.
* The "git clone" documentation refers to command line options in its
description in the short form; they have been replaced with long
forms to make them more recognisable.
* The configuration variable rebase.rescheduleFailedExec should be
effective only while running an interactive rebase and should not
affect anything when running an non-interactive one, which was not
the case. This has been corrected.
* "git submodule foreach" did not protect command line options passed
to the command to be run in each submodule correctly, when the
"--recursive" option was in use.
* Use "Erase in Line" CSI sequence that is already used in the editor
support to clear cruft in the progress output.
* The codepath to compute delta islands used to spew progress output
without giving the callers any way to squelch it, which has been
fixed.
* The code to parse scaled numbers out of configuration files has
been made more robust and also easier to follow.
* An incorrect list of options was cached after command line
completion failed (e.g. trying to complete a command that requires
a repository outside one), which has been corrected.
* "git rebase --abort" used to leave refs/rewritten/ when concluding
"git rebase -r", which has been corrected.
* "git stash show 23" used to work, but no more after getting
rewritten in C; this regression has been corrected.
* "git interpret-trailers" always treated '#' as the comment
character, regardless of core.commentChar setting, which has been
corrected.
* Code clean-up to avoid signed integer overlaps during binary search.
* "git checkout -p" needs to selectively apply a patch in reverse,
which did not work well.
* The commit-graph file is now part of the "files that the runtime
may keep open file descriptors on, all of which would need to be
closed when done with the object store", and the file descriptor to
an existing commit-graph file now is closed before "gc" finalizes a
new instance to replace it.
* Code restructuring during 2.20 period broke fetching tags via
"import" based transports.
* We have been trying out a few language features outside c89; the
coding guidelines document did not talk about them and instead had
a blanket ban against them.
Also contains various documentation updates, code clean-ups and minor fixups.

View File

@ -1,410 +0,0 @@
Git 2.23 Release Notes
======================
Updates since v2.22
-------------------
Backward compatibility note
* The "--base" option of "format-patch" computed the patch-ids for
prerequisite patches in an unstable way, which has been updated to
compute in a way that is compatible with "git patch-id --stable".
UI, Workflows & Features
* The "git fast-export/import" pair has been taught to handle commits
with log messages in encoding other than UTF-8 better.
* In recent versions of Git, per-worktree refs are exposed in
refs/worktrees/<wtname>/ hierarchy, which means that worktree names
must be a valid refname component. The code now sanitizes the names
given to worktrees, to make sure these refs are well-formed.
* "git merge" learned "--quit" option that cleans up the in-progress
merge while leaving the working tree and the index still in a mess.
* "git format-patch" learns a configuration to set the default for
its --notes=<ref> option.
* The code to show args with potential typo that cannot be
interpreted as a commit-ish has been improved.
* "git clone --recurse-submodules" learned to set up the submodules
to ignore commit object names recorded in the superproject gitlink
and instead use the commits that happen to be at the tip of the
remote-tracking branches from the get-go, by passing the new
"--remote-submodules" option.
* The pattern "git diff/grep" use to extract funcname and words
boundary for Matlab has been extend to cover Octave, which is more
or less equivalent.
* "git help git" was hard to discover (well, at least for some
people).
* The pattern "git diff/grep" use to extract funcname and words
boundary for Rust has been added.
* "git status" can be told a non-standard default value for the
"--[no-]ahead-behind" option with a new configuration variable
status.aheadBehind.
* "git fetch" and "git pull" reports when a fetch results in
non-fast-forward updates to let the user notice unusual situation.
The commands learned "--no-shown-forced-updates" option to disable
this safety feature.
* Two new commands "git switch" and "git restore" are introduced to
split "checking out a branch to work on advancing its history" and
"checking out paths out of the index and/or a tree-ish to work on
advancing the current history" out of the single "git checkout"
command.
* "git branch --list" learned to always output the detached HEAD as
the first item (when the HEAD is detached, of course), regardless
of the locale.
* The conditional inclusion mechanism learned to base the choice on
the branch the HEAD currently is on.
* "git rev-list --objects" learned with "--no-object-names" option to
squelch the path to the object that is used as a grouping hint for
pack-objects.
* A new tag.gpgSign configuration variable turns "git tag -a" into
"git tag -s".
* "git multi-pack-index" learned expire and repack subcommands.
* "git blame" learned to "ignore" commits in the history, whose
effects (as well as their presence) get ignored.
* "git cherry-pick/revert" learned a new "--skip" action.
* The tips of refs from the alternate object store can be used as
starting point for reachability computation now.
* Extra blank lines in "git status" output have been reduced.
* The commits in a repository can be described by multiple
commit-graph files now, which allows the commit-graph files to be
updated incrementally.
* The "git log" command learns to issue a warning when log.mailmap
configuration is not set and --[no-]mailmap option is not used, to
prepare users for future versions of Git that uses the mailmap by
default.
* "git range-diff" output has been tweaked for easier identification
of which part of what file the patch shown is about.
Performance, Internal Implementation, Development Support etc.
* Update supporting parts of "git rebase" to remove code that should
no longer be used.
* Developer support to emulate unsatisfied prerequisites in tests to
ensure that the remainer of the tests still succeeds when tests
with prerequisites are skipped.
* "git update-server-info" learned not to rewrite the file with the
same contents.
* The way of specifying the path to find dynamic libraries at runtime
has been simplified. The old default to pass -R/path/to/dir has been
replaced with the new default to pass -Wl,-rpath,/path/to/dir,
which is the more recent GCC uses. Those who need to build with an
old GCC can still use "CC_LD_DYNPATH=-R"
* Prepare use of reachability index in topological walker that works
on a range (A..B).
* A new tutorial targetting specifically aspiring git-core
developers has been added.
* Auto-detect how to tell HP-UX aCC where to use dynamically linked
libraries from at runtime.
* "git mergetool" and its tests now spawn fewer subprocesses.
* Dev support update to help tracing out tests.
* Support to build with MSVC has been updated.
* "git fetch" that grabs from a group of remotes learned to run the
auto-gc only once at the very end.
* A handful of Windows build patches have been upstreamed.
* The code to read state files used by the sequencer machinery for
"git status" has been made more robust against a corrupt or stale
state files.
* "git for-each-ref" with multiple patterns have been optimized.
* The tree-walk API learned to pass an in-core repository
instance throughout more codepaths.
* When one step in multi step cherry-pick or revert is reset or
committed, the command line prompt script failed to notice the
current status, which has been improved.
* Many GIT_TEST_* environment variables control various aspects of
how our tests are run, but a few followed "non-empty is true, empty
or unset is false" while others followed the usual "there are a few
ways to spell true, like yes, on, etc., and also ways to spell
false, like no, off, etc." convention.
* Adjust the dir-iterator API and apply it to the local clone
optimization codepath.
* We have been trying out a few language features outside c89; the
coding guidelines document did not talk about them and instead had
a blanket ban against them.
(merge cc0c42975a jc/post-c89-rules-doc later to maint).
* A test helper has been introduced to optimize preparation of test
repositories with many simple commits, and a handful of test
scripts have been updated to use it.
Fixes since v2.22
-----------------
* A relative pathname given to "git init --template=<path> <repo>"
ought to be relative to the directory "git init" gets invoked in,
but it instead was made relative to the repository, which has been
corrected.
(merge e1df7fe43f nd/init-relative-template-fix later to maint).
* "git worktree add" used to fail when another worktree connected to
the same repository was corrupt, which has been corrected.
(merge 105df73e71 nd/corrupt-worktrees later to maint).
* The ownership rule for the file descriptor to fast-import remote
backend was mixed up, leading to unrelated file descriptor getting
closed, which has been fixed.
(merge 3203566a71 mh/import-transport-fd-fix later to maint).
* A "merge -c" instruction during "git rebase --rebase-merges" should
give the user a chance to edit the log message, even when there is
otherwise no need to create a new merge and replace the existing
one (i.e. fast-forward instead), but did not. Which has been
corrected.
* Code cleanup and futureproof.
(merge 31f5256c82 ds/object-info-for-prefetch-fix later to maint).
* More parameter validation.
(merge de99eb0c24 es/grep-require-name-when-needed later to maint).
* "git update-server-info" used to leave stale packfiles in its
output, which has been corrected.
(merge e941c48d49 ew/server-info-remove-crufts later to maint).
* The server side support for "git fetch" used to show incorrect
value for the HEAD symbolic ref when the namespace feature is in
use, which has been corrected.
(merge 533e088250 jk/HEAD-symref-in-xfer-namespaces later to maint).
* "git am -i --resolved" segfaulted after trying to see a commit as
if it were a tree, which has been corrected.
(merge 7663e438c5 jk/am-i-resolved-fix later to maint).
* "git bundle verify" needs to see if prerequisite objects exist in
the receiving repository, but the command did not check if we are
in a repository upfront, which has been corrected.
(merge 3bbbe467f2 js/bundle-verify-require-object-store later to maint).
* "git merge --squash" is designed to update the working tree and the
index without creating the commit, and this cannot be countermanded
by adding the "--commit" option; the command now refuses to work
when both options are given.
(merge 1d14d0c994 vv/merge-squash-with-explicit-commit later to maint).
* The data collected by fsmonitor was not properly written back to
the on-disk index file, breaking t7519 tests occasionally, which
has been corrected.
(merge b5a8169752 js/fsmonitor-unflake later to maint).
* Update to Unicode 12.1 width table.
(merge 5817f9caa3 bb/unicode-12.1-reiwa later to maint).
* The command line to invoke a "git cat-file" command from inside
"git p4" was not properly quoted to protect a caret and running a
broken command on Windows, which has been corrected.
(merge c3f2358de3 mm/p4-unshelve-windows-fix later to maint).
* "git request-pull" learned to warn when the ref we ask them to pull
from in the local repository and in the published repository are
different.
(merge 0454220d66 pb/request-pull-verify-remote-ref later to maint).
* When creating a partial clone, the object filtering criteria is
recorded for the origin of the clone, but this incorrectly used a
hardcoded name "origin" to name that remote; it has been corrected
to honor the "--origin <name>" option.
(merge 1c4a9f9114 xl/record-partial-clone-origin later to maint).
* "git fetch" into a lazy clone forgot to fetch base objects that are
necessary to complete delta in a thin packfile, which has been
corrected.
(merge 810e19322d jt/partial-clone-missing-ref-delta-base later to maint).
* The filter_data used in the list-objects-filter (which manages a
lazily sparse clone repository) did not use the dynamic array API
correctly---'nr' is supposed to point at one past the last element
of the array in use. This has been corrected.
(merge 7140600e2e md/list-objects-filter-memfix later to maint).
* The description about slashes in gitignore patterns (used to
indicate things like "anchored to this level only" and "only
matches directories") has been revamped.
(merge 1a58bad014 an/ignore-doc-update later to maint).
* The URL decoding code has been updated to avoid going past the end
of the string while parsing %-<hex>-<hex> sequence.
(merge d37dc239a4 md/url-parse-harden later to maint).
* The list of for-each like macros used by clang-format has been
updated.
(merge fc7e03aace mo/clang-format-for-each-update later to maint).
* "git branch --list" learned to show branches that are checked out
in other worktrees connected to the same repository prefixed with
'+', similar to the way the currently checked out branch is shown
with '*' in front.
(merge 6e9381469e nb/branch-show-other-worktrees-head later to maint).
* Code restructuring during 2.20 period broke fetching tags via
"import" based transports.
(merge f80d922355 fc/fetch-with-import-fix later to maint).
* The commit-graph file is now part of the "files that the runtime
may keep open file descriptors on, all of which would need to be
closed when done with the object store", and the file descriptor to
an existing commit-graph file now is closed before "gc" finalizes a
new instance to replace it.
(merge 2d511cfc0b ds/close-object-store later to maint).
* "git checkout -p" needs to selectively apply a patch in reverse,
which did not work well.
(merge 2bd69b9024 pw/add-p-recount later to maint).
* Code clean-up to avoid signed integer wraparounds during binary search.
(merge 568a05c5ec rs/avoid-overflow-in-midpoint-computation later to maint).
* "git interpret-trailers" always treated '#' as the comment
character, regardless of core.commentChar setting, which has been
corrected.
(merge 29c83fc23f jk/trailers-use-config later to maint).
* "git stash show 23" used to work, but no more after getting
rewritten in C; this regression has been corrected.
(merge 63b50c8ffe tg/stash-ref-by-index-fix later to maint).
* "git rebase --abort" used to leave refs/rewritten/ when concluding
"git rebase -r", which has been corrected.
(merge d559f502c5 pw/rebase-abort-clean-rewritten later to maint).
* An incorrect list of options was cached after command line
completion failed (e.g. trying to complete a command that requires
a repository outside one), which has been corrected.
(merge 69702523af nd/completion-no-cache-failure later to maint).
* The code to parse scaled numbers out of configuration files has
been made more robust and also easier to follow.
(merge 39c575c969 rs/config-unit-parsing later to maint).
* The codepath to compute delta islands used to spew progress output
without giving the callers any way to squelch it, which has been
fixed.
(merge bdbdf42f8a jk/delta-islands-progress-fix later to maint).
* Protocol capabilities that go over wire should never be translated,
but it was incorrectly marked for translation, which has been
corrected. The output of protocol capabilities for debugging has
been tweaked a bit.
* Use "Erase in Line" CSI sequence that is already used in the editor
support to clear cruft in the progress output.
(merge 5b12e3123b sg/rebase-progress later to maint).
* "git submodule foreach" did not protect command line options passed
to the command to be run in each submodule correctly, when the
"--recursive" option was in use.
(merge 30db18b148 ms/submodule-foreach-fix later to maint).
* The configuration variable rebase.rescheduleFailedExec should be
effective only while running an interactive rebase and should not
affect anything when running an non-interactive one, which was not
the case. This has been corrected.
(merge 906b63942a js/rebase-reschedule-applies-only-to-interactive later to maint).
* The "git clone" documentation refers to command line options in its
description in the short form; they have been replaced with long
forms to make them more recognisable.
(merge bfc8c84ed5 qn/clone-doc-use-long-form later to maint).
* Generation of pack bitmaps are now disabled when .keep files exist,
as these are mutually exclusive features.
(merge 7328482253 ew/repack-with-bitmaps-by-default later to maint).
* "git rm" to resolve a conflicted path leaked an internal message
"needs merge" before actually removing the path, which was
confusing. This has been corrected.
(merge b2b1f615ce jc/denoise-rm-to-resolve later to maint).
* "git stash --keep-index" did not work correctly on paths that have
been removed, which has been fixed.
(merge b932f6a5e8 tg/stash-keep-index-with-removed-paths later to maint).
* Window 7 update ;-)
(merge eb7c786314 js/mingw-spawn-with-spaces-in-path later to maint).
* A codepath that reads from GPG for signed object verification read
past the end of allocated buffer, which has been fixed.
(merge 64c45dc72e sr/gpg-interface-stop-at-the-end later to maint).
* "git clean" silently skipped a path when it cannot lstat() it; now
it gives a warning.
(merge b09364c47a js/clean-report-too-long-a-path later to maint).
* "git push --atomic" that goes over the transport-helper (namely,
the smart http transport) failed to prevent refs to be pushed when
it can locally tell that one of the ref update will fail without
having to consult the other end, which has been corrected.
(merge 2581ea3d31 es/local-atomic-push-failure-with-http later to maint).
* The internal diff machinery can be made to read out of bounds while
looking for --funcion-context line in a corner case, which has been
corrected.
(merge b777f3fd61 jk/xdiff-clamp-funcname-context-index later to maint).
* Other code cleanup, docfix, build fix, etc.
(merge f547101b26 es/git-debugger-doc later to maint).
(merge 7877ac3d7b js/bisect-helper-check-get-oid-return-value later to maint).
(merge 0108f47eb3 sw/git-p4-unshelve-branched-files later to maint).
(merge 9df8f734fd cm/send-email-document-req-modules later to maint).
(merge afc3bf6eb1 ab/hash-object-doc later to maint).
(merge 1fde99cfc7 po/doc-branch later to maint).
(merge 459842e1c2 dl/config-alias-doc later to maint).
(merge 5d137fc2c7 cb/fsmonitor-intfix later to maint).
(merge 921d49be86 rs/copy-array later to maint).
(merge cc8d872e69 js/t3404-typofix later to maint).
(merge 729a9b558b cb/mkstemps-uint-type-fix later to maint).
(merge 9dae4fe79f js/gcc-8-and-9 later to maint).
(merge ed33bd8f30 js/t0001-case-insensitive later to maint).
(merge dfa880e336 jw/gitweb-sample-update later to maint).
(merge e532a90a9f sg/t5551-fetch-smart-error-is-translated later to maint).
(merge 8d45ad8c29 jt/t5551-test-chunked later to maint).
(merge 1a64e07d23 sg/git-C-empty-doc later to maint).
(merge 37a2e35395 sg/ci-brew-gcc-workaround later to maint).
(merge 24df0d49c4 js/trace2-signo-typofix later to maint).
(merge fbec05c210 cc/test-oidmap later to maint).
(merge 7926cee904 di/readme-markup-fix later to maint).
(merge 02638d1e11 vn/xmmap-gently later to maint).
(merge f7bf24d4dd rm/gpg-program-doc-fix later to maint).
(merge 3aef54e8b8 js/unmap-before-ext-diff later to maint).

View File

@ -372,15 +372,15 @@ such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
Some parts of the system have dedicated maintainers with their own
repositories.
- `git-gui/` comes from git-gui project, maintained by Pat Thoyts:
- 'git-gui/' comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- `gitk-git/` comes from Paul Mackerras's gitk project:
- 'gitk-git/' comes from Paul Mackerras's gitk project:
git://ozlabs.org/~paulus/gitk
- `po/` comes from the localization coordinator, Jiang Xin:
- 'po/' comes from the localization coordinator, Jiang Xin:
https://github.com/git-l10n/git-po/

View File

@ -11,12 +11,12 @@ module Git
def process(parent, target, attrs)
if parent.document.basebackend? 'html'
prefix = parent.document.attr('git-relative-html-prefix')
%(<a href="#{prefix}#{target}.html">#{target}(#{attrs[1]})</a>)
%(<a href="#{prefix}#{target}.html">#{target}(#{attrs[1]})</a>\n)
elsif parent.document.basebackend? 'docbook'
"<citerefentry>\n" \
"<refentrytitle>#{target}</refentrytitle>" \
"<manvolnum>#{attrs[1]}</manvolnum>\n" \
"</citerefentry>"
"</citerefentry>\n"
end
end
end

View File

@ -110,24 +110,5 @@ commit. And the default value is 40. If there are more than one
`-C` options given, the <num> argument of the last `-C` will
take effect.
--ignore-rev <rev>::
Ignore changes made by the revision when assigning blame, as if the
change never happened. Lines that were changed or added by an ignored
commit will be blamed on the previous commit that changed that line or
nearby lines. This option may be specified multiple times to ignore
more than one revision. If the `blame.markIgnoredLines` config option
is set, then lines that were changed by an ignored commit and attributed to
another commit will be marked with a `?` in the blame output. If the
`blame.markUnblamableLines` config option is set, then those lines touched
by an ignored commit that we could not attribute to another revision are
marked with a '*'.
--ignore-revs-file <file>::
Ignore revisions listed in `file`, which must be in the same format as an
`fsck.skipList`. This option may be repeated, and these files will be
processed after any files specified with the `blame.ignoreRevsFile` config
option. An empty file name, `""`, will clear the list of revs from
previously processed files.
-h::
Show help message.

View File

@ -144,20 +144,6 @@ refer to linkgit:gitignore[5] for details. For convenience:
This is the same as `gitdir` except that matching is done
case-insensitively (e.g. on case-insensitive file sytems)
`onbranch`::
The data that follows the keyword `onbranch:` is taken to be a
pattern with standard globbing wildcards and two additional
ones, `**/` and `/**`, that can match multiple path components.
If we are in a worktree where the name of the branch that is
currently checked out matches the pattern, the include condition
is met.
+
If the pattern ends with `/`, `**` will be automatically added. For
example, the pattern `foo/` becomes `foo/**`. In other words, it matches
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.
A few more notes on matching via `gitdir` and `gitdir/i`:
* Symlinks in `$GIT_DIR` are not resolved before matching.
@ -220,11 +206,6 @@ Example
[includeIf "gitdir:/path/to/group/"]
path = foo.inc
; include only if we are in a worktree where foo-branch is
; currently checked out
[includeIf "onbranch:foo-branch"]
path = foo.inc
Values
~~~~~~
@ -441,8 +422,6 @@ include::config/submodule.txt[]
include::config/tag.txt[]
include::config/trace2.txt[]
include::config/transfer.txt[]
include::config/uploadarchive.txt[]

View File

@ -4,10 +4,6 @@ advice.*::
can tell Git that you do not need help by setting these to 'false':
+
--
fetchShowForcedUpdates::
Advice shown when linkgit:git-fetch[1] takes a long time
to calculate forced updates after ref updates, or to warn
that the check is disabled.
pushUpdateRejected::
Set this variable to 'false' if you want to disable
'pushNonFFCurrent',
@ -41,19 +37,12 @@ advice.*::
we can still suggest that the user push to either
refs/heads/* or refs/tags/* based on the type of the
source object.
statusAheadBehind::
Shown when linkgit:git-status[1] computes the ahead/behind
counts for a local ref compared to its remote tracking ref,
and that calculation takes longer than expected. Will not
appear if `status.aheadBehind` is false or the option
`--no-ahead-behind` is given.
statusHints::
Show directions on how to proceed from the current
state in the output of linkgit:git-status[1], in
the template shown when writing commit messages in
linkgit:git-commit[1], and in the help message shown
by linkgit:git-switch[1] or
linkgit:git-checkout[1] when switching branch.
by linkgit:git-checkout[1] when switching branch.
statusUoption::
Advise to consider using the `-u` option to linkgit:git-status[1]
when the command takes more than 2 seconds to enumerate untracked
@ -68,21 +57,17 @@ advice.*::
resolveConflict::
Advice shown by various commands when conflicts
prevent the operation from being performed.
sequencerInUse::
Advice shown when a sequencer command is already in progress.
implicitIdentity::
Advice on how to set your identity configuration when
your information is guessed from the system username and
domain name.
detachedHead::
Advice shown when you used
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.
Advice shown when you used linkgit:git-checkout[1] to
move to the detach HEAD state, to instruct how to create
a local branch after the fact.
checkoutAmbiguousRemoteBranchName::
Advice shown when the argument to
linkgit:git-checkout[1] and linkgit:git-switch[1]
ambiguously resolves to a
linkgit:git-checkout[1] ambiguously resolves to a
remote tracking branch on more than one remote in
situations where an unambiguous argument would have
otherwise caused a remote-tracking branch to be
@ -105,6 +90,4 @@ advice.*::
waitingForEditor::
Print a message to the terminal whenever Git is waiting for
editor input from the user.
nestedTag::
Advice shown if a user attempts to recursively tag a tag object.
--

View File

@ -1,28 +1,18 @@
alias.*::
Command aliases for the linkgit:git[1] command wrapper - e.g.
after defining `alias.last = cat-file commit HEAD`, the invocation
`git last` is equivalent to `git cat-file commit HEAD`. To avoid
after defining "alias.last = cat-file commit HEAD", the invocation
"git last" is equivalent to "git cat-file commit HEAD". To avoid
confusion and troubles with script usage, aliases that
hide existing Git commands are ignored. Arguments are split by
spaces, the usual shell quoting and escaping is supported.
A quote pair or a backslash can be used to quote them.
+
Note that the first word of an alias does not necessarily have to be a
command. It can be a command-line option that will be passed into the
invocation of `git`. In particular, this is useful when used with `-c`
to pass in one-time configurations or `-p` to force pagination. For example,
`loud-rebase = -c commit.verbose=true rebase` can be defined such that
running `git loud-rebase` would be equivalent to
`git -c commit.verbose=true rebase`. Also, `ps = -p status` would be a
helpful alias since `git ps` would paginate the output of `git status`
where the original command does not.
+
If the alias expansion is prefixed with an exclamation point,
it will be treated as a shell command. For example, defining
`alias.new = !gitk --all --not ORIG_HEAD`, the invocation
`git new` is equivalent to running the shell command
`gitk --all --not ORIG_HEAD`. Note that shell commands will be
"alias.new = !gitk --all --not ORIG_HEAD", the invocation
"git new" is equivalent to running the shell command
"gitk --all --not ORIG_HEAD". Note that shell commands will be
executed from the top-level directory of a repository, which may
not necessarily be the current directory.
`GIT_PREFIX` is set as returned by running `git rev-parse --show-prefix`
`GIT_PREFIX` is set as returned by running 'git rev-parse --show-prefix'
from the original current directory. See linkgit:git-rev-parse[1].

View File

@ -19,19 +19,3 @@ blame.showEmail::
blame.showRoot::
Do not treat root commits as boundaries in linkgit:git-blame[1].
This option defaults to false.
blame.ignoreRevsFile::
Ignore revisions listed in the file, one unabbreviated object name per
line, in linkgit:git-blame[1]. Whitespace and comments beginning with
`#` are ignored. This option may be repeated multiple times. Empty
file names will reset the list of ignored revisions. This option will
be handled before the command line option `--ignore-revs-file`.
blame.markUnblamables::
Mark lines that were changed by an ignored revision that we could not
attribute to another commit with a '*' in the output of
linkgit:git-blame[1].
blame.markIgnoredLines::
Mark lines that were changed by an ignored revision that we attributed to
another commit with a '?' in the output of linkgit:git-blame[1].

View File

@ -1,5 +1,5 @@
branch.autoSetupMerge::
Tells 'git branch', 'git switch' and 'git checkout' to set up new branches
Tells 'git branch' and 'git checkout' to set up new branches
so that linkgit:git-pull[1] will appropriately merge from the
starting point branch. Note that even if this option is not set,
this behavior can be chosen per-branch using the `--track`
@ -11,7 +11,7 @@ branch.autoSetupMerge::
branch. This option defaults to true.
branch.autoSetupRebase::
When a new branch is created with 'git branch', 'git switch' or 'git checkout'
When a new branch is created with 'git branch' or 'git checkout'
that tracks another branch, this variable tells Git to set
up pull to rebase instead of merge (see "branch.<name>.rebase").
When `never`, rebase is never automatically set to true.
@ -85,9 +85,9 @@ When `merges`, pass the `--rebase-merges` option to 'git rebase'
so that the local merge commits are included in the rebase (see
linkgit:git-rebase[1] for details).
+
When `preserve` (deprecated in favor of `merges`), also pass
`--preserve-merges` along to 'git rebase' so that locally committed merge
commits will not be flattened by running 'git pull'.
When preserve, also pass `--preserve-merges` along to 'git rebase'
so that locally committed merge commits will not be flattened
by running 'git pull'.
+
When the value is `interactive`, the rebase is run in interactive mode.
+

View File

@ -1,6 +1,5 @@
checkout.defaultRemote::
When you run 'git checkout <something>'
or 'git switch <something>' and only have one
When you run 'git checkout <something>' and only have one
remote, it may implicitly fall back on checking out and
tracking e.g. 'origin/<something>'. This stops working as soon
as you have more than one remote with a '<something>'
@ -9,10 +8,16 @@ checkout.defaultRemote::
disambiguation. The typical use-case is to set this to
`origin`.
+
Currently this is used by linkgit:git-switch[1] and
linkgit:git-checkout[1] when 'git checkout <something>'
or 'git switch <something>'
will checkout the '<something>' branch on another remote,
Currently this is used by linkgit:git-checkout[1] when 'git checkout
<something>' will checkout the '<something>' branch on another remote,
and by linkgit:git-worktree[1] when 'git worktree add' refers to a
remote branch. This setting might be used for other checkout-like
commands or functionality in the future.
checkout.optimizeNewBranch::
Optimizes the performance of "git checkout -b <new_branch>" when
using sparse-checkout. When set to true, git will not update the
repo based on the current sparse-checkout settings. This means it
will not update the skip-worktree bit in the index nor add/remove
files in the working directory to reflect the current sparse checkout
settings nor will it show the local changes.

View File

@ -414,7 +414,7 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
core.excludesFile::
Specifies the pathname to the file that contains patterns to
describe paths that are not meant to be tracked, in addition
to `.gitignore` (per-directory) and `.git/info/exclude`.
to '.gitignore' (per-directory) and '.git/info/exclude'.
Defaults to `$XDG_CONFIG_HOME/git/ignore`.
If `$XDG_CONFIG_HOME` is either not set or empty, `$HOME/.config/git/ignore`
is used instead. See linkgit:gitignore[5].
@ -429,8 +429,8 @@ core.askPass::
command-line argument and write the password on its STDOUT.
core.attributesFile::
In addition to `.gitattributes` (per-directory) and
`.git/info/attributes`, Git looks into this file for attributes
In addition to '.gitattributes' (per-directory) and
'.git/info/attributes', Git looks into this file for attributes
(see linkgit:gitattributes[5]). Path expansions are made the same
way as for `core.excludesFile`. Its default value is
`$XDG_CONFIG_HOME/git/attributes`. If `$XDG_CONFIG_HOME` is either not
@ -438,10 +438,10 @@ core.attributesFile::
core.hooksPath::
By default Git will look for your hooks in the
`$GIT_DIR/hooks` directory. Set this to different path,
e.g. `/etc/git/hooks`, and Git will try to find your hooks in
that directory, e.g. `/etc/git/hooks/pre-receive` instead of
in `$GIT_DIR/hooks/pre-receive`.
'$GIT_DIR/hooks' directory. Set this to different path,
e.g. '/etc/git/hooks', and Git will try to find your hooks in
that directory, e.g. '/etc/git/hooks/pre-receive' instead of
in '$GIT_DIR/hooks/pre-receive'.
+
The path can be either absolute or relative. A relative path is
taken as relative to the directory where the hooks are run (see

View File

@ -10,7 +10,7 @@ diff.autoRefreshIndex::
diff.dirstat::
A comma separated list of `--dirstat` parameters specifying the
default behavior of the `--dirstat` option to linkgit:git-diff[1]
default behavior of the `--dirstat` option to linkgit:git-diff[1]`
and friends. The defaults can be overridden on the command line
(using `--dirstat=<param1,param2,...>`). The fallback defaults
(when not changed by `diff.dirstat`) are `changes,noncumulative,3`.
@ -73,13 +73,12 @@ diff.external::
environment variable. The command is called with parameters
as described under "git Diffs" in linkgit:git[1]. Note: if
you want to use an external diff program only on a subset of
your files, you might want to use linkgit:gitattributes[5] instead.
your files, you might want to use linkgit:gitattributes[5] instead.
diff.ignoreSubmodules::
Sets the default value of --ignore-submodules. Note that this
affects only 'git diff' Porcelain, and not lower level 'diff'
commands such as 'git diff-files'. 'git checkout'
and 'git switch' also honor
commands such as 'git diff-files'. 'git checkout' also honors
this setting when reporting uncommitted changes. Setting it to
'all' disables the submodule summary normally shown by 'git commit'
and 'git status' when `status.submoduleSummary` is set unless it is

View File

@ -63,8 +63,3 @@ fetch.negotiationAlgorithm::
Unknown values will cause 'git fetch' to error out.
+
See also the `--negotiation-tip` option for linkgit:git-fetch[1].
fetch.showForcedUpdates::
Set to false to enable `--no-show-forced-updates` in
linkgit:git-fetch[1] and linkgit:git-pull[1] commands.
Defaults to true.

View File

@ -85,18 +85,3 @@ format.outputDirectory::
format.useAutoBase::
A boolean value which lets you enable the `--base=auto` option of
format-patch by default.
format.notes::
Provides the default value for the `--notes` option to
format-patch. Accepts a boolean value, or a ref which specifies
where to get notes. If false, format-patch defaults to
`--no-notes`. If true, format-patch defaults to `--notes`. If
set to a non-boolean value, format-patch defaults to
`--notes=<ref>`, where `ref` is the non-boolean value. Defaults
to false.
+
If one wishes to use the ref `ref/notes/true`, please use that literal
instead.
+
This configuration can be specified multiple times in order to allow
multiple notes refs to be included.

View File

@ -23,9 +23,9 @@ When `fsck.<msg-id>` is set, errors can be switched to warnings and
vice versa by configuring the `fsck.<msg-id>` setting where the
`<msg-id>` is the fsck message ID and the value is one of `error`,
`warn` or `ignore`. For convenience, fsck prefixes the error/warning
with the message ID, e.g. "missingEmail: invalid author/committer
line - missing email" means that setting `fsck.missingEmail = ignore`
will hide that issue.
with the message ID, e.g. "missingEmail: invalid author/committer line
- missing email" means that setting `fsck.missingEmail = ignore` will
hide that issue.
+
In general, it is better to enumerate existing objects with problems
with `fsck.skipList`, instead of listing the kind of breakages these

View File

@ -1,42 +1,25 @@
gc.aggressiveDepth::
The depth parameter used in the delta compression
algorithm used by 'git gc --aggressive'. This defaults
to 50, which is the default for the `--depth` option when
`--aggressive` isn't in use.
+
See the documentation for the `--depth` option in
linkgit:git-repack[1] for more details.
to 50.
gc.aggressiveWindow::
The window size parameter used in the delta compression
algorithm used by 'git gc --aggressive'. This defaults
to 250, which is a much more aggressive window size than
the default `--window` of 10.
+
See the documentation for the `--window` option in
linkgit:git-repack[1] for more details.
to 250.
gc.auto::
When there are approximately more than this many loose
objects in the repository, `git gc --auto` will pack them.
Some Porcelain commands use this command to perform a
light-weight garbage collection from time to time. The
default value is 6700.
+
Setting this to 0 disables not only automatic packing based on the
number of loose objects, but any other heuristic `git gc --auto` will
otherwise use to determine if there's work to do, such as
`gc.autoPackLimit`.
default value is 6700. Setting this to 0 disables it.
gc.autoPackLimit::
When there are more than this many packs that are not
marked with `*.keep` file in the repository, `git gc
--auto` consolidates them into one larger pack. The
default value is 50. Setting this to 0 disables it.
Setting `gc.auto` to 0 will also disable this.
+
See the `gc.bigPackThreshold` configuration variable below. When in
use, it'll affect how the auto pack limit works.
default value is 50. Setting this to 0 disables it.
gc.autoDetach::
Make `git gc --auto` return immediately and run in background
@ -53,16 +36,11 @@ Note that if the number of kept packs is more than gc.autoPackLimit,
this configuration variable is ignored, all packs except the base pack
will be repacked. After this the number of packs should go below
gc.autoPackLimit and gc.bigPackThreshold should be respected again.
+
If the amount of memory estimated for `git repack` to run smoothly is
not available and `gc.bigPackThreshold` is not set, the largest pack
will also be excluded (this is the equivalent of running `git gc` with
`--keep-base-pack`).
gc.writeCommitGraph::
If true, then gc will rewrite the commit-graph file when
linkgit:git-gc[1] is run. When using `git gc --auto`
the commit-graph will be updated if housekeeping is
linkgit:git-gc[1] is run. When using linkgit:git-gc[1]
'--auto' the commit-graph will be updated if housekeeping is
required. Default is false. See linkgit:git-commit-graph[1]
for details.
@ -116,12 +94,6 @@ gc.<pattern>.reflogExpireUnreachable::
With "<pattern>" (e.g. "refs/stash")
in the middle, the setting applies only to the refs that
match the <pattern>.
+
These types of entries are generally created as a result of using `git
commit --amend` or `git rebase` and are the commits prior to the amend
or rebase occurring. Since these changes are not part of the current
project most users will want to expire them sooner, which is why the
default is more aggressive than `gc.reflogExpire`.
gc.rerereResolved::
Records of conflicted merge you resolved earlier are

View File

@ -2,7 +2,7 @@ gpg.program::
Use this custom program instead of "`gpg`" found on `$PATH` when
making or verifying a PGP signature. The program must support the
same command-line interface as GPG, namely, to verify a detached
signature, "`gpg --verify $signature - <$file`" is run, and the
signature, "`gpg --verify $file - <$signature`" is run, and the
program is expected to signal a good signature by exiting with
code 0, and to generate an ASCII-armored detached signature, the
standard input of "`gpg -bsau $key`" is fed with the contents to be
@ -16,5 +16,5 @@ gpg.format::
gpg.<format>.program::
Use this to customize the program used for the signing format you
chose. (see `gpg.program` and `gpg.format`) `gpg.program` can still
be used as a legacy synonym for `gpg.openpgp.program`. The default
be used as a legacy synonym for `gpg.openpgp.program`. The default
value for `gpg.x509.program` is "gpgsm".

View File

@ -2,8 +2,7 @@ interactive.singleKey::
In interactive commands, allow the user to provide one-letter
input with a single key (i.e., without hitting enter).
Currently this is used by the `--patch` mode of
linkgit:git-add[1], linkgit:git-checkout[1],
linkgit:git-restore[1], linkgit:git-commit[1],
linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1],
linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this
setting is silently ignored if portable keystroke input
is not available; requires the Perl module Term::ReadKey.

View File

@ -40,5 +40,4 @@ log.showSignature::
log.mailmap::
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
linkgit:git-whatchanged[1] assume `--use-mailmap`, otherwise
assume `--no-use-mailmap`. False by default.
linkgit:git-whatchanged[1] assume `--use-mailmap`.

View File

@ -39,22 +39,9 @@ merge.renameLimit::
is turned off.
merge.renames::
Whether Git detects renames. If set to "false", rename detection
is disabled. If set to "true", basic rename detection is enabled.
Defaults to the value of diff.renames.
merge.directoryRenames::
Whether Git detects directory renames, affecting what happens at
merge time to new files added to a directory on one side of
history when that directory was renamed on the other side of
history. If merge.directoryRenames is set to "false", directory
rename detection is disabled, meaning that such new files will be
left behind in the old directory. If set to "true", directory
rename detection is enabled, meaning that such new files will be
moved into the new directory. If set to "conflict", a conflict
will be reported for such paths. If merge.renames is false,
merge.directoryRenames is ignored and treated as false. Defaults
to "conflict".
Whether and how Git detects renames. If set to "false",
rename detection is disabled. If set to "true", basic rename
detection is enabled. Defaults to the value of diff.renames.
merge.renormalize::
Tell Git that canonical representation of files in the

View File

@ -124,4 +124,6 @@ pack.writeBitmapHashCache::
bitmapped and non-bitmapped objects (e.g., when serving a fetch
between an older, bitmapped pack and objects that have been
pushed since the last gc). The downside is that it consumes 4
bytes per object of disk space. Defaults to true.
bytes per object of disk space, and that JGit's bitmap
implementation does not understand it, causing it to complain if
Git and JGit are used on the same repository. Defaults to false.

View File

@ -18,9 +18,9 @@ When `merges`, pass the `--rebase-merges` option to 'git rebase'
so that the local merge commits are included in the rebase (see
linkgit:git-rebase[1] for details).
+
When `preserve` (deprecated in favor of `merges`), also pass
`--preserve-merges` along to 'git rebase' so that locally committed merge
commits will not be flattened by running 'git pull'.
When preserve, also pass `--preserve-merges` along to 'git rebase'
so that locally committed merge commits will not be flattened
by running 'git pull'.
+
When the value is `interactive`, the rebase is run in interactive mode.
+

View File

@ -1,9 +1,16 @@
rebase.useBuiltin::
Unused configuration variable. Used in Git versions 2.20 and
2.21 as an escape hatch to enable the legacy shellscript
implementation of rebase. Now the built-in rewrite of it in C
is always used. Setting this will emit a warning, to alert any
remaining users that setting this now does nothing.
Set to `false` to use the legacy shellscript implementation of
linkgit:git-rebase[1]. Is `true` by default, which means use
the built-in rewrite of it in C.
+
The C rewrite is first included with Git version 2.20. This option
serves an an escape hatch to re-enable the legacy version in case any
bugs are found in the rewrite. This option and the shellscript version
of linkgit:git-rebase[1] will be removed in some future release.
+
If you find some reason to set this option to `false` other than
one-off testing you should report the behavior difference as a bug in
git.
rebase.stat::
Whether to show a diffstat of what changed upstream since the last

View File

@ -24,4 +24,4 @@ repack.writeBitmaps::
packs created for clones and fetches, at the cost of some disk
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.
Defaults to false.

View File

@ -1,18 +1,3 @@
stash.useBuiltin::
Set to `false` to use the legacy shell script implementation of
linkgit:git-stash[1]. Is `true` by default, which means use
the built-in rewrite of it in C.
+
The C rewrite is first included with Git version 2.22 (and Git for Windows
version 2.19). This option serves an an escape hatch to re-enable the
legacy version in case any bugs are found in the rewrite. This option and
the shell script version of linkgit:git-stash[1] will be removed in some
future release.
+
If you find some reason to set this option to `false`, other than
one-off testing, you should report the behavior difference as a bug in
Git (see https://git-scm.com/community for details).
stash.showPatch::
If this is set to true, the `git stash show` command without an
option will show the stash entry in patch form. Defaults to false.

View File

@ -12,11 +12,6 @@ status.branch::
Set to true to enable --branch by default in linkgit:git-status[1].
The option --no-branch takes precedence over this variable.
status.aheadBehind::
Set to true to enable `--ahead-behind` and false to enable
`--no-ahead-behind` by default in linkgit:git-status[1] for
non-porcelain status formats. Defaults to true.
status.displayCommentPrefix::
If set to true, linkgit:git-status[1] will insert a comment
prefix before each output line (starting with

View File

@ -8,14 +8,6 @@ tag.sort::
linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
value of this variable will be used as the default.
tag.gpgSign::
A boolean to specify whether all tags should be GPG signed.
Use of this option when running in an automated script can
result in a large number of tags being signed. It is therefore
convenient to use an agent to avoid typing your gpg passphrase
several times. Note that this option doesn't affects tag signing
behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options.
tar.umask::
This variable can be used to restrict the permission bits of
tar archive entries. The default is 0002, which turns off the

View File

@ -1,56 +0,0 @@
Trace2 config settings are only read from the system and global
config files; repository local and worktree config files and `-c`
command line arguments are not respected.
trace2.normalTarget::
This variable controls the normal target destination.
It may be overridden by the `GIT_TRACE2` environment variable.
The following table shows possible values.
trace2.perfTarget::
This variable controls the performance target destination.
It may be overridden by the `GIT_TRACE2_PERF` environment variable.
The following table shows possible values.
trace2.eventTarget::
This variable controls the event target destination.
It may be overridden by the `GIT_TRACE2_EVENT` environment variable.
The following table shows possible values.
+
include::../trace2-target-values.txt[]
trace2.normalBrief::
Boolean. When true `time`, `filename`, and `line` fields are
omitted from normal output. May be overridden by the
`GIT_TRACE2_BRIEF` environment variable. Defaults to false.
trace2.perfBrief::
Boolean. When true `time`, `filename`, and `line` fields are
omitted from PERF output. May be overridden by the
`GIT_TRACE2_PERF_BRIEF` environment variable. Defaults to false.
trace2.eventBrief::
Boolean. When true `time`, `filename`, and `line` fields are
omitted from event output. May be overridden by the
`GIT_TRACE2_EVENT_BRIEF` environment variable. Defaults to false.
trace2.eventNesting::
Integer. Specifies desired depth of nested regions in the
event output. Regions deeper than this value will be
omitted. May be overridden by the `GIT_TRACE2_EVENT_NESTING`
environment variable. Defaults to 2.
trace2.configParams::
A comma-separated list of patterns of "important" config
settings that should be recorded in the trace2 output.
For example, `core.*,remote.*.url` would cause the trace2
output to contain events listing each configured remote.
May be overridden by the `GIT_TRACE2_CONFIG_PARAMS` environment
variable. Unset by default.
trace2.destinationDebug::
Boolean. When true Git will print error messages when a
trace target destination cannot be opened for writing.
By default, these errors are suppressed and tracing is
silently disabled. May be overridden by the
`GIT_TRACE2_DST_DEBUG` environment variable.

View File

@ -1,19 +1,12 @@
user.name::
user.email::
author.name::
author.email::
committer.name::
committer.email::
The `user.name` and `user.email` variables determine what ends
up in the `author` and `committer` field of commit
objects.
If you need the `author` or `committer` to be different, the
`author.name`, `author.email`, `committer.name` or
`committer.email` variables can be set.
Also, all of these can be overridden by the `GIT_AUTHOR_NAME`,
`GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_NAME`,
`GIT_COMMITTER_EMAIL` and `EMAIL` environment variables.
See linkgit:git-commit-tree[1] for more information.
Your email address to be recorded in any newly created commits.
Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
`EMAIL` environment variables. See linkgit:git-commit-tree[1].
user.name::
Your full name to be recorded in any newly created commits.
Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
environment variables. See linkgit:git-commit-tree[1].
user.useConfigOnly::
Instruct Git to avoid trying to guess defaults for `user.email`

View File

@ -95,26 +95,12 @@ from the format described above in the following way:
. there are more "src" modes and "src" sha1
. status is concatenated status characters for each parent
. no optional "score" number
. tab-separated pathname(s) of the file
. single path, only for "dst"
For `-c` and `--cc`, only the destination or final path is shown even
if the file was renamed on any side of history. With
`--combined-all-paths`, the name of the path in each parent is shown
followed by the name of the path in the merge commit.
Examples for `-c` and `--cc` without `--combined-all-paths`:
------------------------------------------------
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c
::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM bar.sh
::100644 100644 100644 e07d6c5 9042e82 ee91881 RR phooey.c
------------------------------------------------
Examples when `--combined-all-paths` added to either `-c` or `--cc`:
Example:
------------------------------------------------
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c desc.c desc.c
::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM foo.sh bar.sh bar.sh
::100644 100644 100644 e07d6c5 9042e82 ee91881 RR fooey.c fuey.c phooey.c
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM describe.c
------------------------------------------------
Note that 'combined diff' lists only files which were modified from

View File

@ -143,19 +143,6 @@ copying detection) are designed to work with diff of two
Similar to two-line header for traditional 'unified' diff
format, `/dev/null` is used to signal created or deleted
files.
+
However, if the --combined-all-paths option is provided, instead of a
two-line from-file/to-file you get a N+1 line from-file/to-file header,
where N is the number of parents in the merge commit
--- a/file
--- a/file
--- a/file
+++ b/file
+
This extended format can be useful if rename or copy detection is
active, to allow you to see the original name of the file in different
parents.
4. Chunk header format is modified to prevent people from
accidentally feeding it to `patch -p1`. Combined diff format

View File

@ -36,21 +36,11 @@ endif::git-format-patch[]
-U<n>::
--unified=<n>::
Generate diffs with <n> lines of context instead of
the usual three. Implies `--patch`.
the usual three.
ifndef::git-format-patch[]
Implies `-p`.
endif::git-format-patch[]
--output=<file>::
Output to a specific file instead of stdout.
--output-indicator-new=<char>::
--output-indicator-old=<char>::
--output-indicator-context=<char>::
Specify the character used to indicate new, old or context
lines in the generated patch. Normally they are '+', '-' and
' ' respectively.
ifndef::git-format-patch[]
--raw::
ifndef::git-log[]
@ -158,7 +148,6 @@ These parameters can also be set individually with `--stat-width=<width>`,
number of modified files, as well as number of added and deleted
lines.
-X[<param1,param2,...>]::
--dirstat[=<param1,param2,...>]::
Output the distribution of relative amount of changes for each
sub-directory. The behavior of `--dirstat` can be customized by
@ -203,12 +192,6 @@ directories with less than 10% of the total amount of changed files,
and accumulating child directory counts in the parent directories:
`--dirstat=files,10,cumulative`.
--cumulative::
Synonym for --dirstat=cumulative
--dirstat-by-file[=<param1,param2>...]::
Synonym for --dirstat=files,param1,param2...
--summary::
Output a condensed summary of extended header information
such as creations, renames and mode changes.
@ -403,9 +386,6 @@ endif::git-format-patch[]
Turn off rename detection, even when the configuration
file gives the default to do so.
--[no-]rename-empty::
Whether to use empty blobs as rename source.
ifndef::git-format-patch[]
--check::
Warn if changes introduce conflict markers or whitespace errors.
@ -436,7 +416,7 @@ endif::git-format-patch[]
--binary::
In addition to `--full-index`, output a binary diff that
can be applied with `git-apply`. Implies `--patch`.
can be applied with `git-apply`.
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object

View File

@ -12,16 +12,9 @@ OPTIONS_SPEC="\
doc-diff [options] <from> <to> [-- <diff-options>]
doc-diff (-c|--clean)
--
j=n parallel argument to pass to make
f force rebuild; do not rely on cached results
c,clean cleanup temporary working files
from-asciidoc use asciidoc with the 'from'-commit
from-asciidoctor use asciidoctor with the 'from'-commit
asciidoc use asciidoc with both commits
to-asciidoc use asciidoc with the 'to'-commit
to-asciidoctor use asciidoctor with the 'to'-commit
asciidoctor use asciidoctor with both commits
cut-header-footer cut away header and footer
j=n parallel argument to pass to make
f force rebuild; do not rely on cached results
c,clean cleanup temporary working files
"
SUBDIRECTORY_OK=1
. "$(git --exec-path)/git-sh-setup"
@ -29,9 +22,6 @@ SUBDIRECTORY_OK=1
parallel=
force=
clean=
from_program=
to_program=
cut_header_footer=
while test $# -gt 0
do
case "$1" in
@ -41,22 +31,6 @@ do
clean=t ;;
-f)
force=t ;;
--from-asciidoctor)
from_program=-asciidoctor ;;
--to-asciidoctor)
to_program=-asciidoctor ;;
--asciidoctor)
from_program=-asciidoctor
to_program=-asciidoctor ;;
--from-asciidoc)
from_program=-asciidoc ;;
--to-asciidoc)
to_program=-asciidoc ;;
--asciidoc)
from_program=-asciidoc
to_program=-asciidoc ;;
--cut-header-footer)
cut_header_footer=-cut-header-footer ;;
--)
shift; break ;;
*)
@ -105,22 +79,6 @@ then
ln -s "$dots/config.mak" "$tmp/worktree/config.mak"
fi
construct_makemanflags () {
if test "$1" = "-asciidoc"
then
echo USE_ASCIIDOCTOR=
elif test "$1" = "-asciidoctor"
then
echo USE_ASCIIDOCTOR=YesPlease
fi
}
from_makemanflags=$(construct_makemanflags "$from_program") &&
to_makemanflags=$(construct_makemanflags "$to_program") &&
from_dir=$from_oid$from_program$cut_header_footer &&
to_dir=$to_oid$to_program$cut_header_footer &&
# generate_render_makefile <srcdir> <dstdir>
generate_render_makefile () {
find "$1" -type f |
@ -136,7 +94,7 @@ generate_render_makefile () {
done
}
# render_tree <committish_oid> <directory_name> <makemanflags>
# render_tree <committish_oid>
render_tree () {
# Skip install-man entirely if we already have an installed directory.
# We can't rely on make here, since "install-man" unconditionally
@ -144,44 +102,28 @@ render_tree () {
# we then can't rely on during the render step). We use "mv" to make
# sure we don't get confused by a previous run that failed partway
# through.
oid=$1 &&
dname=$2 &&
makemanflags=$3 &&
if ! test -d "$tmp/installed/$dname"
if ! test -d "$tmp/installed/$1"
then
git -C "$tmp/worktree" checkout --detach "$oid" &&
git -C "$tmp/worktree" checkout --detach "$1" &&
make -j$parallel -C "$tmp/worktree" \
$makemanflags \
GIT_VERSION=omitted \
SOURCE_DATE_EPOCH=0 \
DESTDIR="$tmp/installed/$dname+" \
DESTDIR="$tmp/installed/$1+" \
install-man &&
mv "$tmp/installed/$dname+" "$tmp/installed/$dname"
mv "$tmp/installed/$1+" "$tmp/installed/$1"
fi &&
# As with "installed" above, we skip the render if it's already been
# done. So using make here is primarily just about running in
# parallel.
if ! test -d "$tmp/rendered/$dname"
if ! test -d "$tmp/rendered/$1"
then
generate_render_makefile "$tmp/installed/$dname" \
"$tmp/rendered/$dname+" |
generate_render_makefile "$tmp/installed/$1" "$tmp/rendered/$1+" |
make -j$parallel -f - &&
mv "$tmp/rendered/$dname+" "$tmp/rendered/$dname"
if test "$cut_header_footer" = "-cut-header-footer"
then
for f in $(find "$tmp/rendered/$dname" -type f)
do
tail -n +3 "$f" | head -n -2 |
sed -e '1{/^$/d}' -e '${/^$/d}' >"$f+" &&
mv "$f+" "$f" ||
return 1
done
fi
mv "$tmp/rendered/$1+" "$tmp/rendered/$1"
fi
}
render_tree $from_oid $from_dir $from_makemanflags &&
render_tree $to_oid $to_dir $to_makemanflags &&
git -C $tmp/rendered diff --no-index "$@" $from_dir $to_dir
render_tree $from_oid &&
render_tree $to_oid &&
git -C $tmp/rendered diff --no-index "$@" $from_oid $to_oid

View File

@ -88,10 +88,6 @@ ifndef::git-pull[]
Allow several <repository> and <group> arguments to be
specified. No <refspec>s may be specified.
--[no-]auto-gc::
Run `git gc --auto` at the end to perform garbage collection
if needed. This is enabled by default.
-p::
--prune::
Before fetching, remove any remote-tracking references that no
@ -220,24 +216,10 @@ endif::git-pull[]
--server-option=<option>::
Transmit the given string to the server when communicating using
protocol version 2. The given string must not contain a NUL or LF
character. The server's handling of server options, including
unknown ones, is server-specific.
character.
When multiple `--server-option=<option>` are given, they are all
sent to the other side in the order listed on the command line.
--show-forced-updates::
By default, git checks if a branch is force-updated during
fetch. This can be disabled through fetch.showForcedUpdates, but
the --show-forced-updates option guarantees this check occurs.
See linkgit:git-config[1].
--no-show-forced-updates::
By default, git checks if a branch is force-updated during
fetch. Pass --no-show-forced-updates or set fetch.showForcedUpdates
to false to skip this check for performance reasons. If used during
'git-pull' the --ff-only option will still check for forced updates
before attempting a fast-forward update. See linkgit:git-config[1].
-4::
--ipv4::
Use IPv4 addresses only, ignoring IPv6 addresses.

View File

@ -193,6 +193,15 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files.
for command-line options).
CONFIGURATION
-------------
The optional configuration variable `core.excludesFile` indicates a path to a
file containing patterns of file names to exclude from git-add, similar to
$GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to
those in info/exclude. See linkgit:gitignore[5].
EXAMPLES
--------

View File

@ -99,11 +99,6 @@ default. You can use `--no-utf8` to override this.
am.threeWay configuration variable. For more information,
see am.threeWay in linkgit:git-config[1].
--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::
--whitespace=<option>::

View File

@ -10,7 +10,6 @@ SYNOPSIS
[verse]
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
[-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
[--ignore-rev <rev>] [--ignore-revs-file <file>]
[--progress] [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>..<rev>]
[--] <file>

View File

@ -8,14 +8,12 @@ git-branch - List, create, or delete branches
SYNOPSIS
--------
[verse]
'git branch' [--color[=<when>] | --no-color] [--show-current]
[-v [--abbrev=<length> | --no-abbrev]]
'git branch' [--color[=<when>] | --no-color] [-r | -a]
[--list] [-v [--abbrev=<length> | --no-abbrev]]
[--column[=<options>] | --no-column] [--sort=<key>]
[(--merged | --no-merged) [<commit>]]
[--contains [<commit]] [--no-contains [<commit>]]
[--points-at <object>] [--format=<format>]
[(-r | --remotes) | (-a | --all)]
[--list] [<pattern>...]
[--points-at <object>] [--format=<format>] [<pattern>...]
'git branch' [--track | --no-track] [-f] <branchname> [<start-point>]
'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
'git branch' --unset-upstream [<branchname>]
@ -28,19 +26,13 @@ DESCRIPTION
-----------
If `--list` is given, or if there are no non-option arguments, existing
branches are listed; the current branch will be highlighted in green and
marked with an asterisk. Any branches checked out in linked worktrees will
be highlighted in cyan and marked with a plus sign. Option `-r` causes the
remote-tracking branches to be listed,
and option `-a` shows both local and remote branches.
If a `<pattern>`
branches are listed; the current branch will be highlighted with an
asterisk. Option `-r` causes the remote-tracking branches to be listed,
and option `-a` shows both local and remote branches. If a `<pattern>`
is given, it is used as a shell wildcard to restrict the output to
matching branches. If multiple patterns are given, a branch is shown if
it matches any of the patterns.
Note that when providing a
`<pattern>`, you must use `--list`; otherwise the command may be interpreted
it matches any of the patterns. Note that when providing a
`<pattern>`, you must use `--list`; otherwise the command is interpreted
as branch creation.
With `--contains`, shows only the branches that contain the named commit
@ -53,14 +45,10 @@ argument is missing it defaults to `HEAD` (i.e. the tip of the current
branch).
The command's second form creates a new branch head named <branchname>
which points to the current `HEAD`, or <start-point> if given. As a
special case, for <start-point>, you may use `"A...B"` as a shortcut for
the merge base of `A` and `B` if there is exactly one merge base. You
can leave out at most one of `A` and `B`, in which case it defaults to
`HEAD`.
which points to the current `HEAD`, or <start-point> if given.
Note that this will create the new branch, but it will not switch the
working tree to it; use "git switch <newbranch>" to switch to the
working tree to it; use "git checkout <newbranch>" to switch to the
new branch.
When a local branch is started off a remote-tracking branch, Git sets up the
@ -161,12 +149,10 @@ This option is only applicable in non-verbose mode.
-r::
--remotes::
List or delete (if used with -d) the remote-tracking branches.
Combine with `--list` to match the optional pattern(s).
-a::
--all::
List both remote-tracking branches and local branches.
Combine with `--list` to match optional pattern(s).
-l::
--list::
@ -174,20 +160,14 @@ This option is only applicable in non-verbose mode.
branch --list 'maint-*'`, list only the branches that match
the pattern(s).
--show-current::
Print the name of the current branch. In detached HEAD state,
nothing is printed.
-v::
-vv::
--verbose::
When in list mode,
show sha1 and commit subject line for each head, along with
relationship to upstream branch (if any). If given twice, print
the path of the linked worktree (if any) and the name of the upstream
branch, as well (see also `git remote show <remote>`). Note that the
current worktree's HEAD will not have its path printed (it will always
be your current directory).
the name of the upstream branch, as well (see also `git remote
show <remote>`).
-q::
--quiet::
@ -214,7 +194,7 @@ This option is only applicable in non-verbose mode.
+
This behavior 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`
want `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.
@ -313,7 +293,7 @@ Start development from a known tag::
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
$ cd my2.6
$ git branch my2.6.14 v2.6.14 <1>
$ git switch my2.6.14
$ git checkout my2.6.14
------------
+
<1> This step and the next one could be combined into a single step with
@ -334,25 +314,13 @@ $ git branch -D test <2>
<2> Delete the "test" branch even if the "master" branch (or whichever branch
is currently checked out) does not have all commits from the test branch.
Listing branches from a specific remote::
+
------------
$ git branch -r -l '<remote>/<pattern>' <1>
$ git for-each-ref 'refs/remotes/<remote>/<pattern>' <2>
------------
+
<1> Using `-a` would conflate <remote> with any local branches you happen to
have been prefixed with the same <remote> pattern.
<2> `for-each-ref` can take a wide range of options. See linkgit:git-for-each-ref[1]
Patterns will normally need quoting.
NOTES
-----
If you are creating a branch that you want to switch to immediately,
it is easier to use the "git switch" command with its `-c` option to
do the same thing with a single command.
If you are creating a branch that you want to checkout immediately, it is
easier to use the git checkout command with its `-b` option to create
a branch and check it out with a single command.
The options `--contains`, `--no-contains`, `--merged` and `--no-merged`
serve four related but different purposes:

View File

@ -88,8 +88,7 @@ but it is explicitly forbidden at the beginning of a branch name).
When run with `--branch` option in a repository, the input is first
expanded for the ``previous checkout syntax''
`@{-n}`. For example, `@{-1}` is a way to refer the last thing that
was checked out using "git switch" or "git checkout" operation.
This option should be
was checked out using "git checkout" operation. This option should be
used by porcelains to accept this syntax anywhere a branch name is
expected, so they can act as if you typed the branch name. As an
exception note that, the ``previous checkout operation'' might result

View File

@ -23,22 +23,31 @@ or the specified tree. If no paths are given, 'git checkout' will
also update `HEAD` to set the specified branch as the current
branch.
'git checkout' [<branch>]::
To prepare for working on `<branch>`, switch to it by updating
'git checkout' <branch>::
To prepare for working on <branch>, switch to it by updating
the index and the files in the working tree, and by pointing
`HEAD` at the branch. Local modifications to the files in the
HEAD at the branch. Local modifications to the files in the
working tree are kept, so that they can be committed to the
`<branch>`.
<branch>.
+
If `<branch>` is not found but there does exist a tracking branch in
exactly one remote (call it `<remote>`) with a matching name and
`--no-guess` is not specified, treat as equivalent to
If <branch> is not found but there does exist a tracking branch in
exactly one remote (call it <remote>) with a matching name, treat as
equivalent to
+
------------
$ git checkout -b <branch> --track <remote>/<branch>
------------
+
You could omit `<branch>`, in which case the command degenerates to
If the branch exists in multiple remotes and one of them is named by
the `checkout.defaultRemote` configuration variable, we'll use that
one for the purposes of disambiguation, even if the `<branch>` isn't
unique across all remotes. Set it to
e.g. `checkout.defaultRemote=origin` to always checkout remote
branches from there if `<branch>` is ambiguous but exists on the
'origin' remote. See also `checkout.defaultRemote` in
linkgit:git-config[1].
+
You could omit <branch>, in which case the command degenerates to
"check out the current branch", which is a glorified no-op with
rather expensive side-effects to show only the tracking information,
if exists, for the current branch.
@ -52,7 +61,7 @@ if exists, for the current branch.
`--track` without `-b` implies branch creation; see the
description of `--track` below.
+
If `-B` is given, `<new_branch>` is created if it doesn't exist; otherwise, it
If `-B` is given, <new_branch> is created if it doesn't exist; otherwise, it
is reset. This is the transactional equivalent of
+
------------
@ -66,25 +75,25 @@ successful.
'git checkout' --detach [<branch>]::
'git checkout' [--detach] <commit>::
Prepare to work on top of `<commit>`, by detaching `HEAD` at it
Prepare to work on top of <commit>, by detaching HEAD at it
(see "DETACHED HEAD" section), and updating the index and the
files in the working tree. Local modifications to the files
in the working tree are kept, so that the resulting working
tree will be the state recorded in the commit plus the local
modifications.
+
When the `<commit>` argument is a branch name, the `--detach` option can
be used to detach `HEAD` at the tip of the branch (`git checkout
<branch>` would check out that branch without detaching `HEAD`).
When the <commit> argument is a branch name, the `--detach` option can
be used to detach HEAD at the tip of the branch (`git checkout
<branch>` would check out that branch without detaching HEAD).
+
Omitting `<branch>` detaches `HEAD` at the tip of the current branch.
Omitting <branch> detaches HEAD at the tip of the current branch.
'git checkout' [<tree-ish>] [--] <pathspec>...::
Overwrite paths in the working tree by replacing with the
contents in the index or in the `<tree-ish>` (most often a
commit). When a `<tree-ish>` is given, the paths that
match the `<pathspec>` are updated both in the index and in
contents in the index or in the <tree-ish> (most often a
commit). When a <tree-ish> is given, the paths that
match the <pathspec> are updated both in the index and in
the working tree.
+
The index may contain unmerged entries because of a previous failed merge.
@ -109,8 +118,7 @@ OPTIONS
--quiet::
Quiet, suppress feedback messages.
--progress::
--no-progress::
--[no-]progress::
Progress status is reported on the standard error stream
by default when it is attached to a terminal, unless `--quiet`
is specified. This flag enables progress reporting even if not
@ -119,7 +127,7 @@ OPTIONS
-f::
--force::
When switching branches, proceed even if the index or the
working tree differs from `HEAD`. This is used to throw away
working tree differs from HEAD. This is used to throw away
local changes.
+
When checking out paths from the index, do not fail upon unmerged
@ -146,12 +154,12 @@ on your side branch as `theirs` (i.e. "one contributor's work on top
of it").
-b <new_branch>::
Create a new branch named `<new_branch>` and start it at
`<start_point>`; see linkgit:git-branch[1] for details.
Create a new branch named <new_branch> and start it at
<start_point>; see linkgit:git-branch[1] for details.
-B <new_branch>::
Creates the branch `<new_branch>` and start it at `<start_point>`;
if it already exists, then reset it to `<start_point>`. This is
Creates the branch <new_branch> and start it at <start_point>;
if it already exists, then reset it to <start_point>. This is
equivalent to running "git branch" with "-f"; see
linkgit:git-branch[1] for details.
@ -164,36 +172,15 @@ If no `-b` option is given, the name of the new branch will be
derived from the remote-tracking branch, by looking at the local part of
the refspec configured for the corresponding remote, and then stripping
the initial part up to the "*".
This would tell us to use `hack` as the local branch when branching
off of `origin/hack` (or `remotes/origin/hack`, or even
`refs/remotes/origin/hack`). If the given name has no slash, or the above
This would tell us to use "hack" as the local branch when branching
off of "origin/hack" (or "remotes/origin/hack", or even
"refs/remotes/origin/hack"). If the given name has no slash, or the above
guessing results in an empty name, the guessing is aborted. You can
explicitly give a name with `-b` in such a case.
--no-track::
Do not set up "upstream" configuration, even if the
`branch.autoSetupMerge` configuration variable is true.
--guess::
--no-guess::
If `<branch>` is not found but there does exist a tracking
branch in exactly one remote (call it `<remote>`) with a
matching name, treat as equivalent to
+
------------
$ git checkout -b <branch> --track <remote>/<branch>
------------
+
If the branch exists in multiple remotes and one of them is named by
the `checkout.defaultRemote` configuration variable, we'll use that
one for the purposes of disambiguation, even if the `<branch>` isn't
unique across all remotes. Set it to
e.g. `checkout.defaultRemote=origin` to always checkout remote
branches from there if `<branch>` is ambiguous but exists on the
'origin' remote. See also `checkout.defaultRemote` in
linkgit:git-config[1].
+
Use `--no-guess` to disable this.
branch.autoSetupMerge configuration variable is true.
-l::
Create the new branch's reflog; see linkgit:git-branch[1] for
@ -202,21 +189,21 @@ Use `--no-guess` to disable this.
--detach::
Rather than checking out a branch to work on it, check out a
commit for inspection and discardable experiments.
This is the default behavior of `git checkout <commit>` when
`<commit>` is not a branch name. See the "DETACHED HEAD" section
This is the default behavior of "git checkout <commit>" when
<commit> is not a branch name. See the "DETACHED HEAD" section
below for details.
--orphan <new_branch>::
Create a new 'orphan' branch, named `<new_branch>`, started from
`<start_point>` and switch to it. The first commit made on this
Create a new 'orphan' branch, named <new_branch>, started from
<start_point> and switch to it. The first commit made on this
new branch will have no parents and it will be the root of a new
history totally disconnected from all the other branches and
commits.
+
The index and the working tree are adjusted as if you had previously run
`git checkout <start_point>`. This allows you to start a new history
that records a set of paths similar to `<start_point>` by easily running
`git commit -a` to make the root commit.
"git checkout <start_point>". This allows you to start a new history
that records a set of paths similar to <start_point> by easily running
"git commit -a" to make the root commit.
+
This can be useful when you want to publish the tree from a commit
without exposing its full history. You might want to do this to publish
@ -225,17 +212,17 @@ whose full history contains proprietary or otherwise encumbered bits of
code.
+
If you want to start a disconnected history that records a set of paths
that is totally different from the one of `<start_point>`, then you should
that is totally different from the one of <start_point>, then you should
clear the index and the working tree right after creating the orphan
branch by running `git rm -rf .` from the top level of the working tree.
branch by running "git rm -rf ." from the top level of the working tree.
Afterwards you will be ready to prepare your new files, repopulating the
working tree, by copying them from elsewhere, extracting a tarball, etc.
--ignore-skip-worktree-bits::
In sparse checkout mode, `git checkout -- <paths>` would
update only entries matched by `<paths>` and sparse patterns
in `$GIT_DIR/info/sparse-checkout`. This option ignores
the sparse patterns and adds back any files in `<paths>`.
update only entries matched by <paths> and sparse patterns
in $GIT_DIR/info/sparse-checkout. This option ignores
the sparse patterns and adds back any files in <paths>.
-m::
--merge::
@ -255,29 +242,24 @@ should result in deletion of the path).
+
When checking out paths from the index, this option lets you recreate
the conflicted merge in the specified paths.
+
When switching branches with `--merge`, staged changes may be lost.
--conflict=<style>::
The same as `--merge` option above, but changes the way the
The same as --merge option above, but changes the way the
conflicting hunks are presented, overriding the
`merge.conflictStyle` configuration variable. Possible values are
merge.conflictStyle configuration variable. Possible values are
"merge" (default) and "diff3" (in addition to what is shown by
"merge" style, shows the original contents).
-p::
--patch::
Interactively select hunks in the difference between the
`<tree-ish>` (or the index, if unspecified) and the working
<tree-ish> (or the index, if unspecified) and the working
tree. The chosen hunks are then applied in reverse to the
working tree (and if a `<tree-ish>` was specified, the index).
working tree (and if a <tree-ish> was specified, the index).
+
This means that you can use `git checkout -p` to selectively discard
edits from your current working tree. See the ``Interactive Mode''
section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
+
Note that this option uses the no overlay mode by default (see also
`--overlay`), and currently doesn't support overlay mode.
--ignore-other-worktrees::
`git checkout` refuses when the wanted ref is already checked
@ -285,42 +267,31 @@ Note that this option uses the no overlay mode by default (see also
out anyway. In other words, the ref can be held by more than one
worktree.
--overwrite-ignore::
--no-overwrite-ignore::
Silently overwrite ignored files when switching branches. This
is the default behavior. Use `--no-overwrite-ignore` to abort
the operation when the new branch contains ignored files.
--recurse-submodules::
--no-recurse-submodules::
Using `--recurse-submodules` will update the content of all initialized
--[no-]recurse-submodules::
Using --recurse-submodules will update the content of all initialized
submodules according to the commit recorded in the superproject. If
local modifications in a submodule would be overwritten the checkout
will fail unless `-f` is used. If nothing (or `--no-recurse-submodules`)
will fail unless `-f` is used. If nothing (or --no-recurse-submodules)
is used, the work trees of submodules will not be updated.
Just like linkgit:git-submodule[1], this will detach `HEAD` of the
submodule.
Just like linkgit:git-submodule[1], this will detach the
submodules HEAD.
--overlay::
--no-overlay::
In the default overlay mode, `git checkout` never
removes files from the index or the working tree. When
specifying `--no-overlay`, files that appear in the index and
working tree, but not in `<tree-ish>` are removed, to make them
match `<tree-ish>` exactly.
--no-guess::
Do not attempt to create a branch if a remote tracking branch
of the same name exists.
<branch>::
Branch to checkout; if it refers to a branch (i.e., a name that,
when prepended with "refs/heads/", is a valid ref), then that
branch is checked out. Otherwise, if it refers to a valid
commit, your `HEAD` becomes "detached" and you are no longer on
commit, your HEAD becomes "detached" and you are no longer on
any branch (see below for details).
+
You can use the `@{-N}` syntax to refer to the N-th last
You can use the `"@{-N}"` syntax to refer to the N-th last
branch/commit checked out using "git checkout" operation. You may
also specify `-` which is synonymous to `@{-1}`.
also specify `-` which is synonymous to `"@{-1}"`.
+
As a special case, you may use `A...B` as a shortcut for the
As a special case, you may use `"A...B"` as a shortcut for the
merge base of `A` and `B` if there is exactly one merge base. You can
leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
@ -329,11 +300,7 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
<start_point>::
The name of a commit at which to start the new branch; see
linkgit:git-branch[1] for details. Defaults to `HEAD`.
+
As a special case, you may use `"A...B"` as a shortcut for the
merge base of `A` and `B` if there is exactly one merge base. You can
leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
linkgit:git-branch[1] for details. Defaults to HEAD.
<tree-ish>::
Tree to checkout from (when paths are given). If not specified,
@ -343,9 +310,9 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
DETACHED HEAD
-------------
`HEAD` normally refers to a named branch (e.g. `master`). Meanwhile, each
HEAD normally refers to a named branch (e.g. 'master'). Meanwhile, each
branch refers to a specific commit. Let's look at a repo with three
commits, one of them tagged, and with branch `master` checked out:
commits, one of them tagged, and with branch 'master' checked out:
------------
HEAD (refers to branch 'master')
@ -358,10 +325,10 @@ a---b---c branch 'master' (refers to commit 'c')
------------
When a commit is created in this state, the branch is updated to refer to
the new commit. Specifically, 'git commit' creates a new commit `d`, whose
parent is commit `c`, and then updates branch `master` to refer to new
commit `d`. `HEAD` still refers to branch `master` and so indirectly now refers
to commit `d`:
the new commit. Specifically, 'git commit' creates a new commit 'd', whose
parent is commit 'c', and then updates branch 'master' to refer to new
commit 'd'. HEAD still refers to branch 'master' and so indirectly now refers
to commit 'd':
------------
$ edit; git add; git commit
@ -378,7 +345,7 @@ a---b---c---d branch 'master' (refers to commit 'd')
It is sometimes useful to be able to checkout a commit that is not at
the tip of any named branch, or even to create a new commit that is not
referenced by a named branch. Let's look at what happens when we
checkout commit `b` (here we show two ways this may be done):
checkout commit 'b' (here we show two ways this may be done):
------------
$ git checkout v2.0 # or
@ -393,9 +360,9 @@ a---b---c---d branch 'master' (refers to commit 'd')
tag 'v2.0' (refers to commit 'b')
------------
Notice that regardless of which checkout command we use, `HEAD` now refers
directly to commit `b`. This is known as being in detached `HEAD` state.
It means simply that `HEAD` refers to a specific commit, as opposed to
Notice that regardless of which checkout command we use, HEAD now refers
directly to commit 'b'. This is known as being in detached HEAD state.
It means simply that HEAD refers to a specific commit, as opposed to
referring to a named branch. Let's see what happens when we create a commit:
------------
@ -412,7 +379,7 @@ a---b---c---d branch 'master' (refers to commit 'd')
tag 'v2.0' (refers to commit 'b')
------------
There is now a new commit `e`, but it is referenced only by `HEAD`. We can
There is now a new commit 'e', but it is referenced only by HEAD. We can
of course add yet another commit in this state:
------------
@ -430,7 +397,7 @@ a---b---c---d branch 'master' (refers to commit 'd')
------------
In fact, we can perform all the normal Git operations. But, let's look
at what happens when we then checkout `master`:
at what happens when we then checkout master:
------------
$ git checkout master
@ -445,9 +412,9 @@ a---b---c---d branch 'master' (refers to commit 'd')
------------
It is important to realize that at this point nothing refers to commit
`f`. Eventually commit `f` (and by extension commit `e`) will be deleted
'f'. Eventually commit 'f' (and by extension commit 'e') will be deleted
by the routine Git garbage collection process, unless we create a reference
before that happens. If we have not yet moved away from commit `f`,
before that happens. If we have not yet moved away from commit 'f',
any of these will create a reference to it:
------------
@ -456,19 +423,19 @@ $ git branch foo <2>
$ git tag foo <3>
------------
<1> creates a new branch `foo`, which refers to commit `f`, and then
updates `HEAD` to refer to branch `foo`. In other words, we'll no longer
be in detached `HEAD` state after this command.
<1> creates a new branch 'foo', which refers to commit 'f', and then
updates HEAD to refer to branch 'foo'. In other words, we'll no longer
be in detached HEAD state after this command.
<2> similarly creates a new branch `foo`, which refers to commit `f`,
but leaves `HEAD` detached.
<2> similarly creates a new branch 'foo', which refers to commit 'f',
but leaves HEAD detached.
<3> creates a new tag `foo`, which refers to commit `f`,
leaving `HEAD` detached.
<3> creates a new tag 'foo', which refers to commit 'f',
leaving HEAD detached.
If we have moved away from commit `f`, then we must first recover its object
If we have moved away from commit 'f', then we must first recover its object
name (typically by using git reflog), and then we can create a reference to
it. For example, to see the last two commits to which `HEAD` referred, we
it. For example, to see the last two commits to which HEAD referred, we
can use either of these commands:
------------
@ -479,12 +446,12 @@ $ git log -g -2 HEAD
ARGUMENT DISAMBIGUATION
-----------------------
When there is only one argument given and it is not `--` (e.g. `git
checkout abc`), and when the argument is both a valid `<tree-ish>`
(e.g. a branch `abc` exists) and a valid `<pathspec>` (e.g. a file
When there is only one argument given and it is not `--` (e.g. "git
checkout abc"), and when the argument is both a valid `<tree-ish>`
(e.g. a branch "abc" exists) and a valid `<pathspec>` (e.g. a file
or a directory whose name is "abc" exists), Git would usually ask
you to disambiguate. Because checking out a branch is so common an
operation, however, `git checkout abc` takes "abc" as a `<tree-ish>`
operation, however, "git checkout abc" takes "abc" as a `<tree-ish>`
in such a situation. Use `git checkout -- <pathspec>` if you want
to checkout these paths out of the index.
@ -492,7 +459,7 @@ EXAMPLES
--------
. The following sequence checks out the `master` branch, reverts
the `Makefile` to two revisions back, deletes `hello.c` by
the `Makefile` to two revisions back, deletes hello.c by
mistake, and gets it back from the index.
+
------------
@ -504,7 +471,7 @@ $ git checkout hello.c <3>
+
<1> switch branch
<2> take a file out of another commit
<3> restore `hello.c` from the index
<3> restore hello.c from the index
+
If you want to check out _all_ C source files out of the index,
you can say
@ -533,7 +500,7 @@ $ git checkout -- hello.c
$ git checkout mytopic
------------
+
However, your "wrong" branch and correct `mytopic` branch may
However, your "wrong" branch and correct "mytopic" branch may
differ in files that you have modified locally, in which case
the above checkout would fail like this:
+
@ -574,11 +541,6 @@ $ edit frotz
$ git add frotz
------------
SEE ALSO
--------
linkgit:git-switch[1],
linkgit:git-restore[1]
GIT
---
Part of the linkgit:git[1] suite

View File

@ -10,7 +10,9 @@ SYNOPSIS
[verse]
'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]
[-S[<keyid>]] <commit>...
'git cherry-pick' (--continue | --skip | --abort | --quit)
'git cherry-pick' --continue
'git cherry-pick' --quit
'git cherry-pick' --abort
DESCRIPTION
-----------
@ -55,13 +57,6 @@ OPTIONS
With this option, 'git cherry-pick' will let you edit the commit
message prior to committing.
--cleanup=<mode>::
This option determines how the commit message will be cleaned up before
being passed on to the commit machinery. See linkgit:git-commit[1] for more
details. In particular, if the '<mode>' is given a value of `scissors`,
scissors will be appended to `MERGE_MSG` before being passed on in the case
of a conflict.
-x::
When recording the commit, append a line that says
"(cherry picked from commit ...)" to the original commit
@ -153,11 +148,6 @@ 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.
--rerere-autoupdate::
--no-rerere-autoupdate::
Allow the rerere mechanism to update the index with the
result of auto-conflict resolution if possible.
SEQUENCER SUBCOMMANDS
---------------------
include::sequencer.txt[]

View File

@ -55,15 +55,16 @@ OPTIONS
-e <pattern>::
--exclude=<pattern>::
Use the given exclude pattern in addition to the standard ignore rules
(see linkgit:gitignore[5]).
In addition to those found in .gitignore (per directory) and
$GIT_DIR/info/exclude, also consider these patterns to be in the
set of the ignore rules in effect.
-x::
Don't use the standard ignore rules (see linkgit:gitignore[5]), but
still use the ignore rules given with `-e` options from the command
line. This allows removing all untracked
Don't use the standard ignore rules read from .gitignore (per
directory) and $GIT_DIR/info/exclude, but do still use the ignore
rules given with `-e` options. This allows removing all untracked
files, including build products. This can be used (possibly in
conjunction with 'git restore' or 'git reset') to create a pristine
conjunction with 'git reset') to create a pristine
working directory to test a clean build.
-X::

View File

@ -15,15 +15,14 @@ SYNOPSIS
[--dissociate] [--separate-git-dir <git dir>]
[--depth <depth>] [--[no-]single-branch] [--no-tags]
[--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
[--[no-]remote-submodules] [--jobs <n>] [--] <repository>
[<directory>]
[--jobs <n>] [--] <repository> [<directory>]
DESCRIPTION
-----------
Clones a repository into a newly created directory, creates
remote-tracking branches for each branch in the cloned repository
(visible using `git branch --remotes`), and creates and checks out an
(visible using `git branch -r`), and creates and checks out an
initial branch that is forked from the cloned repository's
currently active branch.
@ -41,8 +40,8 @@ configuration variables.
OPTIONS
-------
-l::
--local::
-l::
When the repository to clone from is on a local machine,
this flag bypasses the normal "Git aware" transport
mechanism and clones the repository by making a copy of
@ -63,8 +62,8 @@ Git transport instead.
directory instead of using hardlinks. This may be desirable
if you are trying to make a back-up of your repository.
-s::
--shared::
-s::
When the repository to clone is on the local machine,
instead of using hard links, automatically setup
`.git/objects/info/alternates` to share the objects
@ -81,13 +80,13 @@ which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
If these objects are removed and were referenced by the cloned repository,
then the cloned repository will become corrupt.
+
Note that running `git repack` without the `--local` option in a repository
cloned with `--shared` will copy objects from the source repository into a pack
in the cloned repository, removing the disk space savings of `clone --shared`.
It is safe, however, to run `git gc`, which uses the `--local` option by
Note that running `git repack` without the `-l` option in a repository
cloned with `-s` will copy objects from the source repository into a pack
in the cloned repository, removing the disk space savings of `clone -s`.
It is safe, however, to run `git gc`, which uses the `-l` option by
default.
+
If you want to break the dependency of a repository cloned with `--shared` on
If you want to break the dependency of a repository cloned with `-s` on
its source repository, you can simply run `git repack -a` to copy all
objects from the source repository into a pack in the cloned repository.
@ -116,39 +115,31 @@ objects from the source repository into a pack in the cloned repository.
same repository, and this option can be used to stop the
borrowing.
-q::
--quiet::
-q::
Operate quietly. Progress is not reported to the standard
error stream.
-v::
--verbose::
-v::
Run verbosely. Does not affect the reporting of progress status
to the standard error stream.
--progress::
Progress status is reported on the standard error stream
by default when it is attached to a terminal, unless `--quiet`
by default when it is attached to a terminal, unless -q
is specified. This flag forces progress status even if the
standard error stream is not directed to a terminal.
--server-option=<option>::
Transmit the given string to the server when communicating using
protocol version 2. The given string must not contain a NUL or LF
character. The server's handling of server options, including
unknown ones, is server-specific.
When multiple `--server-option=<option>` are given, they are all
sent to the other side in the order listed on the command line.
-n::
--no-checkout::
-n::
No checkout of HEAD is performed after the clone is complete.
--bare::
Make a 'bare' Git repository. That is, instead of
creating `<directory>` and placing the administrative
files in `<directory>/.git`, make the `<directory>`
itself the `$GIT_DIR`. This obviously implies the `--no-checkout`
itself the `$GIT_DIR`. This obviously implies the `-n`
because there is nowhere to check out the working tree.
Also the branch heads at the remote are copied directly
to corresponding local branch heads, without mapping
@ -164,13 +155,13 @@ objects from the source repository into a pack in the cloned repository.
that all these refs are overwritten by a `git remote update` in the
target repository.
-o <name>::
--origin <name>::
-o <name>::
Instead of using the remote name `origin` to keep track
of the upstream repository, use `<name>`.
-b <name>::
--branch <name>::
-b <name>::
Instead of pointing the newly created HEAD to the branch pointed
to by the cloned repository's HEAD, point to `<name>` branch
instead. In a non-bare repository, this is the branch that will
@ -178,8 +169,8 @@ objects from the source repository into a pack in the cloned repository.
`--branch` can also take tags and detaches the HEAD at that commit
in the resulting repository.
-u <upload-pack>::
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is accessed
via ssh, this specifies a non-default path for the command
run on the other end.
@ -188,8 +179,8 @@ objects from the source repository into a pack in the cloned repository.
Specify the directory from which templates will be used;
(See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
-c <key>=<value>::
--config <key>=<value>::
-c <key>=<value>::
Set a configuration variable in the newly-created repository;
this takes effect immediately after the repository is
initialized, but before the remote history is fetched or any
@ -261,12 +252,6 @@ or `--mirror` is given)
--[no-]shallow-submodules::
All submodules which are cloned will be shallow with a depth of 1.
--[no-]remote-submodules::
All submodules which are cloned will use the status of the submodules
remote-tracking branch to update the submodule, rather than the
superprojects recorded SHA-1. Equivalent to passing `--remote` to
`git submodule update`.
--separate-git-dir=<git dir>::
Instead of placing the cloned repository where it is supposed
to be, place the cloned repository at the specified directory,

View File

@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git commit-graph read' [--object-dir <dir>]
'git commit-graph verify' [--object-dir <dir>] [--shallow]
'git commit-graph verify' [--object-dir <dir>]
'git commit-graph write' <options> [--object-dir <dir>]
@ -26,7 +26,7 @@ OPTIONS
Use given directory for the location of packfiles and commit-graph
file. This parameter exists to specify the location of an alternate
that only has the objects directory, not a full `.git` directory. The
commit-graph file is expected to be in the `<dir>/info` directory and
commit-graph file is expected to be at `<dir>/info/commit-graph` and
the packfiles are expected to be in `<dir>/pack`.
@ -51,25 +51,6 @@ or `--stdin-packs`.)
+
With the `--append` option, include all commits that are present in the
existing commit-graph file.
+
With the `--split` option, write the commit-graph as a chain of multiple
commit-graph files stored in `<dir>/info/commit-graphs`. The new commits
not already in the commit-graph are added in a new "tip" file. This file
is merged with the existing file if the following merge conditions are
met:
+
* If `--size-multiple=<X>` is not specified, let `X` equal 2. If the new
tip file would have `N` commits and the previous tip has `M` commits and
`X` times `N` is greater than `M`, instead merge the two files into a
single file.
+
* If `--max-commits=<M>` is specified with `M` a positive integer, and the
new tip file would have more than `M` commits, then instead merge the new
tip with the previous tip.
+
Finally, if `--expire-time=<datetime>` is not specified, let `datetime`
be the current time. After writing the split commit-graph, delete all
unused commit-graph whose modified times are older than `datetime`.
'read'::
@ -80,9 +61,6 @@ Used for debugging purposes.
Read the commit-graph file and verify its contents against the object
database. Used to check for corrupted data.
+
With the `--shallow` option, only check the tip commit-graph file in
a chain of split commit-graphs.
EXAMPLES

View File

@ -23,10 +23,6 @@ Creates a new commit object based on the provided tree object and
emits the new commit object id on stdout. The log message is read
from the standard input, unless `-m` or `-F` options are given.
The `-m` and `-F` options can be given any number of times, in any
order. The commit log message will be composed in the order in which
the options are given.
A commit object may have any number of parents. With exactly one
parent, it is an ordinary commit. Having more than one parent makes
the commit a merge between several lines of history. Initial (root)
@ -45,7 +41,7 @@ state was.
OPTIONS
-------
<tree>::
An existing tree object.
An existing tree object
-p <parent>::
Each `-p` indicates the id of a parent commit object.
@ -56,8 +52,7 @@ OPTIONS
-F <file>::
Read the commit log message from the given file. Use `-` to read
from the standard input. This can be given more than once and the
content of each file becomes its own paragraph.
from the standard input.
-S[<keyid>]::
--gpg-sign[=<keyid>]::

View File

@ -359,7 +359,7 @@ When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
called the "index" with 'git add'. A file can be
reverted back, only in the index but not in the working tree,
to that of the last commit with `git restore --staged <file>`,
to that of the last commit with `git reset HEAD -- <file>`,
which effectively reverts 'git add' and prevents the changes to
this file from participating in the next commit. After building
the state to be committed incrementally with these commands,

View File

@ -126,7 +126,7 @@ See also <<FILES>>.
--local::
For writing options: write to the repository `.git/config` file.
This is the default behavior.
This is the default behavior.
+
For reading options: read only from the repository `.git/config` rather than
from all available files.
@ -240,9 +240,7 @@ Valid `<type>`'s include:
output. The optional `default` parameter is used instead, if
there is no color configured for `name`.
+
`--type=color [--default=<default>]` is preferred over `--get-color`
(but note that `--get-color` will omit the trailing newline printed by
`--type=color`).
`--type=color [--default=<default>]` is preferred over `--get-color`.
-e::
--edit::

View File

@ -57,7 +57,7 @@ OPTIONS
This is sort of "Git root" - if you run 'git daemon' with
'--base-path=/srv/git' on example.com, then if you later try to pull
'git://example.com/hello.git', 'git daemon' will interpret the path
as `/srv/git/hello.git`.
as '/srv/git/hello.git'.
--base-path-relaxed::
If --base-path is enabled and repo lookup fails, with this option

View File

@ -139,7 +139,7 @@ at the end.
The number of additional commits is the number
of commits which would be displayed by "git log v1.0.4..parent".
The hash suffix is "-g" + unambiguous abbreviation for the tip commit
The hash suffix is "-g" + 7-char abbreviation for the tip commit
of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
The "g" prefix stands for "git" and is used to allow describing the version of
a software depending on the SCM the software is managed with. This is useful

View File

@ -10,8 +10,8 @@ SYNOPSIS
--------
[verse]
'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
[-t] [-r] [-c | --cc] [--combined-all-paths] [--root]
[<common diff options>] <tree-ish> [<tree-ish>] [<path>...]
[-t] [-r] [-c | --cc] [--root] [<common diff options>]
<tree-ish> [<tree-ish>] [<path>...]
DESCRIPTION
-----------
@ -105,20 +105,12 @@ include::pretty-options.txt[]
itself and the commit log message is not shown, just like in any other
"empty diff" case.
--combined-all-paths::
This flag causes combined diffs (used for merge commits) to
list the name of the file from all parents. It thus only has
effect when -c or --cc are specified, and is likely only
useful if filename changes are detected (i.e. when either
rename or copy detection have been requested).
--always::
Show the commit itself and the commit log message even
if the diff itself is empty.
include::pretty-formats.txt[]
include::diff-format.txt[]
GIT

View File

@ -90,9 +90,7 @@ instead. `--no-symlinks` is the default on Windows.
When 'git-difftool' is invoked with the `-g` or `--gui` option
the default diff tool will be read from the configured
`diff.guitool` variable instead of `diff.tool`. The `--no-gui`
option can be used to override this setting. If `diff.guitool`
is not set, we will fallback in the order of `merge.guitool`,
`diff.tool`, `merge.tool` until a tool is found.
option can be used to override this setting.
--[no-]trust-exit-code::
'git-difftool' invokes a diff tool individually on each file.

View File

@ -129,13 +129,6 @@ marks the same across runs.
for intermediary filters (e.g. for rewriting commit messages
which refer to older commits, or for stripping blobs by id).
--reencode=(yes|no|abort)::
Specify how to handle `encoding` header in commit objects. When
asking to 'abort' (which is the default), this program will die
when encountering such a commit object. With 'yes', the commit
message will be reencoded into UTF-8. With 'no', the original
encoding will be preserved.
--refspec::
Apply the specified refspec to each ref exported. Multiple of them can
be specified.

View File

@ -51,6 +51,21 @@ OPTIONS
memory used by fast-import during this run. Showing this output
is currently the default, but can be disabled with --quiet.
--allow-unsafe-features::
Many command-line options can be provided as part of the
fast-import stream itself by using the `feature` or `option`
commands. However, some of these options are unsafe (e.g.,
allowing fast-import to access the filesystem outside of the
repository). These options are disabled by default, but can be
allowed by providing this option on the command line. This
currently impacts only the `export-marks`, `import-marks`, and
`import-marks-if-exists` feature commands.
+
Only enable this option if you trust the program generating the
fast-import stream! This option is enabled automatically for
remote-helpers that use the `import` capability, as they are
already trusted to run their own code.
Options for Frontends
~~~~~~~~~~~~~~~~~~~~~
@ -388,7 +403,6 @@ change to the project.
original-oid?
('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
'committer' (SP <name>)? SP LT <email> GT SP <when> LF
('encoding' SP <encoding>)?
data
('from' SP <commit-ish> LF)?
('merge' SP <commit-ish> LF)?
@ -423,12 +437,7 @@ However it is recommended that a `filedeleteall` command precede
all `filemodify`, `filecopy`, `filerename` and `notemodify` commands in
the same commit, as `filedeleteall` wipes the branch clean (see below).
The `LF` after the command is optional (it used to be required). Note
that for reasons of backward compatibility, if the commit ends with a
`data` command (i.e. it has has no `from`, `merge`, `filemodify`,
`filedelete`, `filecopy`, `filerename`, `filedeleteall` or
`notemodify` commands) then two `LF` commands may appear at the end of
the command instead of just one.
The `LF` after the command is optional (it used to be required).
`author`
^^^^^^^^
@ -456,12 +465,6 @@ that was selected by the --date-format=<fmt> command-line option.
See ``Date Formats'' above for the set of supported formats, and
their syntax.
`encoding`
^^^^^^^^^^
The optional `encoding` command indicates the encoding of the commit
message. Most commits are UTF-8 and the encoding is omitted, but this
allows importing commit messages into git without first reencoding them.
`from`
^^^^^^
The `from` command is used to specify the commit to initialize
@ -978,6 +981,10 @@ might want to refer to in their commit messages.
'get-mark' SP ':' <idnum> LF
....
This command can be used anywhere in the stream that comments are
accepted. In particular, the `get-mark` command can be used in the
middle of a commit but not in the middle of a `data` command.
See ``Responses To Commands'' below for details about how to read
this output safely.
@ -1004,10 +1011,9 @@ Output uses the same format as `git cat-file --batch`:
<contents> LF
====
This command can be used where a `filemodify` directive can appear,
allowing it to be used in the middle of a commit. For a `filemodify`
using an inline directive, it can also appear right before the `data`
directive.
This command can be used anywhere in the stream that comments are
accepted. In particular, the `cat-blob` command can be used in the
middle of a commit but not in the middle of a `data` command.
See ``Responses To Commands'' below for details about how to read
this output safely.
@ -1020,8 +1026,8 @@ printing a blob from the active commit (with `cat-blob`) or copying a
blob or tree from a previous commit for use in the current one (with
`filemodify`).
The `ls` command can also be used where a `filemodify` directive can
appear, allowing it to be used in the middle of a commit.
The `ls` command can be used anywhere in the stream that comments are
accepted, including the middle of a commit.
Reading from the active commit::
This form can only be used in the middle of a `commit`.
@ -1405,13 +1411,6 @@ deltas are suboptimal (see above) then also adding the `-f` option
to force recomputation of all deltas can significantly reduce the
final packfile size (30-50% smaller can be quite typical).
Instead of running `git repack` you can also run `git gc
--aggressive`, which will also optimize other things after an import
(e.g. pack loose refs). As noted in the "AGGRESSIVE" section in
linkgit:git-gc[1] the `--aggressive` option will find new deltas with
the `-f` option to linkgit:git-repack[1]. For the reasons elaborated
on above using `--aggressive` after a fast-import is one of the few
cases where it's known to be worthwhile.
MEMORY UTILIZATION
------------------

View File

@ -189,7 +189,7 @@ to other tags will be rewritten to point to the underlying commit.
rewriting. When applying a tree filter, the command needs to
temporarily check out the tree to some directory, which may consume
considerable space in case of large projects. By default it
does this in the `.git-rewrite/` directory but you can override
does this in the '.git-rewrite/' directory but you can override
that choice by this parameter.
-f::

View File

@ -214,11 +214,6 @@ symref::
`:lstrip` and `:rstrip` options in the same way as `refname`
above.
worktreepath::
The absolute path to the worktree in which the ref is checked
out, if it is checked out in any linked worktree. Empty string
otherwise.
In addition to the above, for commit and tag objects, the header
field names (`tree`, `parent`, `object`, `type`, and `tag`) can
be used to specify the value in the header field.

View File

@ -22,8 +22,7 @@ SYNOPSIS
[--rfc] [--subject-prefix=Subject-Prefix]
[(--reroll-count|-v) <n>]
[--to=<email>] [--cc=<email>]
[--[no-]cover-letter] [--quiet]
[--no-notes | --notes[=<ref>]]
[--[no-]cover-letter] [--quiet] [--notes[=<ref>]]
[--interdiff=<previous>]
[--range-diff=<previous> [--creation-factor=<percent>]]
[--progress]
@ -264,7 +263,6 @@ material (this may change in the future).
for details.
--notes[=<ref>]::
--no-notes::
Append the notes (see linkgit:git-notes[1]) for the commit
after the three-dash line.
+
@ -275,9 +273,6 @@ these explanations after `format-patch` has run but before sending,
keeping them as Git notes allows them to be maintained between versions
of the patch series (but see the discussion of the `notes.rewrite`
configuration options in linkgit:git-notes[1] to use this workflow).
+
The default is `--no-notes`, unless the `format.notes` configuration is
set.
--[no-]signature=<signature>::
Add a signature to each message produced. Per RFC 3676 the signature
@ -426,8 +421,8 @@ One way to test if your MUA is set up correctly is:
* Apply it:
$ git fetch <project> master:test-apply
$ git switch test-apply
$ git restore --source=HEAD --staged --worktree :/
$ git checkout test-apply
$ git reset --hard
$ git am a.patch
If it does not apply correctly, there can be various reasons.

View File

@ -62,17 +62,9 @@ index file, all SHA-1 references in `refs` namespace, and all reflogs
with --no-full.
--connectivity-only::
Check only the connectivity of reachable objects, making sure
that any objects referenced by a reachable tag, commit, or tree
is present. This speeds up the operation by avoiding reading
blobs entirely (though it does still check that referenced blobs
exist). This will detect corruption in commits and trees, but
not do any semantic checks (e.g., for format errors). Corruption
in blob objects will not be detected at all.
+
Unreachable tags, commits, and trees will also be accessed to find the
tips of dangling segments of history. Use `--no-dangling` if you don't
care about this output and want to speed it up further.
Check only the connectivity of tags, commits and tree objects. By
avoiding to unpack blobs, this speeds up the operation, at the
expense of missing corrupt objects or other problematic issues.
--strict::
Enable more strict checking, namely to catch a file mode

View File

@ -20,16 +20,17 @@ created from prior invocations of 'git add', packing refs, pruning
reflog, rerere metadata or stale working trees. May also update ancillary
indexes such as the commit-graph.
When common porcelain operations that create objects are run, they
will check whether the repository has grown substantially since the
last maintenance, and if so run `git gc` automatically. See `gc.auto`
below for how to disable this behavior.
Users are encouraged to run this task on a regular basis within
each repository to maintain good disk space utilization and good
operating performance.
Running `git gc` manually should only be needed when adding objects to
a repository without regularly running such porcelain commands, to do
a one-off repository optimization, or e.g. to clean up a suboptimal
mass-import. See the "PACKFILE OPTIMIZATION" section in
linkgit:git-fast-import[1] for more details on the import case.
Some git commands may automatically run 'git gc'; see the `--auto` flag
below for details. If you know what you're doing and all you want is to
disable this behavior permanently without further considerations, just do:
----------------------
$ git config --global gc.auto 0
----------------------
OPTIONS
-------
@ -39,17 +40,35 @@ OPTIONS
space utilization and performance. This option will cause
'git gc' to more aggressively optimize the repository at the expense
of taking much more time. The effects of this optimization are
mostly persistent. See the "AGGRESSIVE" section below for details.
persistent, so this option only needs to be used occasionally; every
few hundred changesets or so.
--auto::
With this option, 'git gc' checks whether any housekeeping is
required; if not, it exits without performing any work.
Some git commands run `git gc --auto` after performing
operations that could create many loose objects. Housekeeping
is required if there are too many loose objects or too many
packs in the repository.
+
See the `gc.auto` option in the "CONFIGURATION" section below for how
this heuristic works.
If the number of loose objects exceeds the value of the `gc.auto`
configuration variable, then all loose objects are combined into a
single pack using `git repack -d -l`. Setting the value of `gc.auto`
to 0 disables automatic packing of loose objects.
+
Once housekeeping is triggered by exceeding the limits of
configuration options such as `gc.auto` and `gc.autoPackLimit`, all
If the number of packs exceeds the value of `gc.autoPackLimit`,
then existing packs (except those marked with a `.keep` file
or over `gc.bigPackThreshold` limit)
are consolidated into a single pack by using the `-A` option of
'git repack'.
If the amount of memory is estimated not enough for `git repack` to
run smoothly and `gc.bigPackThreshold` is not set, the largest
pack will also be excluded (this is the equivalent of running `git gc`
with `--keep-base-pack`).
Setting `gc.autoPackLimit` to 0 disables automatic consolidation of
packs.
+
If houskeeping is required due to many loose objects or packs, all
other housekeeping tasks (e.g. rerere, working trees, reflog...) will
be performed as well.
@ -57,7 +76,7 @@ be performed as well.
--prune=<date>::
Prune loose objects older than date (default is 2 weeks ago,
overridable by the config variable `gc.pruneExpire`).
--prune=now prunes loose objects regardless of their age and
--prune=all prunes loose objects regardless of their age and
increases the risk of corruption if another process is writing to
the repository concurrently; see "NOTES" below. --prune is on by
default.
@ -77,39 +96,69 @@ be performed as well.
`.keep` files are consolidated into a single pack. When this
option is used, `gc.bigPackThreshold` is ignored.
AGGRESSIVE
----------
When the `--aggressive` option is supplied, linkgit:git-repack[1] will
be invoked with the `-f` flag, which in turn will pass
`--no-reuse-delta` to linkgit:git-pack-objects[1]. This will throw
away any existing deltas and re-compute them, at the expense of
spending much more time on the repacking.
The effects of this are mostly persistent, e.g. when packs and loose
objects are coalesced into one another pack the existing deltas in
that pack might get re-used, but there are also various cases where we
might pick a sub-optimal delta from a newer pack instead.
Furthermore, supplying `--aggressive` will tweak the `--depth` and
`--window` options passed to linkgit:git-repack[1]. See the
`gc.aggressiveDepth` and `gc.aggressiveWindow` settings below. By
using a larger window size we're more likely to find more optimal
deltas.
It's probably not worth it to use this option on a given repository
without running tailored performance benchmarks on it. It takes a lot
more time, and the resulting space/delta optimization may or may not
be worth it. Not using this at all is the right trade-off for most
users and their repositories.
CONFIGURATION
-------------
The below documentation is the same as what's found in
linkgit:git-config[1]:
The optional configuration variable `gc.reflogExpire` can be
set to indicate how long historical entries within each branch's
reflog should remain available in this repository. The setting is
expressed as a length of time, for example '90 days' or '3 months'.
It defaults to '90 days'.
The optional configuration variable `gc.reflogExpireUnreachable`
can be set to indicate how long historical reflog entries which
are not part of the current branch should remain available in
this repository. These types of entries are generally created as
a result of using `git commit --amend` or `git rebase` and are the
commits prior to the amend or rebase occurring. Since these changes
are not part of the current project most users will want to expire
them sooner. This option defaults to '30 days'.
The above two configuration variables can be given to a pattern. For
example, this sets non-default expiry values only to remote-tracking
branches:
------------
[gc "refs/remotes/*"]
reflogExpire = never
reflogExpireUnreachable = 3 days
------------
The optional configuration variable `gc.rerereResolved` indicates
how long records of conflicted merge you resolved earlier are
kept. This defaults to 60 days.
The optional configuration variable `gc.rerereUnresolved` indicates
how long records of conflicted merge you have not resolved are
kept. This defaults to 15 days.
The optional configuration variable `gc.packRefs` determines if
'git gc' runs 'git pack-refs'. This can be set to "notbare" to enable
it within all non-bare repos or it can be set to a boolean value.
This defaults to true.
The optional configuration variable `gc.writeCommitGraph` determines if
'git gc' should run 'git commit-graph write'. This can be set to a
boolean value. This defaults to false.
The optional configuration variable `gc.aggressiveWindow` controls how
much time is spent optimizing the delta compression of the objects in
the repository when the --aggressive option is specified. The larger
the value, the more time is spent optimizing the delta compression. See
the documentation for the --window option in linkgit:git-repack[1] for
more details. This defaults to 250.
Similarly, the optional configuration variable `gc.aggressiveDepth`
controls --depth option in linkgit:git-repack[1]. This defaults to 50.
The optional configuration variable `gc.pruneExpire` controls how old
the unreferenced loose objects have to be before they are pruned. The
default is "2 weeks ago".
Optional configuration variable `gc.worktreePruneExpire` controls how
old a stale working tree should be before `git worktree prune` deletes
it. Default is "3 months ago".
include::config/gc.txt[]
NOTES
-----
@ -119,8 +168,8 @@ anywhere in your repository. In
particular, it will keep not only objects referenced by your current set
of branches and tags, but also objects referenced by the index,
remote-tracking branches, refs saved by 'git filter-branch' in
refs/original/, reflogs (which may reference commits in branches
that were later amended or rewound), and anything else in the refs/* namespace.
refs/original/, or reflogs (which may reference commits in branches
that were later amended or rewound).
If you are expecting some objects to be deleted and they aren't, check
all of those locations and decide whether it makes sense in your case to
remove those references.
@ -141,7 +190,8 @@ mitigate this problem:
However, these features fall short of a complete solution, so users who
run commands concurrently have to live with some risk of corruption (which
seems to be low in practice).
seems to be low in practice) unless they turn off automatic garbage
collection with 'git config gc.auto 0'.
HOOKS
-----

View File

@ -88,7 +88,7 @@ OPTIONS
mechanism. Only useful with `--untracked`.
--exclude-standard::
Do not pay attention to ignored files specified via the `.gitignore`
Do not pay attention to ignored files specified via the `.gitignore`
mechanism. Only useful when searching files in the current directory
with `--no-index`.

View File

@ -18,7 +18,9 @@ Computes the object ID value for an object with specified type
with the contents of the named file (which can be outside of the
work tree), and optionally writes the resulting object into the
object database. Reports its object ID to its standard output.
When <type> is not specified, it defaults to "blob".
This is used by 'git cvsimport' to update the index
without modifying files in the work tree. When <type> is not
specified, it defaults to "blob".
OPTIONS
-------

View File

@ -171,8 +171,8 @@ variable, we launch 'kfmclient' to try to open the man page on an
already opened konqueror in a new tab if possible.
For consistency, we also try such a trick if 'man.konqueror.path' is
set to something like `A_PATH_TO/konqueror`. That means we will try to
launch `A_PATH_TO/kfmclient` instead.
set to something like 'A_PATH_TO/konqueror'. That means we will try to
launch 'A_PATH_TO/kfmclient' instead.
If you really want to use 'konqueror', then you can use something like
the following:

View File

@ -162,7 +162,7 @@ ScriptAliasMatch ^/git/[^/]*(.*) /usr/libexec/git-core/git-http-backend/storage.
Accelerated static Apache 2.x::
Similar to the above, but Apache can be used to return static
files that are stored on disk. On many systems this may
files that are stored on disk. On many systems this may
be more efficient as Apache can ask the kernel to copy the
file contents from the file system directly to the network:
+

View File

@ -3,7 +3,7 @@ git-interpret-trailers(1)
NAME
----
git-interpret-trailers - Add or parse structured information in commit messages
git-interpret-trailers - add or parse structured information in commit messages
SYNOPSIS
--------

View File

@ -49,7 +49,7 @@ OPTIONS
Print out the ref name given on the command line by which each
commit was reached.
--[no-]use-mailmap::
--use-mailmap::
Use mailmap file to map author and committer names and email
addresses to canonical real names and email addresses. See
linkgit:git-shortlog[1].

View File

@ -118,7 +118,6 @@ OPTIONS
linkgit:git-status[1] `--short` or linkgit:git-diff[1]
`--name-status` for more user-friendly alternatives.
+
--
This option identifies the file status with the following tags (followed by
a space) at the start of each line:
@ -129,7 +128,6 @@ a space) at the start of each line:
C:: modified/changed
K:: to be killed
?:: other
--
-v::
Similar to `-t`, but use lowercase letters for files

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