]>
Commit | Line | Data |
---|---|---|
f80ccccb NTND |
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 | |
bc42e1e7 MÅ |
26 | with the message ID, e.g. "missingEmail: invalid author/committer |
27 | line - missing email" means that setting `fsck.missingEmail = ignore` | |
28 | will hide that issue. | |
f80ccccb NTND |
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. |