diff options
author | Nguyễn Thái Ngọc Duy <pclouds@gmail.com> | 2018-10-27 08:22:58 +0200 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2018-10-29 10:17:01 +0900 |
commit | f80ccccbc7b39465aaa9937b8be2ca2949b3d3d3 (patch) | |
tree | b6bf54369a8fa91f8cdb644889c12e8ce335f530 /Documentation | |
parent | config.txt: move fmt-merge-msg-config.txt to config/ (diff) | |
download | tgif-f80ccccbc7b39465aaa9937b8be2ca2949b3d3d3.tar.xz |
config.txt: move fsck.* 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>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/config.txt | 68 | ||||
-rw-r--r-- | Documentation/config/fsck.txt | 67 |
2 files changed, 68 insertions, 67 deletions
diff --git a/Documentation/config.txt b/Documentation/config.txt index 3dc2285ba5..f70f95d5cf 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -331,73 +331,7 @@ include::config/format.txt[] include::config/filter.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::config/fsck.txt[] gc.aggressiveDepth:: The depth parameter used in the delta compression diff --git a/Documentation/config/fsck.txt b/Documentation/config/fsck.txt new file mode 100644 index 0000000000..879c5a29c4 --- /dev/null +++ b/Documentation/config/fsck.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. |