{"thread":{"id":"46852","subject":"[PATCH] doc: correct command formatting","startedAt":"2017-09-28T14:07:01Z","lastAt":"2017-09-29T04:07:36Z","messageCount":8,"participants":["Adam Dinwoodie","Andreas Heiduk","Jonathan Nieder","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"329107","messageId":"20170928140648.GC9439@dinwoodie.org","threadId":"46852","inReplyTo":null,"subject":"[PATCH] doc: correct command formatting","fromName":"Adam Dinwoodie","fromEmail":"adam@dinwoodie.org","sentAt":"2017-09-28T14:06:48Z","receivedAt":"2017-09-28T14:07:01Z","isPatch":true,"sender":{"key":"adam@dinwoodie.org","avatar":"https://avatars.githubusercontent.com/u/1397507?v=4"},"body":"Leaving spaces around the `-delimeters for commands means asciidoc fails\nto parse them as the start of a literal string. Remove an extraneous\nspace that is causing a literal to not be formatted as such.\n\nSigned-off-by: Adam Dinwoodie \n---\n Documentation/git.txt | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 6e3a6767e..98b9b46b9 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -75,7 +75,7 @@ example the following invocations are equivalent:\n Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets\n `foo.bar` to the boolean true value (just like `[foo]bar` would in a\n config file). Including the equals but with an empty value (like `git -c\n-foo.bar= ...`) sets `foo.bar` to the empty string which ` git config\n+foo.bar= ...`) sets `foo.bar` to the empty string which `git config\n --bool` will convert to `false`.\n \n --exec-path[=]::\n-- \n2.14.1\n\n"},{"id":"329112","messageId":"70decbc2-093c-9f9a-3661-ee6500cec641@gmail.com","threadId":"46852","inReplyTo":"20170928140648.GC9439@dinwoodie.org","subject":"Re: [PATCH] doc: correct command formatting","fromName":"Andreas Heiduk","fromEmail":"asheiduk@gmail.com","sentAt":"2017-09-28T17:18:08Z","receivedAt":"2017-09-28T17:18:15Z","isPatch":true,"sender":{"key":"asheiduk@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9371344?v=4"},"body":"Am 28.09.2017 um 16:06 schrieb Adam Dinwoodie:\n> Leaving spaces around the `-delimeters for commands means asciidoc fails\n> to parse them as the start of a literal string. Remove an extraneous\n> space that is causing a literal to not be formatted as such.\n> \n> Signed-off-by: Adam Dinwoodie \n> ---\n> Documentation/git.txt | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/Documentation/git.txt b/Documentation/git.txt\n> index 6e3a6767e..98b9b46b9 100644\n> --- a/Documentation/git.txt\n> +++ b/Documentation/git.txt\n> @@ -75,7 +75,7 @@ example the following invocations are equivalent:\n> Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets\n> `foo.bar` to the boolean true value (just like `[foo]bar` would in a\n> config file). Including the equals but with an empty value (like `git -c\n> -foo.bar= ...`) sets `foo.bar` to the empty string which ` git config\n> +foo.bar= ...`) sets `foo.bar` to the empty string which `git config\n> --bool` will convert to `false`.\n> \n> --exec-path[=]::\n> \n\n+1, Thanks for spotting.\n\nI did a quick\n\n\tgrep -r \" ` \"\n\nwhich came up with with another relevant place:\n\nDocumentation/git-format-patch.txt:\t`--subject-prefix` option) has ` v` appended to it. E.g.\n\nBut here the space IS relevant but asciidoc does not pick up\nthe formatting. Perhaps that one could read like this:\n\n\n\t`--subject-prefix` option) has `v` appended to it. E.g.\n"},{"id":"329115","messageId":"20170928190304.GA174074@aiede.mtv.corp.google.com","threadId":"46852","inReplyTo":"20170928140648.GC9439@dinwoodie.org","subject":"Re: [PATCH] doc: correct command formatting","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-09-28T19:03:04Z","receivedAt":"2017-09-28T19:04:45Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Adam Dinwoodie wrote:\n\n> Leaving spaces around the `-delimeters for commands means asciidoc fails\n> to parse them as the start of a literal string. Remove an extraneous\n> space that is causing a literal to not be formatted as such.\n>\n> Signed-off-by: Adam Dinwoodie \n> ---\n> Documentation/git.txt | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n\nGood catch.\n\nReviewed-by: Jonathan Nieder \n"},{"id":"329116","messageId":"20170928193412.GB174074@aiede.mtv.corp.google.com","threadId":"46852","inReplyTo":"70decbc2-093c-9f9a-3661-ee6500cec641@gmail.com","subject":"Re: [PATCH] doc: correct command formatting","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-09-28T19:34:12Z","receivedAt":"2017-09-28T19:34:20Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nAndreas Heiduk wrote:\n\n> +1, Thanks for spotting.\n\nThanks for looking it over. Can we add your Reviewed-by? (See [1]\nfor what this means.)\n\n> I did a quick\n>\n> \tgrep -r \" ` \"\n>\n> which came up with with another relevant place:\n>\n> Documentation/git-format-patch.txt:\t`--subject-prefix` option) has ` v` appended to it. E.g.\n>\n> But here the space IS relevant but asciidoc does not pick up\n> the formatting. Perhaps that one could read like this:\n>\n> \t`--subject-prefix` option) has `v` appended to it. E.g.\n\nInteresting. This comes from\n\n commit 4aad08e061df699b49e24c4d34698d734473fb66\n Author: Junio C Hamano \n Date: Wed Jan 2 14:16:07 2013 -0800\n\n format-patch: document and test --reroll-count\n\nIn some output formats, the text with backticks surrounding it is\nshown in a different background color, which makes something like\n`{space}v` tempting (with appropriate definition of {space} in\nthe attributes section of asciidoc.conf). But that feels way too\nsubtle.\n\nHow about something like\n\n\thas a space and `v` appended to it\n\n?\n\nThanks,\nJonathan\n\n[1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux/+/9cd6681cb1169e815c41af0265165dd1b872f228/Documentation/process/submitting-patches.rst#563\n"},{"id":"329131","messageId":"0635cfc6-e5ce-c0eb-d0e4-636fb57fbe4f@gmail.com","threadId":"46852","inReplyTo":"20170928193412.GB174074@aiede.mtv.corp.google.com","subject":"Re: [PATCH] doc: correct command formatting","fromName":"Andreas Heiduk","fromEmail":"asheiduk@gmail.com","sentAt":"2017-09-28T22:28:21Z","receivedAt":"2017-09-28T22:28:30Z","isPatch":true,"sender":{"key":"asheiduk@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9371344?v=4"},"body":"Am 28.09.2017 um 21:34 schrieb Jonathan Nieder:\n> Andreas Heiduk wrote:\n> \n>> +1, Thanks for spotting.\n> \n> Thanks for looking it over. Can we add your Reviewed-by? (See [1]\n> for what this means.)\n\nWell, I'd like to see the following occurrence of the same problem\nsolved in that patch, too. Beyond that - your welcome.\n\n>>\n>> Documentation/git-format-patch.txt:\t`--subject-prefix` option) has ` v` appended to it. E.g.\n>>\n>> But here the space IS relevant but asciidoc does not pick up\n>> the formatting. Perhaps that one could read like this:\n>>\n>> \t`--subject-prefix` option) has `v` appended to it. E.g.\n\n...\n\n> In some output formats, the text with backticks surrounding it is\n> shown in a different background color, which makes something like\n> `{space}v` tempting (with appropriate definition of {space} in\n> the attributes section of asciidoc.conf). But that feels way too\n> subtle.\n> \n> How about something like\n> \n> \thas a space and `v` appended to it\n\nWell, in the original text \"\" is already used as a replacement\nmarker. Therefore \"\" seemed obvious to me as another replacement\nmarker which avoids exactly that problem.\n\n> \n> ?\n> \n> Thanks,\n> Jonathan\n> \n> [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux/+/9cd6681cb1169e815c41af0265165dd1b872f228/Documentation/process/submitting-patches.rst#563\n> \n\n"},{"id":"329137","messageId":"xmqqk20iz2w9.fsf@gitster.mtv.corp.google.com","threadId":"46852","inReplyTo":"20170928193412.GB174074@aiede.mtv.corp.google.com","subject":"Re: [PATCH] doc: correct command formatting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-29T01:53:26Z","receivedAt":"2017-09-29T01:53:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Andreas Heiduk wrote:\n>\n>> +1, Thanks for spotting.\n>\n> Thanks for looking it over. Can we add your Reviewed-by? (See [1]\n> for what this means.)\n\nI would just do \"Acked-by: Andreas\" after seeing such an obvious\nadmission of guilt & appreciation for fixing in the exchange. \n\nWould we rather want to make it more formal like how Linux folks do\nthe Reviewed-by: thing?\n\n\n"},{"id":"329143","messageId":"20170929032653.GA28303@aiede.mtv.corp.google.com","threadId":"46852","inReplyTo":"xmqqk20iz2w9.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] doc: correct command formatting","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-09-29T03:27:29Z","receivedAt":"2017-09-29T03:27:46Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>> Andreas Heiduk wrote:\n\n>>> +1, Thanks for spotting.\n>>\n>> Thanks for looking it over. Can we add your Reviewed-by? (See [1]\n>> for what this means.)\n>\n> I would just do \"Acked-by: Andreas\" after seeing such an obvious\n> admission of guilt & appreciation for fixing in the exchange.\n\nOh! I had missed that context.\n\nYour instinct would have been right (and is born out by Andreas's\nreply to me).\n\nI was just fishing, but in this context there was no reason to fish\nfor more than the Ack that was already there.\n\n> Would we rather want to make it more formal like how Linux folks do\n> the Reviewed-by: thing?\n\nSeparate from this example: yes, I think adopting Linux's Reviewed-by\nconvention would be a good thing. When I see a positive reply to a\npatch, I often wonder whether an ack or a fuller reviewed-by is\nintended, and Linux's way of formalizing that appeals to me.\n\nI'll try sending a patch to add it to SubmittingPatches tomorrow\nmorning (Stefan had also been hinting recently about this being\nsomething worth trying).\n\nThank you,\nJonathan\n"},{"id":"329147","messageId":"xmqqpoaaxi4e.fsf@gitster.mtv.corp.google.com","threadId":"46852","inReplyTo":"20170929032653.GA28303@aiede.mtv.corp.google.com","subject":"Re: [PATCH] doc: correct command formatting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-29T04:07:29Z","receivedAt":"2017-09-29T04:07:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Separate from this example: yes, I think adopting Linux's Reviewed-by\n> convention would be a good thing. When I see a positive reply to a\n> patch, I often wonder whether an ack or a fuller reviewed-by is\n> intended, and Linux's way of formalizing that appeals to me.\n>\n> I'll try sending a patch to add it to SubmittingPatches tomorrow\n> morning (Stefan had also been hinting recently about this being\n> something worth trying).\n\nThanks. \n\nI agree with the goal of educating list participants not to throw\nReviewed-by: without reading the patches too carelessly. As akpm\nonce said in <20121003143200.69a50aad.akpm@linux-foundation.org>,\n\"Looks ok to me from a quick look\" is not a review.\n\n > > No, lib/lzo has no identifiable maintainer. I suggest you proceed as\n > > follows:\n > > \n > > - Post the entire patch series to lkml for review (I'd like a cc please)\n > \n > Already happened, multiple people reviewed and tested.\n\n um, I would not consider \"Looks ok to me from a quick look.\" and \"I\n couldn't tell from the github view, but I assume you follow standard\n coding style.\" to indicate a rigorous code review!\n\n That's the problem with the git presentation: hardly anyone reads the\n patches and there is no patch for a reviewer to reply to.\n\n So please send the patches out for review. One at a time, via email.\n"}]}