threads / patch / 18424

patchDocumentation/git-filter-branch.txt: Remove unnecessary URL quoting

Subject: [PATCH] Documentation/git-filter-branch.txt: Remove unnecessary URL quoting

## tl;dr

3 messages between Mar 19, 2009 and Mar 22, 2009. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Johan Herland· Mar 19, 2009, 23:12 UTC · lore

Embedding the URL in '+++' causes AsciiDoc (v8.4.1) to generate invalid XML. None of the other URLs in Git's documentation are quoted in this manner. There's no reason to treat this URL differently.

Signed-off-by: Johan Herland <johan@herland.net>
---
 Documentation/git-filter-branch.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Show changes to Documentation/git-filter-branch.txt +1 −1
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 237f85e..64b99d7 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -361,7 +361,7 @@ objects until you tell it to.  First make sure that:
 Then there are two ways to get a smaller repository.  A safer way is
 to clone, that keeps your original intact.
 
-* Clone it with `git clone +++file:///path/to/repo+++`.  The clone
+* Clone it with `git clone file:///path/to/repo`.  The clone
   will not have the removed objects.  See linkgit:git-clone[1].  (Note
   that cloning with a plain path just hardlinks everything!)
 
-- 
1.6.2.1.352.gae594.dirty
Thomas Rast· Mar 20, 2009, 15:19 UTC · re: Johan Herland · lore

Re: [PATCH] Documentation/git-filter-branch.txt: Remove unnecessary URL quoting

Johan Herland wrote:
Show 5 quoted lines
> Embedding the URL in '+++' causes AsciiDoc (v8.4.1) to generate invalid XML.
> None of the other URLs in Git's documentation are quoted in this manner.
> There's no reason to treat this URL differently.
> 
> Signed-off-by: Johan Herland <johan@herland.net>
[...]
> -* Clone it with `git clone +++file:///path/to/repo+++`.  The clone
> +* Clone it with `git clone file:///path/to/repo`.  The clone

I deliberately wrote it that way because *not* quoting it, at least on my box, formats the entire paragraph in monospace. Apparently it treats the ` as part of an autodetected URL or some such. This is independent of my choice of ASCIIDOC8 or DOCBOOK_XSL_172 settings. Am I missing another flag that avoids this problem?

I have these packages installed from opensuse:
  asciidoc-8.2.7-29.10
  docbook_4-4.5-111.8
  docbook-xsl-stylesheets-1.74.0-1.35
-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Johan Herland· Mar 22, 2009, 23:20 UTC · re: Thomas Rast · lore

Re: [PATCH] Documentation/git-filter-branch.txt: Remove unnecessary URL quoting

On Friday 20 March 2009, Thomas Rast wrote:
Show 15 quoted lines
> Johan Herland wrote:
> > Embedding the URL in '+++' causes AsciiDoc (v8.4.1) to generate invalid
> > XML. None of the other URLs in Git's documentation are quoted in this
> > manner. There's no reason to treat this URL differently.
>
> [...]
>
> > -* Clone it with `git clone +++file:///path/to/repo+++`.  The clone
> > +* Clone it with `git clone file:///path/to/repo`.  The clone
>
> I deliberately wrote it that way because *not* quoting it, at least on
> my box, formats the entire paragraph in monospace.  Apparently it
> treats the ` as part of an autodetected URL or some such.  This is
> independent of my choice of ASCIIDOC8 or DOCBOOK_XSL_172 settings.  Am
> I missing another flag that avoids this problem?
No, I think this is due to version differences in AsciiDoc.
> I have these packages installed from opensuse:
>   asciidoc-8.2.7-29.10

I use AsciiDoc v8.4.1 (from Arch Linux), and according to http://www.methods.co.nz/asciidoc/CHANGELOG.html there are some regression issues regarding backtick quoting and "inline literal passthrough"s when upgrading to v8.4.1. According to the changelog I should be able to revert AsciiDoc to the old behaviour by putting

  [attributes]
  no-inline-literal=

in my Documentation/asciidoc.conf. However, with this in place, I _still_ get invalid XML generated for git-filter-branch.txt... :(

So, it seems to be an AsciiDoc versioning issue. I'm not sure which of these AsciiDoc versions are preferable, of if it is possible to format the text in such a manner that it'll work in both versions.

...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net

← back to recent threads