Browse Source
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>maint


2 changed files with 68 additions and 67 deletions
@ -0,0 +1,67 @@
@@ -0,0 +1,67 @@
|
||||
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. |
||||
|
||||
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. |
Loading…
Reference in new issue