config.txt: move transfer.* to a separate file
authorNguyễn Thái Ngọc Duy <>
Sat, 27 Oct 2018 06:23:43 +0000 (08:23 +0200)
committerJunio C Hamano <>
Mon, 29 Oct 2018 01:17:04 +0000 (10:17 +0900)
Signed-off-by: Nguyễn Thái Ngọc Duy <>
Signed-off-by: Junio C Hamano <>
Documentation/config/transfer.txt [new file with mode: 0644]

index 1db9c58..07100e2 100644 (file)
@@ -421,77 +421,7 @@ include::config/submodule.txt[]
-       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 can not 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 already been
-written to the object store. That difference in behavior should not be
-relied upon. In the future, such objects may be quarantined for
-"fetch" as well.
-For now, the paranoid need to find some way to emulate the quarantine
-environment if they'd like the same protection as "push". E.g. in the
-case of an internal mirror do the mirroring in two steps, one to fetch
-the untrusted objects, and then do a second "push" (which will use the
-quarantine) to another internal repo, and have internal clients
-consume this pushed-to repository, or embargo internal fetches and
-only allow them once a full "fsck" has run (and no new fetches have
-happened in the meantime).
-       String(s) `receive-pack` and `upload-pack` use to decide which
-       refs to omit from their initial advertisements.  Use more than
-       one definition to specify multiple prefix strings. A ref that is
-       under the hierarchies listed in the value of this variable is
-       excluded, and is hidden when responding to `git push` or `git
-       fetch`.  See `receive.hideRefs` and `uploadpack.hideRefs` for
-       program-specific versions of this config.
-You may also include a `!` in front of the ref name to negate the entry,
-explicitly exposing it, even if an earlier entry marked it as hidden.
-If you have multiple hideRefs values, later entries override earlier ones
-(and entries in more-specific config files override less-specific ones).
-If a namespace is in use, the namespace prefix is stripped from each
-reference before it is matched against `transfer.hiderefs` patterns.
-For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
-the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
-is omitted from the advertisements but `refs/heads/master` and
-`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
-"have" lines. In order to match refs before stripping, add a `^` in front of
-the ref name. If you combine `!` and `^`, `!` must be specified first.
-Even if you hide refs, a client may still be able to steal the target
-objects via the techniques described in the "SECURITY" section of the
-linkgit:gitnamespaces[7] man page; it's best to keep private data in a
-separate repository.
-       When `fetch.unpackLimit` or `receive.unpackLimit` are
-       not set, the value of this variable is used instead.
-       The default value is 100.
        If true, allow clients to use `git archive --remote` to request
diff --git a/Documentation/config/transfer.txt b/Documentation/config/transfer.txt
new file mode 100644 (file)
index 0000000..4a5dfe2
--- /dev/null
@@ -0,0 +1,71 @@
+       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 can not 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 already been
+written to the object store. That difference in behavior should not be
+relied upon. In the future, such objects may be quarantined for
+"fetch" as well.
+For now, the paranoid need to find some way to emulate the quarantine
+environment if they'd like the same protection as "push". E.g. in the
+case of an internal mirror do the mirroring in two steps, one to fetch
+the untrusted objects, and then do a second "push" (which will use the
+quarantine) to another internal repo, and have internal clients
+consume this pushed-to repository, or embargo internal fetches and
+only allow them once a full "fsck" has run (and no new fetches have
+happened in the meantime).
+       String(s) `receive-pack` and `upload-pack` use to decide which
+       refs to omit from their initial advertisements.  Use more than
+       one definition to specify multiple prefix strings. A ref that is
+       under the hierarchies listed in the value of this variable is
+       excluded, and is hidden when responding to `git push` or `git
+       fetch`.  See `receive.hideRefs` and `uploadpack.hideRefs` for
+       program-specific versions of this config.
+You may also include a `!` in front of the ref name to negate the entry,
+explicitly exposing it, even if an earlier entry marked it as hidden.
+If you have multiple hideRefs values, later entries override earlier ones
+(and entries in more-specific config files override less-specific ones).
+If a namespace is in use, the namespace prefix is stripped from each
+reference before it is matched against `transfer.hiderefs` patterns.
+For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
+the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
+is omitted from the advertisements but `refs/heads/master` and
+`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
+"have" lines. In order to match refs before stripping, add a `^` in front of
+the ref name. If you combine `!` and `^`, `!` must be specified first.
+Even if you hide refs, a client may still be able to steal the target
+objects via the techniques described in the "SECURITY" section of the
+linkgit:gitnamespaces[7] man page; it's best to keep private data in a
+separate repository.
+       When `fetch.unpackLimit` or `receive.unpackLimit` are
+       not set, the value of this variable is used instead.
+       The default value is 100.