git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/4] Allow building Git with Asciidoctor
Date: Tue, 14 Oct 2014 05:51:19 -0400	[thread overview]
Message-ID: <20141014095119.GC16686@peff.net> (raw)
In-Reply-To: <1413070656-241955-1-git-send-email-sandals@crustytoothpaste.net>

On Sat, Oct 11, 2014 at 11:37:32PM +0000, brian m. carlson wrote:

> This series is designed to implement the changes necessary to build Git
> using Asciidoctor instead of AsciiDoc.

Thanks. I had always taken the attitude that we wrote for the original
Python AsciiDoc, and that using AsciiDoctor was a choice that
git-scm.com made, and something they would have to deal with as far as
compatibility (AFAIK, AsciiDoctor grew out of git-scm.com's home-grown
asciidoc parser).

What's the status on AsciiDoc versus AsciiDoctor? The latter seems more
actively developed these days, but perhaps that is just my perception.
The incompatibilities seem fairly minimal (if those first two patches
are the extent of it, I have no problem at all trying to remain
compatible with both). Would it ever make sense to switch to AsciiDoctor
as our official command-line build program? I know it is supposed to be
much faster (though a lot of the slowness in our build chain is due to
docbook, not asciidoc itself).

Specifically I'm not excited about getting into a state where we have to
maintain both an asciidoc.conf file _and_ ruby extensions for
asciidoctor. I don't mind if somebody wants to step up and keep the
asciidoctor bits in sync with the asciidoc.conf, but I feel like one of
them needs to be considered the "master".

-Peff

  parent reply	other threads:[~2014-10-14 13:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-11 23:37 [PATCH 0/4] Allow building Git with Asciidoctor brian m. carlson
2014-10-11 23:37 ` [PATCH 1/4] Documentation: adjust document title underlining brian m. carlson
2014-10-13 20:35   ` Junio C Hamano
2014-10-11 23:37 ` [PATCH 2/4] Documentation: fix mismatched delimiters in git-imap-send brian m. carlson
2014-10-11 23:37 ` [PATCH 3/4] Documentation: move some AsciiDoc parameters into variables brian m. carlson
2014-10-15 20:43   ` Junio C Hamano
2014-10-16  1:52     ` brian m. carlson
2014-10-11 23:37 ` [PATCH 4/4] Documentation: implement linkgit macro for Asciidoctor brian m. carlson
2014-10-13 20:41 ` [PATCH 0/4] Allow building Git with Asciidoctor Junio C Hamano
2014-10-14  0:34   ` brian m. carlson
2014-10-14 10:07     ` Jakub Narębski
2014-10-14 11:26       ` brian m. carlson
2014-10-14  9:51 ` Jeff King [this message]
2014-10-14 17:08   ` Junio C Hamano
2014-10-15  1:17     ` brian m. carlson
2014-10-15 17:43       ` Junio C Hamano
2014-10-15 11:24   ` Thomas Braun
2014-10-15 23:52     ` brian m. carlson
2014-10-16 22:53 ` Philip Oakley

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=20141014095119.GC16686@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).