From: Todd Zullinger <tmz@pobox.com>
To: git@vger.kernel.org
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Jeff King <peff@peff.net>, Patrick Steinhardt <ps@pks.im>,
Taylor Blau <me@ttaylorr.com>
Subject: Re: [NOTES 03/07] Documentation
Date: Wed, 7 Oct 2026 00:49:44 -0400 [thread overview]
Message-ID: <20261007044944.PjN-Ln9E@teonanacatl.net> (raw)
In-Reply-To: <summit-2026.94e33e9ddf234334.03@ttaylorr.com>
Thank you for the nice summaries Taylor.
Taylor Blau wrote:
> Topic: Documentation
> * Peff: We support both AsciiDoc and Asciidoctor. Would it help to get
> out of that dual world?
>
> * Patrick: Traditionally this was for migration. AsciiDoc was thought to
> be unmaintained, but it is maintained now.
>
> * Peff: We could move to Asciidoctor.
>
> * brian: Fedora still uses AsciiDoc. Asciidoctor is well maintained,
> written in Ruby, and reasonably portable. It depends on how much we
> want to support. I do not know whether Fedora is still an obstacle.
The Fedora packages have used Asciidoctor by default since
e942c8d (use Asciidoctor to build documentation when
possible, 2020-02-25).
https://src.fedoraproject.org/rpms/git/c/e942c8d
That hasn't changed since I stopped maintaining the git
package, so Fedora hasn't had an issue with a switch to
Asciidoctor for quite a long time.
CentOS Stream / RHEL uses AsciiDoc (with the odd exception
of 9). They _could_ use Asciidoctor relatively easily; it
is maintained for EPEL already.
But if Red Hat really dislike requiring Asciidoctor for git
builds in RHEL, they could ship the pre-built docs, as I
used to do for EL-5 builds due to an unsupported (read:
ancient) AsciiDoc version.
If we switched to Asciidoctor, it _might_ open the door to
replacing the docbook/xmlto dependencies and having
Asciidoctor directly generate the man pages.
I haven't thought about or looked at that in a long, long
time, so I don't know if that would be a worthwhile change
or not. I don't recall if we need the XML step for other
outputs, like info or PDF (neither of which I ever spent
much time trying to build).
--
Todd
next prev parent reply other threads:[~2026-10-07 4:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 18:05 Notes from the Git Contributor's Summit, 2026 Taylor Blau
2026-10-06 18:06 ` [NOTES 01/07] Security mailing list and security process Taylor Blau
2026-10-06 18:06 ` [NOTES 02/07] Git 3.0 Taylor Blau
2026-10-06 18:06 ` [NOTES 03/07] Documentation Taylor Blau
2026-10-07 4:49 ` Todd Zullinger [this message]
2026-10-07 17:38 ` Junio C Hamano
2026-10-06 18:06 ` [NOTES 04/07] Outreachy sponsorship Taylor Blau
2026-10-06 18:06 ` [NOTES 05/07] What can we do next with pluggable ODB? Taylor Blau
2026-10-06 18:06 ` [NOTES 06/07] AI contribution policy Taylor Blau
2026-10-06 18:06 ` [NOTES 07/07] Protocol v2 for pushes Taylor Blau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261007044944.PjN-Ln9E@teonanacatl.net \
--to=tmz@pobox.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox