aboutsummaryrefslogtreecommitdiff
path: root/Documentation/git-rev-parse.adoc
AgeCommit message (Collapse)Author
2025-10-22Merge branch 'bc/sha1-256-interop-01'Junio C Hamano
The beginning of SHA1-SHA256 interoperability work. * bc/sha1-256-interop-01: t1010: use BROKEN_OBJECTS prerequisite t: allow specifying compatibility hash fsck: consider gpgsig headers expected in tags rev-parse: allow printing compatibility hash docs: add documentation for loose objects docs: improve ambiguous areas of pack format documentation docs: reflect actual double signature for tags docs: update offset order for pack index v3 docs: update pack index v3 format
2025-10-10doc: fix accidental literal blocksKristoffer Haugsbakk
Make sure that normal paragraphs in most user-facing docs[1] don’t use literal blocks. This can easily happen if you try to maintain indentation in order to continue a block; that might work in e.g. Markdown variants, but not in AsciiDoc. The fixes are straightforward, i.e. just deindent the block and maybe add line continuations. The only exception is git-sparse-checkout(1) where we also replace indentation used for *intended* literal blocks with `----`. † 1: These have not been considered: • `Documentation/howto/` • `Documentation/technical/` • `Documentation/gitprotocol*` Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09rev-parse: allow printing compatibility hashbrian m. carlson
Right now, we have a way to print the storage hash, the input hash, and the output hash, but we lack a way to print the compatibility hash. Add a new type to --show-object-format, compat, which prints this value. If no compatibility hash exists, simply print a newline. This is important to allow users to use multiple options at once while still getting unambiguous output. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-01-21doc: use .adoc extension for AsciiDoc filesbrian m. carlson
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>