Skip to content

Commit f80cccc

Browse files
pcloudsgitster
authored andcommitted
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>
1 parent 5a06936 commit f80cccc

File tree

2 files changed

+68
-67
lines changed

2 files changed

+68
-67
lines changed

Documentation/config.txt

Lines changed: 1 addition & 67 deletions
Original file line numberDiff line numberDiff line change
@@ -331,73 +331,7 @@ include::config/format.txt[]
331331

332332
include::config/filter.txt[]
333333

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[]
401335

402336
gc.aggressiveDepth::
403337
The depth parameter used in the delta compression

Documentation/config/fsck.txt

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -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.

0 commit comments

Comments
 (0)