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