{"thread":{"id":"9607","subject":"[PATCH] Fix break in git-rev-list.txt","startedAt":"2007-08-22T08:18:03Z","lastAt":"2007-08-22T16:45:43Z","messageCount":6,"participants":["Quy Tonthat","Junio C Hamano","David Kastrup"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"51227","messageId":"11877706831306-git-send-email-qtonthat@gmail.com","threadId":"9607","inReplyTo":null,"subject":"[PATCH] Fix break in git-rev-list.txt","fromName":"Quy Tonthat","fromEmail":"qtonthat@gmail.com","sentAt":"2007-08-22T08:18:03Z","receivedAt":"2007-08-22T08:18:03Z","isPatch":true,"sender":{"key":"qtonthat@gmail.com","avatar":null},"body":"Also fix some innocent missing of quotes.\n\nSigned-off-by: Quy Tonthat <qtonthat@gmail.com>\n---\n Documentation/git-rev-list.txt |    6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt\nindex cbbc234..a0c611e 100644\n--- a/Documentation/git-rev-list.txt\n+++ b/Documentation/git-rev-list.txt\n@@ -298,8 +298,8 @@ used in the output.  When the starting commit is specified as\n 'commit@{now}', output also uses 'commit@\\{timestamp}' notation\n instead.  Under '\\--pretty=oneline', the commit message is\n prefixed with this information on the same line.\n-+\n-Cannot be combined with --reverse.\n+\n+Cannot be combined with '\\--reverse'.\n \n --merge::\n \n@@ -375,7 +375,7 @@ By default, the commits are shown in reverse chronological order.\n --reverse::\n \n \tOutput the commits in reverse order.\n-\tCannot be combined with --walk-reflogs.\n+\tCannot be combined with '\\--walk-reflogs'.\n \n Object Traversal\n ~~~~~~~~~~~~~~~~\n-- \n1.5.3.rc5.1q\n"},{"id":"51234","messageId":"7vbqczkhvb.fsf@gitster.siamese.dyndns.org","threadId":"9607","inReplyTo":"11877706831306-git-send-email-qtonthat@gmail.com","subject":"Re: [PATCH] Fix break in git-rev-list.txt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-22T10:01:44Z","receivedAt":"2007-08-22T10:01:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Quy Tonthat <qtonthat@gmail.com> writes:\n\n> diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt\n> index cbbc234..a0c611e 100644\n> --- a/Documentation/git-rev-list.txt\n> +++ b/Documentation/git-rev-list.txt\n> @@ -298,8 +298,8 @@ used in the output.  When the starting commit is specified as\n>  'commit@{now}', output also uses 'commit@\\{timestamp}' notation\n>  instead.  Under '\\--pretty=oneline', the commit message is\n>  prefixed with this information on the same line.\n> -+\n> -Cannot be combined with --reverse.\n> +\n> +Cannot be combined with '\\--reverse'.\n\nHmph.  Interesting.  The text around this is:\n\n\t-g, --wark-reflogs::\n\n        \tIndented first paragraph...\n\t+\n        With '\\--pretty' fromat ... second paragraph ...\n\tprefixed with this information on the same line.\n\t+\n        Cannot be combined with --reverse.\n\nAnd its formatted form looks like either (without your patch):\n\n\t<listitem>\n        <simpara>\n        \tIndented first paragraph...\n\tWith <emphasis>--pretty</emphasis> format ...\n\t</simpara>\n        <simpara>Cannot be combined with --reverse.</simpara>\n\n        </listitem>\t\n\nor (with):\n\n\t<listitem>\n        <simpara>\n        \tIndented first paragraph...\n\tWith <emphasis>--pretty</emphasis> format ...\n\tCannot be combined with --reverse.\n\t</simpara>\n\n        </listitem>\t\n\nSo it looks as if the only place that needs the ugly '+'\ncontinuation marker is between the first and the second\nparagraph.  And it also appears that the manpage backend does\nnot pay attention to the paragraph break there (HTML backend\nplaces a <br /> before \"With <em>--pretty</em>\").\n\nIs it just me, or the more we look at it, everybody doubts if\nAsciiDoc was such a good choice?\n\nIt was a major plus that the input format is mostly readable as\nstraight text, but this was one of the sore points in our\nformatting.  In the description part of a definition list, we\nindent the first paragraph but append the second paragraph and\nlater with '+' without indenting (we would rather keep the\nsecond and subsequent paragraphs aligned with the first one).\nHowever, it appears that the definition has to be a single\nparagraph and not any longer in such a list anyway.\n\nHmmmm.\n\nIn any case, I'd appreciate feedbacks from people who recently\nreported formatting breakages on this patch.\n"},{"id":"51241","messageId":"86fy2besyi.fsf@lola.quinscape.zz","threadId":"9607","inReplyTo":"7vbqczkhvb.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix break in git-rev-list.txt","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-22T10:58:45Z","receivedAt":"2007-08-22T10:58:45Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> So it looks as if the only place that needs the ugly '+'\n> continuation marker is between the first and the second\n> paragraph.  And it also appears that the manpage backend does\n> not pay attention to the paragraph break there (HTML backend\n> places a <br /> before \"With <em>--pretty</em>\").\n>\n> Is it just me, or the more we look at it, everybody doubts if\n> AsciiDoc was such a good choice?\n\nI don't think you should overgeneralize right now.  Every input format\nwill need some massaging, possibly resulting in ugliness.\n\nAsciiDoc _can_ be converted to plain text without markup.  Whether\nthis is worth doing depends on just how many people actually access\nthe .txt files, and how much they are disturbed by things that are\njust there for leading AsciiDoc on the right path.\n\nOne can also cater for particular patterns in the configuration files\nrather than in the source files.\n\nHowever, there are some things which can't be ironed out: adding\nuseful indexing information will certainly disturb perusing the .txt\nfiles as text.  And I consider good indexing important.\n\nThere also is the problem that AsciiDoc works with a format _chain_\nthat makes it painful to achieve a certain result.\n\nHowever, the resulting quality of this format chain is good: proper\nDocbook output, even proper Texinfo output, well-formatted manual\npages, nice-looking HTML.  In most of those areas, the Texinfo\ntoolchain, in contrast, falls on its face.\n\nIf one does not want to sacrifice quality, it might still make sense\nto cut Asciidoc out of the equation and use Docbook instead.\nMarkup-free .txt-files can presumably generated from Docbook.  I think\nit should also be possible to generate manpages from it, and it\nconverts nicely into Texinfo.\n\nAs long as we have no dedicated Asciidoc wizard working for git, this\nmight make changing the structure of the documentation or adding new\nfeatures much easier.\n\nBut it might frighten people from correcting the straight text of the\ndocumentation.\n\nIt is certainly a multi-edged sword, and without doing an extensive\npoll among those who contribute to documentation, a change in policy\nwould not appear appropriate.\n\nI know that the combined Asciidoc/Docbook challenge has kept me up to\nnow from succeeding in a restructuring that would include the manual\npages in the user manual as an appendix.\n\nI have no doubt from the Docbook and Asciidoc documentation I have\ndigged through that this is possible, and with not too many lines of\ncode, but it is still quite beyond me given the time I can spend on\nit.\n\nThe question is how often Asciidoc will keep people from contributing\nuseful changes, and how often Docbook would.\n\nI have no idea how the numbers would turn out.  I consider it more\nlikely that people will contribute text changes to Asciidoc\ndocumentation, but structural changes are likely quite easier to do\nwith Docbook.\n\n-- \nDavid Kastrup\n"},{"id":"51255","messageId":"46CC4A43.9050305@gmail.com","threadId":"9607","inReplyTo":"7vbqczkhvb.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix break in git-rev-list.txt","fromName":"Quy Tonthat","fromEmail":"qtonthat@gmail.com","sentAt":"2007-08-22T14:37:55Z","receivedAt":"2007-08-22T14:37:55Z","isPatch":true,"sender":{"key":"qtonthat@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> Hmph.  Interesting.  The text around this is:\n> \n> \t-g, --wark-reflogs::\n> \n>         \tIndented first paragraph...\n> \t+\n>         With '\\--pretty' fromat ... second paragraph ...\n> \tprefixed with this information on the same line.\n> \t+\n>         Cannot be combined with --reverse.\n> \n> And its formatted form looks like either (without your patch):\n> \n> \t<listitem>\n>         <simpara>\n>         \tIndented first paragraph...\n> \tWith <emphasis>--pretty</emphasis> format ...\n> \t</simpara>\n>         <simpara>Cannot be combined with --reverse.</simpara>\n> \n>         </listitem>\t\n> \n> or (with):\n> \n> \t<listitem>\n>         <simpara>\n>         \tIndented first paragraph...\n> \tWith <emphasis>--pretty</emphasis> format ...\n> \tCannot be combined with --reverse.\n> \t</simpara>\n> \n>         </listitem>\t\n> \n\nWell, it goes differently on my system here (asciidoc 8.1.0), as shown\nin the diff bellow:\n\n\t--- git-rev-list.xml.bad\t2007-08-23 00:08:58.000000000 +1000\n\t+++ git-rev-list.xml.good\t2007-08-23 00:10:20.000000000 +1000\n\t@@ -509,16 +509,15 @@\n\t         When this option is used you cannot specify commits to\n\t         exclude (that is, <emphasis>&#94;commit</emphasis>, <emphasis>commit1..commit2</emphasis>,\n\t         nor <emphasis>commit1&#8230;commit2</emphasis> notations cannot be used).\n\t-<literal>\n\t With <emphasis>--pretty</emphasis> format other than oneline (for obvious reasons),\n\t this causes the output to have two extra lines of information\n\n\t taken from the reflog.  By default, <emphasis>commit@{Nth}</emphasis> notation is\n\t used in the output.  When the starting commit is specified as\n\n\t instead.  Under <emphasis>--pretty=oneline</emphasis>, the commit message is\n\n\t prefixed with this information on the same line.\n\n\t-</literal>\n\n\t-Cannot be combined with --reverse.\n\n\t </simpara>\n\n\t+<simpara>Cannot be combined with --reverse.</simpara>\n\n\t+\n\n\t </listitem>\n\n\t </varlistentry>\n\n\t <varlistentry>\n\n\nNote the extra <literal></literal> which what xmlto has problems with as\nin its error messages\n\n/work/devel/git/git.git/Documentation/git-rev-list.xml:512: element literal: validity error : Element emphasis is not declared in literal list of possible children\n\nI'll have a look at asciidoc as soon as I have some time.\n\nQuy\n"},{"id":"51261","messageId":"46CC564E.10609@gmail.com","threadId":"9607","inReplyTo":"7vbqczkhvb.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix break in git-rev-list.txt","fromName":"Quy Tonthat","fromEmail":"qtonthat@gmail.com","sentAt":"2007-08-22T15:29:18Z","receivedAt":"2007-08-22T15:29:18Z","isPatch":true,"sender":{"key":"qtonthat@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> It was a major plus that the input format is mostly readable as\n> straight text, but this was one of the sore points in our\n> formatting.  In the description part of a definition list, we\n> indent the first paragraph but append the second paragraph and\n> later with '+' without indenting (we would rather keep the\n> second and subsequent paragraphs aligned with the first one).\n> However, it appears that the definition has to be a single\n> paragraph and not any longer in such a list anyway.\n\nFor your info (not implying what is \"wrong\" or \"right\"), without\nthe second '+' it will generate new paragraph with correct indentation\non my system here.\n\nQuy\n"},{"id":"51268","messageId":"46CC6837.6050005@gmail.com","threadId":"9607","inReplyTo":"7vbqczkhvb.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix break in git-rev-list.txt","fromName":"Quy Tonthat","fromEmail":"qtonthat@gmail.com","sentAt":"2007-08-22T16:45:43Z","receivedAt":"2007-08-22T16:45:43Z","isPatch":true,"sender":{"key":"qtonthat@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> In any case, I'd appreciate feedbacks from people who recently\n> reported formatting breakages on this patch.\n\nI was not aware this problem had been reported/discussed in another\nthread (lack of time lately). I would not have had created this\nthread otherwise. Sorry for making more noise (than necessary)\nand any confusion this may cause.\n\nAnyway, reports/comments will be appreciated.\n\nQuy\n"}]}