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>
Nguyễn Thái Ngọc Duy committed
Oct 27, 2018 at 08:22 UTC
f80ccccbc7b39465aaa9937b8be2ca2949b3d3d3
2 files changed
+68
-67
Documentation/config.txt
+1
-67
@@ -331,73 +331,7 @@ include::config/format.txt[]
331
332
include::config/filter.txt[]
333
334
-fsck.<msg-id>::
335
- During fsck git may find issues with legacy data which
336
- wouldn't be generated by current versions of git, and which
337
- wouldn't be sent over the wire if `transfer.fsckObjects` was
338
- set. This feature is intended to support working with legacy
339
- repositories containing such data.
340
-+
341
-Setting `fsck.<msg-id>` will be picked up by linkgit:git-fsck[1], but
342
-to accept pushes of such data set `receive.fsck.<msg-id>` instead, or
343
-to clone or fetch it set `fetch.fsck.<msg-id>`.
344
-+
345
-The rest of the documentation discusses `fsck.*` for brevity, but the
346
-same applies for the corresponding `receive.fsck.*` and
347
-`fetch.<msg-id>.*`. variables.
348
-+
349
-Unlike variables like `color.ui` and `core.editor` the
350
-`receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>` variables will not
351
-fall back on the `fsck.<msg-id>` configuration if they aren't set. To
352
-uniformly configure the same fsck settings in different circumstances
353
-all three of them they must all set to the same values.
354
-+
355
-When `fsck.<msg-id>` is set, errors can be switched to warnings and
356
-vice versa by configuring the `fsck.<msg-id>` setting where the
357
-`<msg-id>` is the fsck message ID and the value is one of `error`,
358
-`warn` or `ignore`. For convenience, fsck prefixes the error/warning
359
-with the message ID, e.g. "missingEmail: invalid author/committer line
360
-- missing email" means that setting `fsck.missingEmail = ignore` will
361
-hide that issue.
362
-+
363
-In general, it is better to enumerate existing objects with problems
364
-with `fsck.skipList`, instead of listing the kind of breakages these
365
-problematic objects share to be ignored, as doing the latter will
366
-allow new instances of the same breakages go unnoticed.
367
-+
368
-Setting an unknown `fsck.<msg-id>` value will cause fsck to die, but
369
-doing the same for `receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>`
370
-will only cause git to warn.
371
-
372
-fsck.skipList::
373
- The path to a list of object names (i.e. one unabbreviated SHA-1 per
374
- line) that are known to be broken in a non-fatal way and should
375
- be ignored. On versions of Git 2.20 and later comments ('#'), empty
376
- lines, and any leading and trailing whitespace is ignored. Everything
377
- but a SHA-1 per line will error out on older versions.
378
-+
379
-This feature is useful when an established project should be accepted
380
-despite early commits containing errors that can be safely ignored
381
-such as invalid committer email addresses. Note: corrupt objects
382
-cannot be skipped with this setting.
383
-+
384
-Like `fsck.<msg-id>` this variable has corresponding
385
-`receive.fsck.skipList` and `fetch.fsck.skipList` variants.
386
-+
387
-Unlike variables like `color.ui` and `core.editor` the
388
-`receive.fsck.skipList` and `fetch.fsck.skipList` variables will not
389
-fall back on the `fsck.skipList` configuration if they aren't set. To
390
-uniformly configure the same fsck settings in different circumstances
391
-all three of them they must all set to the same values.
392
-+
393
-Older versions of Git (before 2.20) documented that the object names
394
-list should be sorted. This was never a requirement, the object names
395
-could appear in any order, but when reading the list we tracked whether
396
-the list was sorted for the purposes of an internal binary search
397
-implementation, which could save itself some work with an already sorted
398
-list. Unless you had a humongous list there was no reason to go out of
399
-your way to pre-sort the list. After Git version 2.20 a hash implementation
400
-is used instead, so there's now no reason to pre-sort the list.
334
+include::config/fsck.txt[]
335
336
gc.aggressiveDepth::
337
The depth parameter used in the delta compression
Documentation/config/fsck.txt
new
+67
@@ -0,0 +1,67 @@
1
+fsck.<msg-id>::
2
+ During fsck git may find issues with legacy data which
3
+ wouldn't be generated by current versions of git, and which
4
+ wouldn't be sent over the wire if `transfer.fsckObjects` was
5
+ set. This feature is intended to support working with legacy
6
+ repositories containing such data.
7
++
8
+Setting `fsck.<msg-id>` will be picked up by linkgit:git-fsck[1], but
9
+to accept pushes of such data set `receive.fsck.<msg-id>` instead, or
10
+to clone or fetch it set `fetch.fsck.<msg-id>`.
11
++
12
+The rest of the documentation discusses `fsck.*` for brevity, but the
13
+same applies for the corresponding `receive.fsck.*` and
14
+`fetch.<msg-id>.*`. variables.
15
++
16
+Unlike variables like `color.ui` and `core.editor` the
17
+`receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>` variables will not
18
+fall back on the `fsck.<msg-id>` configuration if they aren't set. To
19
+uniformly configure the same fsck settings in different circumstances
20
+all three of them they must all set to the same values.
21
++
22
+When `fsck.<msg-id>` is set, errors can be switched to warnings and
23
+vice versa by configuring the `fsck.<msg-id>` setting where the
24
+`<msg-id>` is the fsck message ID and the value is one of `error`,
25
+`warn` or `ignore`. For convenience, fsck prefixes the error/warning
26
+with the message ID, e.g. "missingEmail: invalid author/committer line
27
+- missing email" means that setting `fsck.missingEmail = ignore` will
28
+hide that issue.
29
++
30
+In general, it is better to enumerate existing objects with problems
31
+with `fsck.skipList`, instead of listing the kind of breakages these
32
+problematic objects share to be ignored, as doing the latter will
33
+allow new instances of the same breakages go unnoticed.
34
++
35
+Setting an unknown `fsck.<msg-id>` value will cause fsck to die, but
36
+doing the same for `receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>`
37
+will only cause git to warn.
38
+
39
+fsck.skipList::
40
+ The path to a list of object names (i.e. one unabbreviated SHA-1 per
41
+ line) that are known to be broken in a non-fatal way and should
42
+ be ignored. On versions of Git 2.20 and later comments ('#'), empty
43
+ lines, and any leading and trailing whitespace is ignored. Everything
44
+ but a SHA-1 per line will error out on older versions.
45
++
46
+This feature is useful when an established project should be accepted
47
+despite early commits containing errors that can be safely ignored
48
+such as invalid committer email addresses. Note: corrupt objects
49
+cannot be skipped with this setting.
50
++
51
+Like `fsck.<msg-id>` this variable has corresponding
52
+`receive.fsck.skipList` and `fetch.fsck.skipList` variants.
53
++
54
+Unlike variables like `color.ui` and `core.editor` the
55
+`receive.fsck.skipList` and `fetch.fsck.skipList` variables will not
56
+fall back on the `fsck.skipList` configuration if they aren't set. To
57
+uniformly configure the same fsck settings in different circumstances
58
+all three of them they must all set to the same values.
59
++
60
+Older versions of Git (before 2.20) documented that the object names
61
+list should be sorted. This was never a requirement, the object names
62
+could appear in any order, but when reading the list we tracked whether
63
+the list was sorted for the purposes of an internal binary search
64
+implementation, which could save itself some work with an already sorted
65
+list. Unless you had a humongous list there was no reason to go out of
66
+your way to pre-sort the list. After Git version 2.20 a hash implementation
67
+is used instead, so there's now no reason to pre-sort the list.