config.txt: move transfer.* to a separate file
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nguyễn Thái Ngọc Duy committed
Oct 27, 2018 at 08:23 UTC
4a5bad0704859d09c2b53d3a2546799a36ee16dd
2 files changed
+72
-71
Documentation/config.txt
+1
-71
@@ -421,77 +421,7 @@ include::config/submodule.txt[]
421
422
include::config/tag.txt[]
423
424
-transfer.fsckObjects::
425
- When `fetch.fsckObjects` or `receive.fsckObjects` are
426
- not set, the value of this variable is used instead.
427
- Defaults to false.
428
-+
429
-When set, the fetch or receive will abort in the case of a malformed
430
-object or a link to a nonexistent object. In addition, various other
431
-issues are checked for, including legacy issues (see `fsck.<msg-id>`),
432
-and potential security issues like the existence of a `.GIT` directory
433
-or a malicious `.gitmodules` file (see the release notes for v2.2.1
434
-and v2.17.1 for details). Other sanity and security checks may be
435
-added in future releases.
436
-+
437
-On the receiving side, failing fsckObjects will make those objects
438
-unreachable, see "QUARANTINE ENVIRONMENT" in
439
-linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
440
-instead be left unreferenced in the repository.
441
-+
442
-Due to the non-quarantine nature of the `fetch.fsckObjects`
443
-implementation it can not be relied upon to leave the object store
444
-clean like `receive.fsckObjects` can.
445
-+
446
-As objects are unpacked they're written to the object store, so there
447
-can be cases where malicious objects get introduced even though the
448
-"fetch" failed, only to have a subsequent "fetch" succeed because only
449
-new incoming objects are checked, not those that have already been
450
-written to the object store. That difference in behavior should not be
451
-relied upon. In the future, such objects may be quarantined for
452
-"fetch" as well.
453
-+
454
-For now, the paranoid need to find some way to emulate the quarantine
455
-environment if they'd like the same protection as "push". E.g. in the
456
-case of an internal mirror do the mirroring in two steps, one to fetch
457
-the untrusted objects, and then do a second "push" (which will use the
458
-quarantine) to another internal repo, and have internal clients
459
-consume this pushed-to repository, or embargo internal fetches and
460
-only allow them once a full "fsck" has run (and no new fetches have
461
-happened in the meantime).
462
-
463
-transfer.hideRefs::
464
- String(s) `receive-pack` and `upload-pack` use to decide which
465
- refs to omit from their initial advertisements. Use more than
466
- one definition to specify multiple prefix strings. A ref that is
467
- under the hierarchies listed in the value of this variable is
468
- excluded, and is hidden when responding to `git push` or `git
469
- fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for
470
- program-specific versions of this config.
471
-+
472
-You may also include a `!` in front of the ref name to negate the entry,
473
-explicitly exposing it, even if an earlier entry marked it as hidden.
474
-If you have multiple hideRefs values, later entries override earlier ones
475
-(and entries in more-specific config files override less-specific ones).
476
-+
477
-If a namespace is in use, the namespace prefix is stripped from each
478
-reference before it is matched against `transfer.hiderefs` patterns.
479
-For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
480
-the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
481
-is omitted from the advertisements but `refs/heads/master` and
482
-`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
483
-"have" lines. In order to match refs before stripping, add a `^` in front of
484
-the ref name. If you combine `!` and `^`, `!` must be specified first.
485
-+
486
-Even if you hide refs, a client may still be able to steal the target
487
-objects via the techniques described in the "SECURITY" section of the
488
-linkgit:gitnamespaces[7] man page; it's best to keep private data in a
489
-separate repository.
490
-
491
-transfer.unpackLimit::
492
- When `fetch.unpackLimit` or `receive.unpackLimit` are
493
- not set, the value of this variable is used instead.
494
- The default value is 100.
424
+include::config/transfer.txt[]
425
426
uploadarchive.allowUnreachable::
427
If true, allow clients to use `git archive --remote` to request
Documentation/config/transfer.txt
new
+71
@@ -0,0 +1,71 @@
1
+transfer.fsckObjects::
2
+ When `fetch.fsckObjects` or `receive.fsckObjects` are
3
+ not set, the value of this variable is used instead.
4
+ Defaults to false.
5
++
6
+When set, the fetch or receive will abort in the case of a malformed
7
+object or a link to a nonexistent object. In addition, various other
8
+issues are checked for, including legacy issues (see `fsck.<msg-id>`),
9
+and potential security issues like the existence of a `.GIT` directory
10
+or a malicious `.gitmodules` file (see the release notes for v2.2.1
11
+and v2.17.1 for details). Other sanity and security checks may be
12
+added in future releases.
13
++
14
+On the receiving side, failing fsckObjects will make those objects
15
+unreachable, see "QUARANTINE ENVIRONMENT" in
16
+linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
17
+instead be left unreferenced in the repository.
18
++
19
+Due to the non-quarantine nature of the `fetch.fsckObjects`
20
+implementation it can not be relied upon to leave the object store
21
+clean like `receive.fsckObjects` can.
22
++
23
+As objects are unpacked they're written to the object store, so there
24
+can be cases where malicious objects get introduced even though the
25
+"fetch" failed, only to have a subsequent "fetch" succeed because only
26
+new incoming objects are checked, not those that have already been
27
+written to the object store. That difference in behavior should not be
28
+relied upon. In the future, such objects may be quarantined for
29
+"fetch" as well.
30
++
31
+For now, the paranoid need to find some way to emulate the quarantine
32
+environment if they'd like the same protection as "push". E.g. in the
33
+case of an internal mirror do the mirroring in two steps, one to fetch
34
+the untrusted objects, and then do a second "push" (which will use the
35
+quarantine) to another internal repo, and have internal clients
36
+consume this pushed-to repository, or embargo internal fetches and
37
+only allow them once a full "fsck" has run (and no new fetches have
38
+happened in the meantime).
39
+
40
+transfer.hideRefs::
41
+ String(s) `receive-pack` and `upload-pack` use to decide which
42
+ refs to omit from their initial advertisements. Use more than
43
+ one definition to specify multiple prefix strings. A ref that is
44
+ under the hierarchies listed in the value of this variable is
45
+ excluded, and is hidden when responding to `git push` or `git
46
+ fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for
47
+ program-specific versions of this config.
48
++
49
+You may also include a `!` in front of the ref name to negate the entry,
50
+explicitly exposing it, even if an earlier entry marked it as hidden.
51
+If you have multiple hideRefs values, later entries override earlier ones
52
+(and entries in more-specific config files override less-specific ones).
53
++
54
+If a namespace is in use, the namespace prefix is stripped from each
55
+reference before it is matched against `transfer.hiderefs` patterns.
56
+For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
57
+the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
58
+is omitted from the advertisements but `refs/heads/master` and
59
+`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
60
+"have" lines. In order to match refs before stripping, add a `^` in front of
61
+the ref name. If you combine `!` and `^`, `!` must be specified first.
62
++
63
+Even if you hide refs, a client may still be able to steal the target
64
+objects via the techniques described in the "SECURITY" section of the
65
+linkgit:gitnamespaces[7] man page; it's best to keep private data in a
66
+separate repository.
67
+
68
+transfer.unpackLimit::
69
+ When `fetch.unpackLimit` or `receive.unpackLimit` are
70
+ not set, the value of this variable is used instead.
71
+ The default value is 100.