commit | 7a3013435831e77ca24f4bf234a8751eb59adeb2 | [log] [tgz] |
---|---|---|
author | Martin Ågren <martin.agren@gmail.com> | Mon Sep 16 21:00:27 2019 +0200 |
committer | Junio C Hamano <gitster@pobox.com> | Mon Sep 16 12:27:37 2019 -0700 |
tree | 87dfdf25f7279870988eb167038d771804dbec21 | |
parent | 226daba280be841833589d29d4375ba57d508878 [diff] |
asciidoctor-extensions: provide `<refmiscinfo/>` As can be seen from the previous commit, there are three attributes that we provide to AsciiDoc through asciidoc.conf. Asciidoctor ignores that file. After that patch, newer versions of Asciidoctor pick up the `manmanual` and `mansource` attributes as we invoke `asciidoctor`, but they don't pick up `manversion`. ([1] says: "Not used by Asciidoctor.") Older versions (<1.5.7) don't handle these attributes at all. As a result, we are missing one or three `<refmiscinfo/>` tags in each xml-file produced when we build with Asciidoctor. Because of this, xmlto doesn't include the Git version number in the rendered manpages. And in particular, with versions <1.5.7, the manpage footers instead contain the fairly ugly "[FIXME: source]". That Asciidoctor ignores asciidoc.conf is nothing new. This is why we implement the `linkgit:` macro in asciidoc.conf *and* in asciidoctor-extensions.rb. Follow suit and provide these tags in asciidoctor-extensions.rb, using a "postprocessor" extension where we just search and replace in the XML, treated as text. We may consider a few alternatives: * Inject these lines into the xml-files from the *Makefile*, e.g., using `sed`. That would reduce repetition, but it feels wrong to impose another step and another risk on the AsciiDoc-processing only to benefit the Asciidoctor-one. * I tried providing a "docinfo processor" to inject these tags, but could not figure out how to "merge" the two <refmeta/> sections that resulted. To avoid xmlto barfing on the result, I needed to use `xmlto --skip-validation ...`, which seems unfortunate. Let's instead inject the missing tags using a postprocessor. We'll make it fairly obvious that we aim to inject the exact same three lines of `<refmiscinfo/>` that asciidoc.conf provides. We inject them in *post*-processing so we need to do the variable expansion ourselves. We do introduce the bug that asciidoc.conf already has in that we won't do any escaping, e.g., of funky versions like "some v <2.25, >2.20". The postprocessor we add here works on the XML as raw text and doesn't really use the full potential of XML to do a more structured injection. This is actually precisely what the Asciidoctor User Manual does in its postprocessor example [2]. I looked into two other approaches: 1. The nokogiri library is apparently the "modern" way of doing XML in ruby. I got it working fairly easily: require 'nokogiri' doc = Nokogiri::XML(output) doc.search("refmeta").each { |n| n.add_child(new_tags) } output = doc.to_xml However, this adds another dependency (e.g., the "ruby-nokogiri" package on Ubuntu). Using Asciidoctor is not our default, but it will probably need to become so soon. Let's avoid adding a dependency just so that we can say "search...add_child" rather than "sub(regex...)". 2. The older REXML is apparently always(?) bundled with ruby, but I couldn't even parse the original document: require 'rexml/document' doc = REXML::Document.new(output) ... The error was "no implicit conversion of nil into String" and I stopped there. I don't think it's unlikely that doing a plain old search-and-replace will work just as fine or better compared to parsing XML and worrying about libraries and library versions. [1] https://asciidoctor.org/docs/user-manual/#builtin-attributes [2] https://asciidoctor.org/docs/user-manual/#postprocessor-example Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.
Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2). It was originally written by Linus Torvalds with help of a group of hackers around the net.
Please read the file INSTALL for installation instructions.
Many Git online resources are accessible from https://git-scm.com/ including full documentation and Git related tools.
See Documentation/gittutorial.txt to get started, then see Documentation/giteveryday.txt for a useful minimum set of commands, and Documentation/git-<commandname>.txt
for documentation of each command. If git has been correctly installed, then the tutorial can also be read with man gittutorial
or git help tutorial
, and the documentation of each command with man git-<commandname>
or git help <commandname>
.
CVS users may also want to read Documentation/gitcvs-migration.txt (man gitcvs-migration
or git help cvs-migration
if git is installed).
The user discussion and development of Git take place on the Git mailing list -- everyone is welcome to post bug reports, feature requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission). To subscribe to the list, send an email with just “subscribe git” in the body to majordomo@vger.kernel.org. The mailing list archives are available at https://public-inbox.org/git/, http://marc.info/?l=git and other archival sites.
Issues which are security relevant should be disclosed privately to the Git Security mailing list git-security@googlegroups.com.
The maintainer frequently sends the “What's cooking” reports that list the current status of various development topics to the mailing list. The discussion following them give a good reference for project status, development direction and remaining tasks.
The name “git” was given by Linus Torvalds when he wrote the very first version. He described the tool as “the stupid content tracker” and the name as (depending on your mood):