Documentation/config/fsck.txt

   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.fsck.*`. 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 must be 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
  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.
  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 See the `Fsck Messages` section of linkgit:git-fsck[1] for supported
  40 values of `<msg-id>`.
  41
  42
  43 fsck.skipList::
  44         The path to a list of object names (i.e. one unabbreviated SHA-1 per
  45         line) that are known to be broken in a non-fatal way and should
  46         be ignored. On versions of Git 2.20 and later, comments ('#'), empty
  47         lines, and any leading and trailing whitespace are ignored. Everything
  48         but a SHA-1 per line will error out on older versions.
  49 +
  50 This feature is useful when an established project should be accepted
  51 despite early commits containing errors that can be safely ignored,
  52 such as invalid committer email addresses.  Note: corrupt objects
  53 cannot be skipped with this setting.
  54 +
  55 Like `fsck.<msg-id>` this variable has corresponding
  56 `receive.fsck.skipList` and `fetch.fsck.skipList` variants.
  57 +
  58 Unlike variables like `color.ui` and `core.editor` the
  59 `receive.fsck.skipList` and `fetch.fsck.skipList` variables will not
  60 fall back on the `fsck.skipList` configuration if they aren't set. To
  61 uniformly configure the same fsck settings in different circumstances,
  62 all three of them must be set to the same values.
  63 +
  64 Older versions of Git (before 2.20) documented that the object names
  65 list should be sorted. This was never a requirement; the object names
  66 could appear in any order, but when reading the list we tracked whether
  67 the list was sorted for the purposes of an internal binary search
  68 implementation, which could save itself some work with an already sorted
  69 list. Unless you had a humongous list there was no reason to go out of
  70 your way to pre-sort the list. After Git version 2.20 a hash implementation
  71 is used instead, so there's now no reason to pre-sort the list.