f6534dbda4
The documentation lacks mention of specific <msg-id> that are supported. While git-help --config will display a list of these options, often developers' first instinct is to consult the git docs to find valid config values. Add a list of fsck error messages, and link to it from the git-fsck documentation. Signed-off-by: John Cai <johncai86@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
72 lines
3.4 KiB
Plaintext
72 lines
3.4 KiB
Plaintext
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.<msg-id>.*`. 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 they must all 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 `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 is 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 they must all 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.
|