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

transfer.fsckObjects::
	When `fetch.fsckObjects` or `receive.fsckObjects` are
	not set, the value of this variable is used instead.
	Defaults to false.
+
When set, the fetch or receive will abort in the case of a malformed
object or a link to a nonexistent object. In addition, various other
issues are checked for, including legacy issues (see `fsck.<msg-id>`),
and potential security issues like the existence of a `.GIT` directory
or a malicious `.gitmodules` file (see the release notes for v2.2.1
and v2.17.1 for details). Other sanity and security checks may be
added in future releases.
+
On the receiving side, failing fsckObjects will make those objects
unreachable, see "QUARANTINE ENVIRONMENT" in
linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
instead be left unreferenced in the repository.
+
Due to the non-quarantine nature of the `fetch.fsckObjects`
implementation it cannot be relied upon to leave the object store
clean like `receive.fsckObjects` can.
+
As objects are unpacked they're written to the object store, so there
can be cases where malicious objects get introduced even though the
"fetch" failed, only to have a subsequent "fetch" succeed because only
new incoming objects are checked, not those that have