[PATCH 20/59] config.txt: move fsck.* to a separate file
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/config.txt | 68 +----------------------------------
Documentation/fsck-config.txt | 67 ++++++++++++++++++++++++++++++++++
2 files changed, 68 insertions(+), 67 deletions(-)
create mode 100644 Documentation/fsck-config.txt
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7c7dde188c..fa26cb1090 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -331,73 +331,7 @@ include::format-config.txt[]
include::filter-config.txt[]
-fsck.<msg-id>::
- During fsck git may find issues with legacy data which
- wouldn't be generated by current versions of git, and which
- wouldn't be sent over the wire if `transfer.fsckObjects` was
- set. This feature is intended to support working with legacy
- repositories containing such data.
-+
-Setting `fsck.<msg-id>` will be picked up by linkgit:git-fsck[1], but
-to accept pushes of such data set `receive.fsck.<msg-id>` instead, or
-to clone or fetch it set `fetch.fsck.<msg-id>`.
-+
-The rest of the documentation discusses `fsck.*` for brevity, but the
-same applies for the corresponding `receive.fsck.*` and
-`fetch.<msg-id>.*`. variables.
-+
-Unlike variables like `color.ui` and `core.editor` the
-`receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>` variables will not
-fall back on the `fsck.<msg-id>` configuration if they aren't set. To
-uniformly configure the same fsck settings in different circumstances
-all three of them they must all set to the same values.
-+
-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.
-+
-In general, it is better to enumerate existing objects with problems
-with `fsck.skipList`, instead of listing the kind of breakages these
-problematic objects share to be ignored, as doing the latter will
-allow new instances of the same breakages go unnoticed.
-+
-Setting an unknown `fsck.<msg-id>` value will cause fsck to die, but
-doing the same for `receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>`
-will only cause git to warn.
-
-fsck.skipList::
- The path to a list of object names (i.e. one unabbreviated SHA-1 per
- line) that are known to be broken in a non-fatal way and should
- be ignored. On versions of Git 2.20 and later comments ('#'), empty
- lines, and any leading and trailing whitespace is ignored. Everything
- but a SHA-1 per line will error out on older versions.
-+
-This feature is useful when an established project should be accepted
-despite early commits containing errors that can be safely ignored
-such as invalid committer email addresses. Note: corrupt objects
-cannot be skipped with this setting.
-+
-Like `fsck.<msg-id>` this variable has corresponding
-`receive.fsck.skipList` and `fetch.fsck.skipList` variants.
-+
-Unlike variables like `color.ui` and `core.editor` the
-`receive.fsck.skipList` and `fetch.fsck.skipList` variables will not
-fall back on the `fsck.skipList` configuration if they aren't set. To
-uniformly configure the same fsck settings in different circumstances
-all three of them they must all set to the same values.
-+
-Older versions of Git (before 2.20) documented that the object names
-list should be sorted. This was never a requirement, the object names
-could appear in any order, but when reading the list we tracked whether
-the list was sorted for the purposes of an internal binary search
-implementation, which could save itself some work with an already sorted
-list. Unless you had a humongous list there was no reason to go out of
-your way to pre-sort the list. After Git version 2.20 a hash implementation
-is used instead, so there's now no reason to pre-sort the list.
+include::fsck-config.txt[]
gc.aggressiveDepth::
The depth parameter used in the delta compression
diff --git a/Documentation/fsck-config.txt b/Documentation/fsck-config.txt
new file mode 100644
index 0000000000..879c5a29c4
--- /dev/null
+++ b/Documentation/fsck-config.txt
@@ -0,0 +1,67 @@
+fsck.<msg-id>::
+ During fsck git may find issues with legacy data which
+ wouldn't be generated by current versions of git, and which
+ wouldn't be sent over the wire if `transfer.fsckObjects` was
+ set. This feature is intended to support working with legacy
+ repositories containing such data.
++
+Setting `fsck.<msg-id>` will be picked up by linkgit:git-fsck[1], but
+to accept pushes of such data set `receive.fsck.<msg-id>` instead, or
+to clone or fetch it set `fetch.fsck.<msg-id>`.
++
+The rest of the documentation discusses `fsck.*` for brevity, but the
+same applies for the corresponding `receive.fsck.*` and
+`fetch.<msg-id>.*`. variables.
++
+Unlike variables like `color.ui` and `core.editor` the
+`receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>` variables will not
+fall back on the `fsck.<msg-id>` configuration if they aren't set. To
+uniformly configure the same fsck settings in different circumstances
+all three of them they must all set to the same values.
++
+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.
++
+In general, it is better to enumerate existing objects with problems
+with `fsck.skipList`, instead of listing the kind of breakages these
+problematic objects share to be ignored, as doing the latter will
+allow new instances of the same breakages go unnoticed.
++
+Setting an unknown `fsck.<msg-id>` value will cause fsck to die, but
+doing the same for `receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>`
+will only cause git to warn.
+
+fsck.skipList::
+ The path to a list of object names (i.e. one unabbreviated SHA-1 per
+ line) that are known to be broken in a non-fatal way and should
+ be ignored. On versions of Git 2.20 and later comments ('#'), empty
+ lines, and any leading and trailing whitespace is ignored. Everything
+ but a SHA-1 per line will error out on older versions.
++
+This feature is useful when an established project should be accepted
+despite early commits containing errors that can be safely ignored
+such as invalid committer email addresses. Note: corrupt objects
+cannot be skipped with this setting.
++
+Like `fsck.<msg-id>` this variable has corresponding
+`receive.fsck.skipList` and `fetch.fsck.skipList` variants.
++
+Unlike variables like `color.ui` and `core.editor` the
+`receive.fsck.skipList` and `fetch.fsck.skipList` variables will not
+fall back on the `fsck.skipList` configuration if they aren't set. To
+uniformly configure the same fsck settings in different circumstances
+all three of them they must all set to the same values.
++
+Older versions of Git (before 2.20) documented that the object names
+list should be sorted. This was never a requirement, the object names
+could appear in any order, but when reading the list we tracked whether
+the list was sorted for the purposes of an internal binary search
+implementation, which could save itself some work with an already sorted
+list. Unless you had a humongous list there was no reason to go out of
+your way to pre-sort the list. After Git version 2.20 a hash implementation
+is used instead, so there's now no reason to pre-sort the list.
--
2.19.1.647.g708186aaf9
Nguyễn Thái Ngọc Duy <pclouds@gmail.com>