Git development
 help / color / mirror / Atom feed
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

  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