|  | 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.fsck.*`. 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 must be 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. | 
|  | + | 
|  | See the `Fsck Messages` section of linkgit:git-fsck[1] for supported | 
|  | values of `<msg-id>`. | 
|  |  | 
|  |  | 
|  | 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 are 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 must be 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. |