1f010d6bdf
We presently use the ".txt" extension for our AsciiDoc files. While not wrong, most editors do not associate this extension with AsciiDoc, meaning that contributors don't get automatic editor functionality that could be useful, such as syntax highlighting and prose linting. It is much more common to use the ".adoc" extension for AsciiDoc files, since this helps editors automatically detect files and also allows various forges to provide rich (HTML-like) rendering. Let's do that here, renaming all of the files and updating the includes where relevant. Adjust the various build scripts and makefiles to use the new extension as well. Note that this should not result in any user-visible changes to the documentation. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> 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.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.
|