config.txt: move fsck.* to a separate file
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>maint
Nguyễn Thái Ngọc Duy
Junio C Hamano
parent
5a06936b60
commit
f80ccccbc7
|
|
@ -331,73 +331,7 @@ include::config/format.txt[]
|
||||||
|
|
||||||
include::config/filter.txt[]
|
include::config/filter.txt[]
|
||||||
|
|
||||||
fsck.<msg-id>::
|
include::config/fsck.txt[]
|
||||||
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.
|
|
||||||
|
|
||||||
gc.aggressiveDepth::
|
gc.aggressiveDepth::
|
||||||
The depth parameter used in the delta compression
|
The depth parameter used in the delta compression
|
||||||
|
|
|
||||||
|
|
@ -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