Git development
 help / color / mirror / Atom feed
From: "Julia Evans" <julia@jvns.ca>
To: "Jeff King" <peff@peff.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Julia Evans" <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] doc: add more AsciiDoc cross-references
Date: Thu, 24 Sep 2026 08:30:31 -0400	[thread overview]
Message-ID: <63520573-c8a7-41bd-aaeb-bfc2b5e43856@app.fastmail.com> (raw)
In-Reply-To: <20260923214038.GA49087@coredump.intra.peff.net>


> Even weirder, in the manpage output both implementations actually expand
> this to: the section called "FOO". So changing your patch like this:
>
>   -See the <<PRUNING,PRUNING>> section below for more details.
>   +See the <<PRUNING>> section below for more details.
>
> gives doc-diff output like this:
>
>   -         See the PRUNING section below for more details.
>   +         See the the section called “PRUNING” section below for more details.
>
> which is obviously nonsense.
>
> I could very well believe that some older versions did other weird
> things in the presence of includes. ;) But AFAICT the real need for the
> doubled text is to control what is in the expanded text (both because of
> differences between the versions, but also differences in output
> backends).
>
> Which is kind of a shame, because writing just <<PRUNING>> makes the
> source a lot more readable. I wonder if we can configure these text
> fallbacks, which would let us use the single-item form reliably.

Thanks for investigating, I was really dreading looking into the guts of
asciidoc to figure out exactly what was happening. It would be nice to be able
to write just <<PRUNING>>, especially because I believe asciidoctor will check
that internal links are valid, so there's no concern about breaking links if we
change the title of a section.

Re your other message about breaking links because we're changing the
HTML IDs: the options I see right now are

1. Leave it is as is and break some links
2. manually enter the ID like `_editing_patches`, trying to make sure to always
match the auto-generated ID (I'm not sure how to do that). I think this might
also cause some confusion for editors in the future as to why the section IDs
are formatted like that
3. Somehow fix it so that we can just do <<PRUNING>>

I'm not sure if #1 or #2 is better, obviously I'm biased towards #1 because
it's less work for me. #3 seems like the ideal but I don't know how to do that.

Here's a revised commit message, can submit that as a v2 if it seems correct.

    doc: add more AsciiDoc cross-references

    Instead of saying "see EXAMPLES below", say "see <<EXAMPLES,EXAMPLES>>
    below" to make the man pages easier to navigate on the web.

    The reason for using the more verbose <<EXAMPLES,EXAMPLES>>
    (instead of <<EXAMPLES>>) is in some cases, the HTML output is rendered
    as `"EXAMPLES"` or `[EXAMPLES]` instead of just `EXAMPLES`.
    So this gives us more control over how the output looks.

    This also changes some of the HTML IDs of the headings from `_examples`
    to `EXAMPLES`, which has the potential to break some links.

  reply	other threads:[~2026-09-24 12:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 19:29 [PATCH] doc: add more AsciiDoc cross-references Julia Evans via GitGitGadget
2026-09-22 20:20 ` Junio C Hamano
2026-09-22 20:54   ` Julia Evans
2026-09-23 21:40     ` Jeff King
2026-09-24 12:30       ` Julia Evans [this message]
2026-09-24 15:55         ` Jeff King
2026-09-24 17:15         ` Junio C Hamano
2026-09-24 17:22           ` Julia Evans
2026-09-24 18:17             ` Junio C Hamano
2026-09-24 18:42             ` Jeff King
2026-09-23 19:06 ` Kristoffer Haugsbakk
2026-09-23 22:00 ` Jeff King
2026-09-25  0:52 ` [PATCH v2] " Julia Evans via GitGitGadget
2026-09-25  8:27   ` Jeff King
2026-09-25 16:08     ` Rewriting the Git tutorial to cover less content Julia Evans
2026-09-25 16:47       ` Junio C Hamano
2026-09-25 17:25         ` Julia Evans
2026-09-25 18:23           ` Junio C Hamano
2026-09-25 19:22             ` Julia Evans
2026-09-25 19:34               ` Junio C Hamano
2026-09-28 12:21                 ` Julia Evans
2026-09-28 15:16                   ` Junio C Hamano

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=63520573-c8a7-41bd-aaeb-bfc2b5e43856@app.fastmail.com \
    --to=julia@jvns.ca \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=peff@peff.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