{"thread":{"id":"23166","subject":"asciidoc problem, and a possible fix","startedAt":"2010-03-24T23:34:53Z","lastAt":"2010-03-29T06:38:47Z","messageCount":4,"participants":["hachi","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"137755","messageId":"4ABB29E2-6DB1-4712-A3E8-CD524983FB0B@kuiki.net","threadId":"23166","inReplyTo":null,"subject":"asciidoc problem, and a possible fix","fromName":"hachi","fromEmail":"hachi@kuiki.net","sentAt":"2010-03-24T23:34:53Z","receivedAt":"2010-03-24T23:34:53Z","isPatch":false,"sender":{"key":"hachi@kuiki.net","avatar":null},"body":"Hello folks,\n\nI had an issue building git on some centos 5 machines today, and in trying to interpret the error message I formed the attached patch.\n\nThe errors were:\nxmlto: input does not validate (status 1)\n/home/hachi/rpm/BUILD/git-1.7.0.3/Documentation/git-filter-branch.xml:463: parser error : PCDATA invalid Char value 7\nClone it with git clone +++0+++. The clone\n ^\n/home/hachi/rpm/BUILD/git-1.7.0.3/Documentation/git-filter-branch.xml:463: parser error : PCDATA invalid Char value 7\nClone it with git clone +++0+++. The clone\n\n\nI will happily admit that I don't know asciidoc, or the use of asciidoc in git.... but the +++ marker surrounding the url seems to not be used anywhere else in the documents directory, and I seem to be getting the appropriate output because of the `` surrounding the command.\n\nI'm not subscribed to the list, but I'll try to watch for replies. Would anyone like to either tell me I did this wrong, or apply my fix?\n\nThanks much,\n\nhachi\n\n\n\ndiff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt\nindex 020028c..4f71c17 100644\n--- a/Documentation/git-filter-branch.txt\n+++ b/Documentation/git-filter-branch.txt\n@@ -386,7 +386,7 @@ objects until you tell it to. First make sure that:\n Then there are two ways to get a smaller repository. A safer way is\n to clone, that keeps your original intact.\n \n-* Clone it with `git clone +++file:///path/to/repo+++`. The clone\n+* Clone it with `git clone file:///path/to/repo`. The clone\n will not have the removed objects. See linkgit:git-clone[1]. (Note\n that cloning with a plain path just hardlinks everything!)\n \n"},{"id":"137757","messageId":"7vljdhjk9r.fsf@alter.siamese.dyndns.org","threadId":"23166","inReplyTo":"4ABB29E2-6DB1-4712-A3E8-CD524983FB0B@kuiki.net","subject":"Re: asciidoc problem, and a possible fix","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-25T00:51:44Z","receivedAt":"2010-03-25T00:51:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"hachi writes:\n\n> I had an issue building git on some centos 5 machines today, and in trying to interpret the error message I formed the attached patch.\n>\n> The errors were:\n> xmlto: input does not validate (status 1)\n> /home/hachi/rpm/BUILD/git-1.7.0.3/Documentation/git-filter-branch.xml:463: parser error : PCDATA invalid Char value 7\n> Clone it with git clone +++0+++. The clone\n> ^\n\nA shot in the dark without sufficient information I could try to make is\nthat you are trying to use an ancient AsciiDoc, perhaps pre-7.1.2?\n\nI am guessing that the following entry from their ChangeLog:\n\n Version 7.1.2 (2006-03-07)\n --------------------------\n .Additions and changes\n ...\n - An 'inline passthrough' mechanism has been implemented.\n\nrefers to this \"triple-plus\" passthrough, documented in:\n\n http://www.methods.co.nz/asciidoc/userguide.html#X77\n\nAs the use of feature is isolated to only the documentation for filter-branch,\nI am personally Ok with replacing that passthru with a simpler formatting\nelement that is supported by an ancient version of AsciiDoc (but I didn't\nlook at your patch in the attachment).\n"},{"id":"137790","messageId":"167EA641-2D5F-4553-909C-DF5D050CEDFB@kuiki.net","threadId":"23166","inReplyTo":"7vljdhjk9r.fsf@alter.siamese.dyndns.org","subject":"Re: asciidoc problem, and a possible fix","fromName":"hachi","fromEmail":"hachi@kuiki.net","sentAt":"2010-03-25T09:15:21Z","receivedAt":"2010-03-25T09:15:21Z","isPatch":false,"sender":{"key":"hachi@kuiki.net","avatar":null},"body":"Junio,\n\nThe short version:\n\n>From asciidoc 8.4.1 to 8.5.0 nested inline passthrough (like +++ inside ``) cannot be used because the internal markers (\\x07, BEL) will be emitted in the output.\n\nasciidoc >= 8.4.2 will warn, and >= 8.5.0 will warn and do the right thing.\n\nThe +++ inside the `` that I'm getting rid of appear to be extraneous (I tested on an old 8.2.7 asciidoc).\n\nI suggest applying my patch because it seems to be the right thing overall. More gory details follow.\n\n\nThe long version:\n\nThanks for telling me what this feature was called, now the changelog makes sense about this.\n\nI'm running asciidoc 8.4.1, and in that version:\n\n* Backtick quoting for monospaced text is now implemented as an inline literal passthrough. This makes more sense since monospace text is usually intended to be rendered literally.\n\nwhich means that the line I'm on has a nested inline passthrough, of which a warning was added in asciidoc 8.4.2 (a quick test on a more modern distro shows):\n\nasciidoc: WARNING: git-filter-branch.txt: line 391: nested inline passthrough\n\nAnd then nested inline was fixed, in addition to the warning, in 8.5.0:\n\n* FIXED: Only the first occurrence of passthrough macro was substituted. Patch submitted by Peter Johnson. See http://groups.google.com/group/asciidoc/browse_frm/thread/1269dc2feb1a482c\n\n\nEnd conclusion:\n\n* Option 1\n\nMy patch is correct because nested inline passthrough doesn't do anything other than confuse the asciidoc parser. However, this means that prior to asciidoc 8.4.1 the inside of backtick strings are not inline passthrough. I have no idea if this is a bad thing, but it seems to not actually matter in my test using asciidoc 8.2.6.\n\nI do suggest applying my patch, actually. Let me know if I need to submit it a different way.\n\n* Option 2\n\nConsider enabling the asciidoc -a no-inline-literal option. This seems like it's a way to go back to the pre 8.4.1 behavior, but I can't tell if that's even right, and this seems to be a bad thing overall.\n\nThanks for reading, but I did tell you this was the long version down here ;)\n\n--hachi\n\nOn Mar 24, 2010, at 5:51 PM, Junio C Hamano wrote:\n\n> hachi writes:\n> \n>> I had an issue building git on some centos 5 machines today, and in trying to interpret the error message I formed the attached patch.\n>> \n>> The errors were:\n>> xmlto: input does not validate (status 1)\n>> /home/hachi/rpm/BUILD/git-1.7.0.3/Documentation/git-filter-branch.xml:463: parser error : PCDATA invalid Char value 7\n>> Clone it with git clone +++0+++. The clone\n>> ^\n> \n> A shot in the dark without sufficient information I could try to make is\n> that you are trying to use an ancient AsciiDoc, perhaps pre-7.1.2?\n> \n> I am guessing that the following entry from their ChangeLog:\n> \n> Version 7.1.2 (2006-03-07)\n> --------------------------\n> .Additions and changes\n> ...\n> - An 'inline passthrough' mechanism has been implemented.\n> \n> refers to this \"triple-plus\" passthrough, documented in:\n> \n> http://www.methods.co.nz/asciidoc/userguide.html#X77\n> \n> As the use of feature is isolated to only the documentation for filter-branch,\n> I am personally Ok with replacing that passthru with a simpler formatting\n> element that is supported by an ancient version of AsciiDoc (but I didn't\n> look at your patch in the attachment).\n> \n> \n"},{"id":"138057","messageId":"7vaatrbpjc.fsf@alter.siamese.dyndns.org","threadId":"23166","inReplyTo":"167EA641-2D5F-4553-909C-DF5D050CEDFB@kuiki.net","subject":"Re: asciidoc problem, and a possible fix","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-29T06:38:47Z","receivedAt":"2010-03-29T06:38:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"hachi writes:\n\n> The long version:\n> ...\n> End conclusion:\n\nThanks. The above analysis would be a good foundation for you to write a\nproper commit message when you submit a patch for application. Please see\nDocumentation/SubmittingPatches.\n\n> * Option 1\n>\n> My patch is correct because nested inline passthrough doesn't do\n> anything other than confuse the asciidoc parser. However, this means\n> that prior to asciidoc 8.4.1 the inside of backtick strings are not\n> inline passthrough. I have no idea if this is a bad thing, but it seems\n> to not actually matter in my test using asciidoc 8.2.6.\n\nI'd really want to avoid anything that does not work with AsciiDoc 8.2.5,\nas that is what is used to format the html/man branches at k.org.\n"}]}