{"thread":{"id":"5788","subject":"[PATCH] escape tilde in Documentation/git-rev-parse.txt","startedAt":"2006-10-02T18:55:05Z","lastAt":"2007-07-20T18:01:13Z","messageCount":23,"participants":["Stefan Richter","Junio C Hamano","Stuart Rackham","Gerrit Pape","Julian Phillips"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"28111","messageId":"tkrat.4532d38d43e16a62@s5r6.in-berlin.de","threadId":"5788","inReplyTo":null,"subject":"[PATCH] escape tilde in Documentation/git-rev-parse.txt","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2006-10-02T18:55:05Z","receivedAt":"2006-10-02T18:55:05Z","isPatch":true,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"fixes a failure to build the git-rev-parse manpage,\nseen with asciidoc 8.0.0\n\nSigned-off-by: Stefan Richter \n---\ndiff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\nindex b761b4b..671b4e3 100644\n--- a/Documentation/git-rev-parse.txt\n+++ b/Documentation/git-rev-parse.txt\n@@ -138,7 +138,7 @@ syntax.\n 'rev{caret}0' means the commit itself and is used when 'rev' is the\n object name of a tag object that refers to a commit object.\n \n-* A suffix '~' to a revision parameter means the commit\n+* A suffix '$$~$$' to a revision parameter means the commit\n object that is the th generation grand-parent of the named\n commit object, following only the first parent. I.e. rev~3 is\n equivalent to rev{caret}{caret}{caret} which is equivalent to\\\n"},{"id":"28130","messageId":"7vhcymt07a.fsf@assigned-by-dhcp.cox.net","threadId":"5788","inReplyTo":"tkrat.4532d38d43e16a62@s5r6.in-berlin.de","subject":"Re: [PATCH] escape tilde in Documentation/git-rev-parse.txt","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-03T05:52:57Z","receivedAt":"2006-10-03T05:52:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Richter writes:\n\n> fixes a failure to build the git-rev-parse manpage,\n> seen with asciidoc 8.0.0\n>\n> Signed-off-by: Stefan Richter \n> ---\n> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\n> index b761b4b..671b4e3 100644\n> --- a/Documentation/git-rev-parse.txt\n> +++ b/Documentation/git-rev-parse.txt\n> @@ -138,7 +138,7 @@ syntax.\n> 'rev{caret}0' means the commit itself and is used when 'rev' is the\n> object name of a tag object that refers to a commit object.\n> \n> -* A suffix '~' to a revision parameter means the commit\n> +* A suffix '$$~$$' to a revision parameter means the commit\n> object that is the th generation grand-parent of the named\n> commit object, following only the first parent. I.e. rev~3 is\n> equivalent to rev{caret}{caret}{caret} which is equivalent to\\\n\nBut this makes it asciidoc 7.1 barf, so we need an alternative\ncompatible to both.\n\nThis works for me on 7.1; is your 8.0 happy with it?\n\n-- >8 --\n\ndiff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf\nindex 8196d78..44b1ce4 100644\n--- a/Documentation/asciidoc.conf\n+++ b/Documentation/asciidoc.conf\n@@ -11,6 +11,7 @@ # the command.\n caret=^\n startsb=[\n endsb=]\n+tilde=~\n \n ifdef::backend-docbook[]\n [gitlink-inlinemacro]\ndiff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\nindex b761b4b..2f1306c 100644\n--- a/Documentation/git-rev-parse.txt\n+++ b/Documentation/git-rev-parse.txt\n@@ -138,7 +138,7 @@ syntax.\n 'rev{caret}0' means the commit itself and is used when 'rev' is the\n object name of a tag object that refers to a commit object.\n \n-* A suffix '~' to a revision parameter means the commit\n+* A suffix '{tilde}' to a revision parameter means the commit\n object that is the th generation grand-parent of the named\n commit object, following only the first parent. I.e. rev~3 is\n equivalent to rev{caret}{caret}{caret} which is equivalent to\\\n"},{"id":"28133","messageId":"452211C2.8020402@s5r6.in-berlin.de","threadId":"5788","inReplyTo":"7vhcymt07a.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] escape tilde in Documentation/git-rev-parse.txt","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2006-10-03T07:31:14Z","receivedAt":"2006-10-03T07:31:14Z","isPatch":true,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Junio C Hamano wrote:\n...\n> This works for me on 7.1; is your 8.0 happy with it?\n...\n> +tilde=~\n...\n> -* A suffix '~' to a revision parameter means the commit\n> +* A suffix '{tilde}' to a revision parameter means the commit\n...\n\nYes, this works as intended. Thanks,\n-- \nStefan Richter\n-=====-=-==- =-=- ---==\nhttp://arcgraph.de/sr/\n"},{"id":"28135","messageId":"7vven1rfpj.fsf@assigned-by-dhcp.cox.net","threadId":"5788","inReplyTo":"452211C2.8020402@s5r6.in-berlin.de","subject":"Re: [PATCH] escape tilde in Documentation/git-rev-parse.txt","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-03T08:00:56Z","receivedAt":"2006-10-03T08:00:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Richter writes:\n\n> Junio C Hamano wrote:\n> ...\n>> This works for me on 7.1; is your 8.0 happy with it?\n> ...\n>> +tilde=~\n> ...\n>> -* A suffix '~' to a revision parameter means the commit\n>> +* A suffix '{tilde}' to a revision parameter means the commit\n> ...\n>\n> Yes, this works as intended. Thanks,\n\nThanks. It's a bit sad that asciidoc's nicer quoting features\nare not backward compatible.\n"},{"id":"28145","messageId":"45222B18.1090305@s5r6.in-berlin.de","threadId":"5788","inReplyTo":"7vven1rfpj.fsf@assigned-by-dhcp.cox.net","subject":"pull-fetch-param.txt (was Re: [PATCH] escape tilde in Documentation/git-rev-parse.txt)","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2006-10-03T09:19:20Z","receivedAt":"2006-10-03T09:19:20Z","isPatch":true,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Junio C Hamano wrote:\n> It's a bit sad that asciidoc's nicer quoting features\n> are not backward compatible.\n\nYes, this is awkward. Here comes the next candidate for quoting.\nIn pull-fetch-param.txt:\n\n----8<----\n::\n\tThe canonical format of a parameter is\n\t`+?:`; that is, an optional plus `+`, followed\n\tby the source ref, followed by a colon `:`, followed by\n\tthe destination ref.\n+\nThe remote ref that matches \nis fetched, and if is not empty string, the local\nref that matches it is fast forwarded using .\nAgain, if the optional plus `+` is used, the local ref\n---->8----\n\n\"man git-fetch\" and \"man git-pull\" show:\n----8<----\n \n The canonical format of a parameter is ?:;\n that is, an optional plus, followed by the source ref, followed\n by a colon :, followed by the destination ref.\n\n The remote ref that matches is fetched, and if is\n not empty string, the local ref that matches it is fast for-\n warded using . Again, if the optional plus + is used, the\n---->8----\n\nI.e. the first and second + were swallowed, but not the third one.\nThis is the fix for asciidoc 8.0.0:\n\t`$$+$$?:`; that is, an optional plus `+`, followed\n\nHere is another fix that works with asciidoc 8.0.0:\n\t`\\+?:`; that is, an optional plus `+`, followed\n\nResults in\n----8<----\n \n The canonical format of a parameter is +?:;\n that is, an optional plus +, followed by the source ref, fol-\n lowed by a colon :, followed by the destination ref.\n\n The remote ref that matches is fetched, and if is\n not empty string, the local ref that matches it is fast for-\n warded using . Again, if the optional plus + is used, the\n---->8----\n\nDoes the backslash notation work with asciidoc 7?\n-- \nStefan Richter\n-=====-=-==- =-=- ---==\nhttp://arcgraph.de/sr/\n"},{"id":"28177","messageId":"7v64f1np8i.fsf@assigned-by-dhcp.cox.net","threadId":"5788","inReplyTo":"45222B18.1090305@s5r6.in-berlin.de","subject":"Re: pull-fetch-param.txt","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-03T20:01:01Z","receivedAt":"2006-10-03T20:01:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Richter writes:\n\n> Junio C Hamano wrote:\n>> It's a bit sad that asciidoc's nicer quoting features\n>> are not backward compatible.\n>\n> Yes, this is awkward. Here comes the next candidate for quoting.\n\n[Stuart Rackham CC'ed]\n\nAt this point I have to say\n\n\tWhat the h*ck AsciiDoc people are thinking?\n\nHeck, I thought we were one of the more important customers of\nasciidoc project and not breaking us meant at least something to\nthem; our name is at the top of \"Project using AsciiDoc\" section\nof their website, http:/www.methods.co.nz/asciidoc/. Apparently\nI was delusional.\n\nIntroducing nicer new features is a good thing, but you do not\nbreak existing documents without a good reason and an escape\nhatch.\n\nPut it more mildly, I think we need to find out what their\npolicy on backward compatibility is, and if it is \"screw it --\nyou should re-mark-up your documents to match the newer rule\nevery time we have a new release. By the way, you always have\nthe option to stay at older releases of ours\", then we should\nseriously consider switching the documentation format to\nsomething else. I honestly hope it does not have to come to\nthat.\n\n> In pull-fetch-param.txt:\n>\n> ----8<----\n> ::\n> \tThe canonical format of a parameter is\n> \t`+?:`; that is, an optional plus `+`, followed\n> \tby the source ref, followed by a colon `:`, followed by\n> \tthe destination ref.\n> +\n> The remote ref that matches \n> is fetched, and if is not empty string, the local\n> ref that matches it is fast forwarded using .\n> Again, if the optional plus `+` is used, the local ref\n> ---->8----\n>\n> \"man git-fetch\" and \"man git-pull\" show:\n> ----8<----\n> \n> The canonical format of a parameter is ?:;\n> that is, an optional plus, followed by the source ref, followed\n> by a colon :, followed by the destination ref.\n>\n> The remote ref that matches is fetched, and if is\n> not empty string, the local ref that matches it is fast for-\n> warded using . Again, if the optional plus + is used, the\n> ---->8----\n>\n> I.e. the first and second + were swallowed, but not the third one.\n> This is the fix for asciidoc 8.0.0:\n> \t`$$+$$?:`; that is, an optional plus `+`, followed\n\nWithout looking at asciidoc 8.0 source, my guess is that it\ntreats _anything_ that has two pluses on the same input line as\nquoted by some magical '+'-pair quote. Can you try\nreformatting the original\n\n> ::\n> \tThe canonical format of a parameter is\n> \t`+?:`; that is, an optional plus `+`, followed\n> \tby the source ref, followed by a colon `:`, followed by\n> \tthe destination ref.\n\nto something like\n\n> ::\n> \tThe canonical format of a parameter is\n> \t`+?:`; that is, an optional plus\n>\t`+`, followed\n> \tby the source ref, followed by a colon `:`, followed by\n> \tthe destination ref.\n\nand verify that conjecture?\n\nWe already had to deal with this with your patch for tilde.\nArguably tilde and caret are rare enough in plain text so we can\nlive with having to spell it as {caret} and {tilde}, but if my\nguess is correct, that means we have to spell plus '+' as {plus}\nwith an appropriate entry in asciidoc.conf (or \"\\+\" if it works\nin both older and newer versions). As more ordinary characters\nare taken for special mark-up purposes, we would need to keep\nadding them to our list. Where does the madness end?\n\nFortunately AsciiDoc 8.0 is still young. Maybe they can find a\nfix for this in a way that does not break documents written for\n(at least recent versions of) AsciiDoc 7; it might have to break\ndocuments written for early betas and the initial release of\n8.0, but that is _much_ better than breaking existing documents,\nin my extremely biased opinion as a very unhappy user.\n"},{"id":"28194","messageId":"4522E66B.4080103@methods.co.nz","threadId":"5788","inReplyTo":"7v64f1np8i.fsf@assigned-by-dhcp.cox.net","subject":"Re: pull-fetch-param.txt","fromName":"Stuart Rackham","fromEmail":"srackham@methods.co.nz","sentAt":"2006-10-03T22:38:35Z","receivedAt":"2006-10-03T22:38:35Z","isPatch":false,"sender":{"key":"srackham@methods.co.nz","avatar":null},"body":" From the AsciiDoc User Guide \n(http://www.methods.co.nz/asciidoc/userguide.html#X53):\n\nIf you want to disable unconstrained quotes, the new alternative \nconstrained quotes syntax and the new index entry syntax then you can \ndefine the attribute asciidoc7compatible (for example by using the -a \nasciidoc7compatible command-line option).\n\n--\nStuart Rackham\n\n\nJunio C Hamano wrote:\n> Stefan Richter writes:\n> \n>> Junio C Hamano wrote:\n>>> It's a bit sad that asciidoc's nicer quoting features\n>>> are not backward compatible.\n>> Yes, this is awkward. Here comes the next candidate for quoting.\n> \n> [Stuart Rackham CC'ed]\n> \n> At this point I have to say\n> \n> \tWhat the h*ck AsciiDoc people are thinking?\n> \n> Heck, I thought we were one of the more important customers of\n> asciidoc project and not breaking us meant at least something to\n> them; our name is at the top of \"Project using AsciiDoc\" section\n> of their website, http:/www.methods.co.nz/asciidoc/. Apparently\n> I was delusional.\n> \n> Introducing nicer new features is a good thing, but you do not\n> break existing documents without a good reason and an escape\n> hatch.\n> \n> Put it more mildly, I think we need to find out what their\n> policy on backward compatibility is, and if it is \"screw it --\n> you should re-mark-up your documents to match the newer rule\n> every time we have a new release. By the way, you always have\n> the option to stay at older releases of ours\", then we should\n> seriously consider switching the documentation format to\n> something else. I honestly hope it does not have to come to\n> that.\n> \n>> In pull-fetch-param.txt:\n>>\n>> ----8<----\n>> ::\n>> \tThe canonical format of a parameter is\n>> \t`+?:`; that is, an optional plus `+`, followed\n>> \tby the source ref, followed by a colon `:`, followed by\n>> \tthe destination ref.\n>> +\n>> The remote ref that matches \n>> is fetched, and if is not empty string, the local\n>> ref that matches it is fast forwarded using .\n>> Again, if the optional plus `+` is used, the local ref\n>> ---->8----\n>>\n>> \"man git-fetch\" and \"man git-pull\" show:\n>> ----8<----\n>> \n>> The canonical format of a parameter is ?:;\n>> that is, an optional plus, followed by the source ref, followed\n>> by a colon :, followed by the destination ref.\n>>\n>> The remote ref that matches is fetched, and if is\n>> not empty string, the local ref that matches it is fast for-\n>> warded using . Again, if the optional plus + is used, the\n>> ---->8----\n>>\n>> I.e. the first and second + were swallowed, but not the third one.\n>> This is the fix for asciidoc 8.0.0:\n>> \t`$$+$$?:`; that is, an optional plus `+`, followed\n> \n> Without looking at asciidoc 8.0 source, my guess is that it\n> treats _anything_ that has two pluses on the same input line as\n> quoted by some magical '+'-pair quote. Can you try\n> reformatting the original\n> \n>> ::\n>> \tThe canonical format of a parameter is\n>> \t`+?:`; that is, an optional plus `+`, followed\n>> \tby the source ref, followed by a colon `:`, followed by\n>> \tthe destination ref.\n> \n> to something like\n> \n>> ::\n>> \tThe canonical format of a parameter is\n>> \t`+?:`; that is, an optional plus\n>> \t`+`, followed\n>> \tby the source ref, followed by a colon `:`, followed by\n>> \tthe destination ref.\n> \n> and verify that conjecture?\n> \n> We already had to deal with this with your patch for tilde.\n> Arguably tilde and caret are rare enough in plain text so we can\n> live with having to spell it as {caret} and {tilde}, but if my\n> guess is correct, that means we have to spell plus '+' as {plus}\n> with an appropriate entry in asciidoc.conf (or \"\\+\" if it works\n> in both older and newer versions). As more ordinary characters\n> are taken for special mark-up purposes, we would need to keep\n> adding them to our list. Where does the madness end?\n> \n> Fortunately AsciiDoc 8.0 is still young. Maybe they can find a\n> fix for this in a way that does not break documents written for\n> (at least recent versions of) AsciiDoc 7; it might have to break\n> documents written for early betas and the initial release of\n> 8.0, but that is _much_ better than breaking existing documents,\n> in my extremely biased opinion as a very unhappy user.\n> \n"},{"id":"28195","messageId":"7vzmccltw2.fsf@assigned-by-dhcp.cox.net","threadId":"5788","inReplyTo":"4522E66B.4080103@methods.co.nz","subject":"Re: pull-fetch-param.txt","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-04T02:03:25Z","receivedAt":"2006-10-04T02:03:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stuart Rackham writes:\n\n> From the AsciiDoc User Guide\n> (http://www.methods.co.nz/asciidoc/userguide.html#X53):\n>\n> If you want to disable unconstrained quotes, the new alternative\n> constrained quotes syntax and the new index entry syntax then you can\n> define the attribute asciidoc7compatible (for example by using the -a\n> asciidoc7compatible command-line option).\n>\n> --\n> Stuart Rackham\n\nThank you for a quick reply.\n\nStefan, can you try it with the earlier commit to escape tilde\nreverted and see if our documentation set behaves well?\n"},{"id":"28211","messageId":"4523E120.6050007@s5r6.in-berlin.de","threadId":"5788","inReplyTo":"7v64f1np8i.fsf@assigned-by-dhcp.cox.net","subject":"Re: pull-fetch-param.txt","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2006-10-04T16:28:16Z","receivedAt":"2006-10-04T16:28:16Z","isPatch":false,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Junio C Hamano wrote:\n> Stefan Richter writes:\n...\n>> I.e. the first and second + were swallowed, but not the third one.\n...\n> Without looking at asciidoc 8.0 source, my guess is that it\n> treats _anything_ that has two pluses on the same input line as\n> quoted by some magical '+'-pair quote. Can you try\n> reformatting the original\n> \n>> ::\n>> \tThe canonical format of a parameter is\n>> \t`+?:`; that is, an optional plus `+`, followed\n>> \tby the source ref, followed by a colon `:`, followed by\n>> \tthe destination ref.\n> \n> to something like\n> \n>> ::\n>> \tThe canonical format of a parameter is\n>> \t`+?:`; that is, an optional plus\n>> \t`+`, followed\n>> \tby the source ref, followed by a colon `:`, followed by\n>> \tthe destination ref.\n> \n> and verify that conjecture?\n\nThis hack does not help. The two `+` are still absent from the manpage\n(but as before, the `+` in the next paragraph is printed as desired).\n-- \nStefan Richter\n-=====-=-==- =-=- --=--\nhttp://arcgraph.de/sr/\n"},{"id":"28212","messageId":"4523E401.5080709@s5r6.in-berlin.de","threadId":"5788","inReplyTo":"4522E66B.4080103@methods.co.nz","subject":"asciidoc 7--8 compatibility (was Re: pull-fetch-param.txt)","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2006-10-04T16:40:33Z","receivedAt":"2006-10-04T16:40:33Z","isPatch":false,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Stuart Rackham wrote:\n> From the AsciiDoc User Guide\n> (http://www.methods.co.nz/asciidoc/userguide.html#X53):\n> \n> If you want to disable unconstrained quotes, the new alternative\n> constrained quotes syntax and the new index entry syntax then you can\n> define the attribute asciidoc7compatible (for example by using the -a\n> asciidoc7compatible command-line option).\n\nStuart,\n\nthe actual issues were:\n\n1.) Input which works with asciidoc 7 fails to build with asciidoc 8\n(after the intermediary XML step). This pair of tildes broke (but other\noccurences of tilde did not):\n\n| * A suffix '~' to a revision parameter means the commit\n| object that is the th generation grand-parent of the named\n| commit object, following only the first parent. I.e. rev~3 is\n\n2.) Asciidoc 8 silently swallows characters from input which works with\nasciidoc 7. The two pluses in the following line vanished (but instances\nof single pluses per input line did not vanish):\n\n| \t`+?:`; that is, an optional plus `+`, followed\n\nI wonder:\n\n - Are tilde and plus new special characters in asciidoc 8, or were they\nalready special characters in asciidoc 7?\n [ A pair of single pluses encloses monospaced text in asciidoc 8.\n A pair of single tildes encloses subscripts. ]\n\n - If they were already special characters in asciidoc 7, what is the\ncanonical way to escape them in asciidoc 7, 8, and hopefully 9?\n [ If they weren't special characters in asciidoc 7, then we need\n to use the asciidoc7compatible attribute. ]\n\n - Does asciidoc 7 accept the asciidoc7compatible attribute?\n\nThanks.\n\n\nPS:\n\nJunio, Stuart, here is another inconsistency between asciidoc 7 and 8.\nPlease have a look at\nhttp://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html .\nSee the ASCII art above \"SPECIFYING RANGES\". The input\n \\ | / \\\n \\ | / |\nproduced\n \\ | / \\ | / |\nI.e. backslash-newline was interpreted by asciidoc 7 (or whatever you\nuse to generate what is put online) as an escaped thus swallowed\nnewline. But the output that I got here from asciidoc 8 (manpage as well\nas the html file) still has backslash and newline printed out.\n-- \nStefan Richter\n-=====-=-==- =-=- --=--\nhttp://arcgraph.de/sr/\n"},{"id":"28214","messageId":"4523EC14.6070806@s5r6.in-berlin.de","threadId":"5788","inReplyTo":"4523E120.6050007@s5r6.in-berlin.de","subject":"Re: pull-fetch-param.txt","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2006-10-04T17:15:00Z","receivedAt":"2006-10-04T17:15:00Z","isPatch":false,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"I wrote:\n> Junio C Hamano wrote:\n>> Can you try reformatting the original\n>>\n>>> ::\n>>> \tThe canonical format of a parameter is\n>>> \t`+?:`; that is, an optional plus `+`, followed\n>>> \tby the source ref, followed by a colon `:`, followed by\n>>> \tthe destination ref.\n>> to something like\n>>\n>>> ::\n>>> \tThe canonical format of a parameter is\n>>> \t`+?:`; that is, an optional plus\n>>> \t`+`, followed\n>>> \tby the source ref, followed by a colon `:`, followed by\n>>> \tthe destination ref.\n>> and verify that conjecture?\n> \n> This hack does not help. The two `+` are still absent from the manpage\n> (but as before, the `+` in the next paragraph is printed as desired).\n\nAfter a few more experiments with different placements of backticks et\ncetera, I found only the following variants to work with asciidoc 8:\n\n(as mentioned, not compatible to asciidoc 7):\n\t`$$+$$?:`; that is, an optional plus `+`, followed\n\n(as mentioned, compatible)\n\t`\\+?:`; that is, an optional plus `+`, followed\n\n(also OK, and this is probably the only really correct syntax)\n\t`\\+?:`; that is, an optional plus `\\+`, followed\n\n(also OK but misses the monospace formatting on the plus or on the plus\nand questionmark)\n\t\\+`?:`; that is, an optional plus `+`, followed\n\t\\+?`:`; that is, an optional plus `+`, followed\n\t\\+?`:`; that is, an optional plus \\+, followed\n\t`\\+?:`; that is, an optional plus +, followed\n\nNote,\n\t`+``?:`; that is, an optional plus `+`, followed\ndoes _not_ work. It stops on invalid syntax in the intermediary xml\nfile. Also\n\t+\\+?:+; that is, an optional plus `+`, followed\nor\n\t`+`+?:+; that is, an optional plus `+`, followed\ndo _not_ work. They don't print what we want to see.\n-- \nStefan Richter\n-=====-=-==- =-=- --=--\nhttp://arcgraph.de/sr/\n"},{"id":"28215","messageId":"4524226D.5000305@methods.co.nz","threadId":"5788","inReplyTo":"4523E401.5080709@s5r6.in-berlin.de","subject":"Re: asciidoc 7--8 compatibility (was Re: pull-fetch-param.txt)","fromName":"Stuart Rackham","fromEmail":"srackham@methods.co.nz","sentAt":"2006-10-04T21:06:53Z","receivedAt":"2006-10-04T21:06:53Z","isPatch":false,"sender":{"key":"srackham@methods.co.nz","avatar":null},"body":"Hi Stefan\n\nStefan Richter wrote:\n> Stuart Rackham wrote:\n>> From the AsciiDoc User Guide\n>> (http://www.methods.co.nz/asciidoc/userguide.html#X53):\n>>\n>> If you want to disable unconstrained quotes, the new alternative\n>> constrained quotes syntax and the new index entry syntax then you can\n>> define the attribute asciidoc7compatible (for example by using the -a\n>> asciidoc7compatible command-line option).\n> \n> Stuart,\n> \n> the actual issues were:\n> \n> 1.) Input which works with asciidoc 7 fails to build with asciidoc 8\n> (after the intermediary XML step). This pair of tildes broke (but other\n> occurences of tilde did not):\n> \n> | * A suffix '~' to a revision parameter means the commit\n> | object that is the th generation grand-parent of the named\n> | commit object, following only the first parent. I.e. rev~3 is\n\nI've conditionally redefined subscript (tilde) and superscripting so \nthey use the old replacements mechanism when asciidoc7compatible is \ndefined rather than the asciidoc 8 default unconstrained quoting (patch \nfor affected files attached).\n\n\n> \n> 2.) Asciidoc 8 silently swallows characters from input which works with\n> asciidoc 7. The two pluses in the following line vanished (but instances\n> of single pluses per input line did not vanish):\n> \n> | \t`+?:`; that is, an optional plus `+`, followed\n\nFixed by asciidoc7compatible.\n\n\n> \n> I wonder:\n> \n> - Are tilde and plus new special characters in asciidoc 8, or were they\n> already special characters in asciidoc 7?\n> [ A pair of single pluses encloses monospaced text in asciidoc 8.\n> A pair of single tildes encloses subscripts. ]\n> \n> - If they were already special characters in asciidoc 7, what is the\n> canonical way to escape them in asciidoc 7, 8, and hopefully 9?\n> [ If they weren't special characters in asciidoc 7, then we need\n> to use the asciidoc7compatible attribute. ]\n> \n> - Does asciidoc 7 accept the asciidoc7compatible attribute?\n\nNo.\n\n\n> \n> Thanks.\n> \n> \n> PS:\n> \n> Junio, Stuart, here is another inconsistency between asciidoc 7 and 8.\n> Please have a look at\n> http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html .\n> See the ASCII art above \"SPECIFYING RANGES\". The input\n> \\ | / \\\n> \\ | / |\n> produced\n> \\ | / \\ | / |\n> I.e. backslash-newline was interpreted by asciidoc 7 (or whatever you\n> use to generate what is put online) as an escaped thus swallowed\n> newline. But the output that I got here from asciidoc 8 (manpage as well\n> as the html file) still has backslash and newline printed out.\n\n\nCheers, Stuart\n\n\nIndex: asciidoc.conf\n===================================================================\n--- asciidoc.conf\t(revision 53)\n+++ asciidoc.conf\t(working copy)\n@@ -62,9 +62,9 @@\n __=#emphasis\n ++=#monospaced\n \\##=#unquoted\n-endif::asciidoc7compatible[]\n ^=#superscript\n ~=#subscript\n+endif::asciidoc7compatible[]\n \n [specialwords]\n emphasizedwords=\nIndex: xhtml11.conf\n===================================================================\n--- xhtml11.conf\t(revision 53)\n+++ xhtml11.conf\t(working copy)\n@@ -22,6 +22,12 @@\n \\$=\\$\n `=\\`\n endif::asciimath[]\n+ifdef::asciidoc7compatible[]\n+# Superscripts.\n+\\^(.+?)\\^=\\1\n+# Subscripts.\n+~(.+?)~=\\1\n+endif::asciidoc7compatible[]\n \n [ruler-blockmacro]\n
\nIndex: docbook.conf\n===================================================================\n--- docbook.conf\t(revision 53)\n+++ docbook.conf\t(working copy)\n@@ -18,6 +18,12 @@\n [replacements]\n # Line break markup is dropped (there is no DocBook line break tag).\n (?m)^(.*)\\s\\+$=\\1\n+ifdef::asciidoc7compatible[]\n+# Superscripts.\n+\\^(.+?)\\^=\\1\n+# Subscripts.\n+~(.+?)~=\\1\n+endif::asciidoc7compatible[]\n \n [ruler-blockmacro]\n # Only applies to HTML so don't output anything.\nIndex: html4.conf\n===================================================================\n--- html4.conf\t(revision 53)\n+++ html4.conf\t(working copy)\n@@ -18,6 +18,12 @@\n [replacements]\n # Line break.\n (?m)^(.*)\\s\\+$=\\1
\n+ifdef::asciidoc7compatible[]\n+# Superscripts.\n+\\^(.+?)\\^=\\1\n+# Subscripts.\n+~(.+?)~=\\1\n+endif::asciidoc7compatible[]\n \n [ruler-blockmacro]\n
\n"},{"id":"28216","messageId":"4524343B.8060709@s5r6.in-berlin.de","threadId":"5788","inReplyTo":"4524226D.5000305@methods.co.nz","subject":"Re: asciidoc 7--8 compatibility","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2006-10-04T22:22:51Z","receivedAt":"2006-10-04T22:22:51Z","isPatch":false,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Stuart Rackham wrote:\n> --- asciidoc.conf\t(revision 53)\n> +++ asciidoc.conf\t(working copy)\n> @@ -62,9 +62,9 @@\n> __=#emphasis\n> ++=#monospaced\n> \\##=#unquoted\n> -endif::asciidoc7compatible[]\n> ^=#superscript\n> ~=#subscript\n> +endif::asciidoc7compatible[]\n\nCould git/Documentation/asciidoc.conf just kill all the various meanings\nof +, ~, ^ and make them into regular characters? In a way that works\nwith all versions of asciidoc?\n\n(Frankly, using + as a special character may sound like a neat idea if\nall one wants to do is to typeset poems.)\n-- \nStefan Richter\n-=====-=-==- =-=- --=--\nhttp://arcgraph.de/sr/\n"},{"id":"28217","messageId":"45244671.4030509@methods.co.nz","threadId":"5788","inReplyTo":"4524343B.8060709@s5r6.in-berlin.de","subject":"Re: asciidoc 7--8 compatibility","fromName":"Stuart Rackham","fromEmail":"srackham@methods.co.nz","sentAt":"2006-10-04T23:40:33Z","receivedAt":"2006-10-04T23:40:33Z","isPatch":false,"sender":{"key":"srackham@methods.co.nz","avatar":null},"body":"Stefan Richter wrote:\n> Stuart Rackham wrote:\n>> --- asciidoc.conf\t(revision 53)\n>> +++ asciidoc.conf\t(working copy)\n>> @@ -62,9 +62,9 @@\n>> __=#emphasis\n>> ++=#monospaced\n>> \\##=#unquoted\n>> -endif::asciidoc7compatible[]\n>> ^=#superscript\n>> ~=#subscript\n>> +endif::asciidoc7compatible[]\n> \n> Could git/Documentation/asciidoc.conf just kill all the various meanings\n> of +, ~, ^ and make them into regular characters? In a way that works\n> with all versions of asciidoc?\n\n[quotes]\n^=\n~=\n+=\n\n From the AsciiDoc User Guide: \"A configuration file [quotes] entry can \nbe subsequently undefined by setting it to a blank value.\"\n\n\n> \n> (Frankly, using + as a special character may sound like a neat idea if\n> all one wants to do is to typeset poems.)\n\nThe rationale for the + is discussed in the AsciiDoc changelog \n(http://www.methods.co.nz/asciidoc/CHANGELOG.html). It also brings \nAsciiDoc in line with the Ruby RDoc source code documentation system syntax.\n\n\n--\nStuart Rackham\n"},{"id":"47154","messageId":"20070712130631.13667.qmail@594d46613ccd9b.315fe32.mid.smarden.org","threadId":"5788","inReplyTo":"45222B18.1090305@s5r6.in-berlin.de","subject":"Re: pull-fetch-param.txt (was Re: [PATCH] escape tilde in Documentation/git-rev-parse.txt)","fromName":"Gerrit Pape","fromEmail":"pape@smarden.org","sentAt":"2007-07-12T13:06:31Z","receivedAt":"2007-07-12T13:06:31Z","isPatch":true,"sender":{"key":"pape@smarden.org","avatar":"https://avatars.githubusercontent.com/u/143170252?v=4"},"body":"On Tue, Oct 03, 2006 at 11:19:20AM +0200, Stefan Richter wrote:\n> Junio C Hamano wrote:\n> > It's a bit sad that asciidoc's nicer quoting features\n> > are not backward compatible.\n> \n> Yes, this is awkward. Here comes the next candidate for quoting.\n> In pull-fetch-param.txt:\n> \n> ----8<----\n> ::\n> \tThe canonical format of a parameter is\n> \t`+?:`; that is, an optional plus `+`, followed\n> \tby the source ref, followed by a colon `:`, followed by\n> \tthe destination ref.\n> +\n> The remote ref that matches \n> is fetched, and if is not empty string, the local\n> ref that matches it is fast forwarded using .\n> Again, if the optional plus `+` is used, the local ref\n> ---->8----\n> \n> \"man git-fetch\" and \"man git-pull\" show:\n> ----8<----\n> \n> The canonical format of a parameter is ?:;\n> that is, an optional plus, followed by the source ref, followed\n> by a colon :, followed by the destination ref.\n> \n> The remote ref that matches is fetched, and if is\n> not empty string, the local ref that matches it is fast for-\n> warded using . Again, if the optional plus + is used, the\n> ---->8----\n\nHi, this still is a problem, at least on Debian/unstable; with asciidoc\n8.2.1, the git-push(1) and git-fetch(1) man pages have this 'broken'\nrefspec description[0].\n\nAdditionally there're problems with callouts, whereever is used to\nrefer to a callout list, it renders broken man pages[1], e.g.:\n\n $ man git-reset\n [...]\n EXAMPLES\n Undo a commit and redo\n \n $ git commit ...\n $ git reset --soft HEAD^ \\fB(1)\\fR\n $ edit \\fB(2)\\fR\n $ git commit -a -c ORIG_HEAD \\fB(3)\\fR\n .sp \\fB1. \\fRThis is most often done when you remembered what you\n just committed is incomplete, or you misspelled your commit\n message, or both. Leaves working tree as it was before \"reset\".\n \n .br \\fB2. \\fRmake corrections to working tree files.\n \n .br \\fB3. \\fR\"reset\" copies the old head to .git/ORIG_HEAD; redo\n the commit by starting with its log message. If you do not need to\n edit the message further, you can give -C option instead.\n \n See also the --amend option to git-commit(1).\n \n .br\n \n Undo commits permanently\n \n $ git commit ...\n $ git reset --hard HEAD~3 \\fB(1)\\fR\n .sp \\fB1. \\fRThe last three commits (HEAD, HEAD^, and HEAD~2) were\n bad and you do not want to ever see them again. Do not do this if\n you have already given these commits to somebody else.\n \n .br\n \n Undo a commit, making it a topic branch\n [...]\n\n\nRegards, Gerrit.\n\n[0] http://bugs.debian.org/432560\n[1] http://bugs.debian.org/420114\n"},{"id":"47210","messageId":"7vvecps2rz.fsf@assigned-by-dhcp.cox.net","threadId":"5788","inReplyTo":"20070712130631.13667.qmail@594d46613ccd9b.315fe32.mid.smarden.org","subject":"Re: pull-fetch-param.txt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-12T21:58:08Z","receivedAt":"2007-07-12T21:58:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gerrit Pape writes:\n\n> Hi, this still is a problem, at least on Debian/unstable; with asciidoc\n> 8.2.1, the git-push(1) and git-fetch(1) man pages have this 'broken'\n> refspec description[0].\n\nQuick question. Is the build done with \"make\nASCIIDOC8=YesPlease\"?\n"},{"id":"47234","messageId":"20070713055346.634.qmail@1e54e4f4e1041d.315fe32.mid.smarden.org","threadId":"5788","inReplyTo":"7vvecps2rz.fsf@assigned-by-dhcp.cox.net","subject":"Re: pull-fetch-param.txt","fromName":"Gerrit Pape","fromEmail":"pape@smarden.org","sentAt":"2007-07-13T05:53:46Z","receivedAt":"2007-07-13T05:53:46Z","isPatch":false,"sender":{"key":"pape@smarden.org","avatar":"https://avatars.githubusercontent.com/u/143170252?v=4"},"body":"On Thu, Jul 12, 2007 at 02:58:08PM -0700, Junio C Hamano wrote:\n> Gerrit Pape writes:\n> > Hi, this still is a problem, at least on Debian/unstable; with asciidoc\n> > 8.2.1, the git-push(1) and git-fetch(1) man pages have this 'broken'\n> > refspec description[0].\n> \n> Quick question. Is the build done with \"make\n> ASCIIDOC8=YesPlease\"?\n\nNo, must have missed that. This solves the first issue with the refspec\nin git-push(1), git-fetch(1), but not the second one with callout lists.\n\nThanks, Gerrit.\n"},{"id":"47240","messageId":"7vejjcpyb5.fsf@assigned-by-dhcp.cox.net","threadId":"5788","inReplyTo":"20070713055346.634.qmail@1e54e4f4e1041d.315fe32.mid.smarden.org","subject":"Re: pull-fetch-param.txt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-13T07:17:34Z","receivedAt":"2007-07-13T07:17:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gerrit Pape writes:\n\n>> Quick question. Is the build done with \"make\n>> ASCIIDOC8=YesPlease\"?\n>\n> No, must have missed that. This solves the first issue ...\n> ..., but not the second one with callout lists.\n\nSorry, does not reproduce for me, with asciidoc 8.2.1. There\nmust be something different between our environments.\n\nHere is an excerpt from what I get for git-reset.txt in\ngit-reset.1:\n\n-- >8 --\n.\\\" Title: git\\-reset\n.\\\" Author: \n.\\\" Generator: DocBook XSL Stylesheets v1.71.0 \n.\\\" Date: 07/13/2007\n.\\\" Manual: Git Manual\n.\\\" Source: Git 1.5.3.rc1.4.gaf83\n\n ...\n\n.SH \"EXAMPLES\"\n.PP\nUndo a commit and redo\n.RS 3n\n.sp\n.RS 3n\n.nf\n$ git commit ...\n$ git reset \\-\\-soft HEAD^ \\fB(1)\\fR\n$ edit \\fB(2)\\fR\n$ git commit \\-a \\-c ORIG_HEAD \\fB(3)\\fR\n.fi\n.RE\n.sp\n\\fB1. \\fRThis is most often done when you remembered what you just committed is incomplete, or you misspelled your commit message, or both. Leaves working tree as it was before \"reset\".\n.br\n\\fB2. \\fRmake corrections to working tree files.\n.br\n\\fB3. \\fR\"reset\" copies the old head to .git/ORIG_HEAD; redo the commit by starting with its log message. If you do not need to edit the message further, you can give \\-C option instead.\n\nSee also the \\-\\-amend option to \\fBgit\\-commit\\fR(1).\n.br\n.RE\n-- 8< --\n\nand \"man -l git-reset.1\" seems to show the callouts just fine.\n\n-- >8 --\n ...\nEXAMPLES\n Undo a commit and redo\n\n $ git commit ...\n $ git reset --soft HEAD^ (1)\n $ edit (2)\n $ git commit -a -c ORIG_HEAD (3)\n\n 1. This is most often done when you remembered what you just\n committed is incomplete, or you misspelled your commit message,\n or both. Leaves working tree as it was before \"reset\".\n 2. make corrections to working tree files.\n 3. \"reset\" copies the old head to .git/ORIG_HEAD; redo the\n commit by starting with its log message. If you do not need to\n edit the message further, you can give -C option instead.\n\n See also the --amend option to git-commit(1).\n-- 8< --\n"},{"id":"47241","messageId":"20070713074824.9806.qmail@df2dc1a3890a6b.315fe32.mid.smarden.org","threadId":"5788","inReplyTo":"7vejjcpyb5.fsf@assigned-by-dhcp.cox.net","subject":"Re: pull-fetch-param.txt","fromName":"Gerrit Pape","fromEmail":"pape@smarden.org","sentAt":"2007-07-13T07:48:24Z","receivedAt":"2007-07-13T07:48:24Z","isPatch":false,"sender":{"key":"pape@smarden.org","avatar":"https://avatars.githubusercontent.com/u/143170252?v=4"},"body":"On Fri, Jul 13, 2007 at 12:17:34AM -0700, Junio C Hamano wrote:\n> Gerrit Pape writes:\n> >> Quick question. Is the build done with \"make\n> >> ASCIIDOC8=YesPlease\"?\n> >\n> > No, must have missed that. This solves the first issue ...\n> > ..., but not the second one with callout lists.\n> \n> Sorry, does not reproduce for me, with asciidoc 8.2.1. There\n> must be something different between our environments.\n\nYes, I have docbook-xsl 1.72.0.\n\n> Here is an excerpt from what I get for git-reset.txt in\n> git-reset.1:\n> \n> -- >8 --\n> .\\\" Title: git\\-reset\n> .\\\" Author: \n> .\\\" Generator: DocBook XSL Stylesheets v1.71.0 \n> .\\\" Date: 07/13/2007\n> .\\\" Manual: Git Manual\n> .\\\" Source: Git 1.5.3.rc1.4.gaf83\n> \n> ...\n> \n> .SH \"EXAMPLES\"\n> .PP\n> Undo a commit and redo\n> .RS 3n\n> .sp\n> .RS 3n\n> .nf\n> $ git commit ...\n> $ git reset \\-\\-soft HEAD^ \\fB(1)\\fR\n> $ edit \\fB(2)\\fR\n> $ git commit \\-a \\-c ORIG_HEAD \\fB(3)\\fR\n\nI get the same with docbook-xsl 1.71.0, but with 1.72.0:\n\n.\\\" Title: git-reset\n.\\\" Author: \n.\\\" Generator: DocBook XSL Stylesheets v1.72.0 \n.\\\" Date: 07/13/2007\n.\\\" Manual: Git Manual\n.\\\" Source: Git 1.5.3.rc0.104.g71f98\n[...]\n.SH \"EXAMPLES\"\n.PP\nUndo a commit and redo\n.RS 4\n.sp\n.RS 4\n.nf\n$ git commit ...\n$ git reset \\-\\-soft HEAD^ \\efB(1)\\efR\n$ edit \\efB(2)\\efR\n$ git commit \\-a \\-c ORIG_HEAD \\efB(3)\\efR\n.fi\n.RE\n\\&.sp\n\\efB1. \\efRThis is most often done when you remembered what you just committed is incomplete, or you misspelled your commit message, or both. Leaves working tree as it was before \"reset\".\n\n\\&.br\n\\efB2. \\efRmake corrections to working tree files.\n\n\\&.br\n\\efB3. \\efR\"reset\" copies the old head to .git/ORIG_HEAD; redo the commit by starting with its log message. If you do not need to edit the message further, you can give \\-C option instead.\n\n\nI'll check with the docbook-xsl Debian maintainer.\n\nThanks, Gerrit.\n"},{"id":"47967","messageId":"20070720143214.23897.qmail@511f57d39b0a54.315fe32.mid.smarden.org","threadId":"5788","inReplyTo":"20070713074824.9806.qmail@df2dc1a3890a6b.315fe32.mid.smarden.org","subject":"Re: pull-fetch-param.txt","fromName":"Gerrit Pape","fromEmail":"pape@smarden.org","sentAt":"2007-07-20T14:32:14Z","receivedAt":"2007-07-20T14:32:14Z","isPatch":false,"sender":{"key":"pape@smarden.org","avatar":"https://avatars.githubusercontent.com/u/143170252?v=4"},"body":"On Fri, Jul 13, 2007 at 07:48:24AM +0000, Gerrit Pape wrote:\n> On Fri, Jul 13, 2007 at 12:17:34AM -0700, Junio C Hamano wrote:\n> > Sorry, does not reproduce for me, with asciidoc 8.2.1. There\n> > must be something different between our environments.\n> \n> Yes, I have docbook-xsl 1.72.0.\n\n> > $ git commit \\-a \\-c ORIG_HEAD \\fB(3)\\fR\n> \n> I get the same with docbook-xsl 1.71.0, but with 1.72.0:\n\n> $ git commit \\-a \\-c ORIG_HEAD \\efB(3)\\efR\n\n> I'll check with the docbook-xsl Debian maintainer.\n\nThe change in docbook-xsl was by intention, please see\n http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420114#22\n\nRegards, Gerrit.\n"},{"id":"47972","messageId":"7vbqe7xbvq.fsf@assigned-by-dhcp.cox.net","threadId":"5788","inReplyTo":"20070720143214.23897.qmail@511f57d39b0a54.315fe32.mid.smarden.org","subject":"Re: pull-fetch-param.txt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-20T16:45:13Z","receivedAt":"2007-07-20T16:45:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gerrit Pape writes:\n\n>> I'll check with the docbook-xsl Debian maintainer.\n>\n> The change in docbook-xsl was by intention, please see\n> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420114#22\n\nHmph. Where does that leave us poor users who would want to\nsupport both 1.71 and 1.72, I wonder...\n\nWill they have the same revert in 1.73 for that House Sign, too?\n"},{"id":"47973","messageId":"Pine.LNX.4.64.0707201758330.26817@reaper.quantumfyre.co.uk","threadId":"5788","inReplyTo":"7vbqe7xbvq.fsf@assigned-by-dhcp.cox.net","subject":"Re: pull-fetch-param.txt","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-07-20T17:09:07Z","receivedAt":"2007-07-20T17:09:07Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Fri, 20 Jul 2007, Junio C Hamano wrote:\n\n> Gerrit Pape writes:\n>\n>>> I'll check with the docbook-xsl Debian maintainer.\n>>\n>> The change in docbook-xsl was by intention, please see\n>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420114#22\n>\n> Hmph. Where does that leave us poor users who would want to\n> support both 1.71 and 1.72, I wonder...\n>\n> Will they have the same revert in 1.73 for that House Sign, too?\n\nIt looks like they do, so perhaps we could just say that you will have \nissues building the git docs with 1.72 and ignore my last patch?\n\n(comparing http://docbook.xml-doc.org/snapshots/xsl/manpages/utility.xsl \nwhich has today's date and uses . and \\ against \nhttp://docbook.sourceforge.net/release/xsl/1.72.0/manpages/utility.xsl \nwhich uses U+2302 and U+2593)\n\n-- \nJulian\n\n ---\nOld MacDonald had an agricultural real estate tax abatement.\n"},{"id":"47977","messageId":"7v1wf3x8d2.fsf@assigned-by-dhcp.cox.net","threadId":"5788","inReplyTo":"Pine.LNX.4.64.0707201758330.26817@reaper.quantumfyre.co.uk","subject":"Re: pull-fetch-param.txt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-20T18:01:13Z","receivedAt":"2007-07-20T18:01:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julian Phillips writes:\n\n> On Fri, 20 Jul 2007, Junio C Hamano wrote:\n> ...\n>> Hmph. Where does that leave us poor users who would want to\n>> support both 1.71 and 1.72, I wonder...\n>>\n>> Will they have the same revert in 1.73 for that House Sign, too?\n>\n> It looks like they do, so perhaps we could just say that you will have\n> issues building the git docs with 1.72 and ignore my last patch?\n\nThat actually sounds a very tempting thing to do, especially\nconsidering we are past -rc2.\n"}]}