| 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. |