{"thread":{"id":"57085","subject":"[PATCH] doc/config: mark ssh allowedSigners example as literal","startedAt":"2021-12-15T16:23:51Z","lastAt":"2021-12-16T09:04:25Z","messageCount":2,"participants":["Jeff King","Fabian Stelzer"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"444149","messageId":"YboWlOG3vZD/7Osx@coredump.intra.peff.net","threadId":"57085","inReplyTo":null,"subject":"[PATCH] doc/config: mark ssh allowedSigners example as literal","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-12-15T16:23:48Z","receivedAt":"2021-12-15T16:23:51Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The discussion for gpg.ssh.allowedSignersFile shows an example string\nthat contains \"user1@example.com,user2@example.com\". Asciidoc thinks\nthese are real email addresses and generates \"mailto\" footnotes for\nthem. This makes the rendered content more confusing, as it has extra\n\"[1]\" markers:\n\n The file consists of one or more lines of principals followed by an\n ssh public key. e.g.: user1@example.com[1],user2@example.com[2]\n ssh-rsa AAAAX1... See ssh-keygen(1) \"ALLOWED SIGNERS\" for details.\n\nand also generates pointless notes at the end of the page:\n\n NOTES\n 1. user1@example.com\n mailto:user1@example.com\n\n 2. user2@example.com\n mailto:user2@example.com\n\nWe can fix this by putting the example into a backtick literal block.\nThat inhibits the mailto generation, and as a bonus typesets the example\ntext in a way that sets it off from the regular prose (a tt font for\nhtml, or bold in the roff manpage).\n\nSigned-off-by: Jeff King \n---\nPossibly this could actually be done in a separate example block, but I\nthink this looks OK and fixes the most obvious problem.\n\n Documentation/config/gpg.txt | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt\nindex 4f30c7dbdd..7875f4fccc 100644\n--- a/Documentation/config/gpg.txt\n+++ b/Documentation/config/gpg.txt\n@@ -44,7 +44,7 @@ gpg.ssh.allowedSignersFile::\n \tA file containing ssh public keys which you are willing to trust.\n \tThe file consists of one or more lines of principals followed by an ssh\n \tpublic key.\n-\te.g.: user1@example.com,user2@example.com ssh-rsa AAAAX1...\n+\te.g.: `user1@example.com,user2@example.com ssh-rsa AAAAX1...`\n \tSee ssh-keygen(1) \"ALLOWED SIGNERS\" for details.\n \tThe principal is only used to identify the key and is available when\n \tverifying a signature.\n-- \n2.34.1.662.g7157fbae24\n"},{"id":"444199","messageId":"20211216090421.ckkuurql5dn2myux@fs","threadId":"57085","inReplyTo":"YboWlOG3vZD/7Osx@coredump.intra.peff.net","subject":"Re: [PATCH] doc/config: mark ssh allowedSigners example as literal","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-12-16T09:04:21Z","receivedAt":"2021-12-16T09:04:25Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 15.12.2021 11:23, Jeff King wrote:\n>The discussion for gpg.ssh.allowedSignersFile shows an example string\n>that contains \"user1@example.com,user2@example.com\". Asciidoc thinks\n>these are real email addresses and generates \"mailto\" footnotes for\n>them. This makes the rendered content more confusing, as it has extra\n>\"[1]\" markers:\n>\n> The file consists of one or more lines of principals followed by an\n> ssh public key. e.g.: user1@example.com[1],user2@example.com[2]\n> ssh-rsa AAAAX1... See ssh-keygen(1) \"ALLOWED SIGNERS\" for details.\n>\n>and also generates pointless notes at the end of the page:\n>\n> NOTES\n> 1. user1@example.com\n> mailto:user1@example.com\n>\n> 2. user2@example.com\n> mailto:user2@example.com\n>\n>We can fix this by putting the example into a backtick literal block.\n>That inhibits the mailto generation, and as a bonus typesets the example\n>text in a way that sets it off from the regular prose (a tt font for\n>html, or bold in the roff manpage).\n>\n>Signed-off-by: Jeff King \n>---\n>Possibly this could actually be done in a separate example block, but I\n>think this looks OK and fixes the most obvious problem.\n>\n> Documentation/config/gpg.txt | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n>diff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt\n>index 4f30c7dbdd..7875f4fccc 100644\n>--- a/Documentation/config/gpg.txt\n>+++ b/Documentation/config/gpg.txt\n>@@ -44,7 +44,7 @@ gpg.ssh.allowedSignersFile::\n> \tA file containing ssh public keys which you are willing to trust.\n> \tThe file consists of one or more lines of principals followed by an ssh\n> \tpublic key.\n>-\te.g.: user1@example.com,user2@example.com ssh-rsa AAAAX1...\n>+\te.g.: `user1@example.com,user2@example.com ssh-rsa AAAAX1...`\n> \tSee ssh-keygen(1) \"ALLOWED SIGNERS\" for details.\n> \tThe principal is only used to identify the key and is available when\n> \tverifying a signature.\n>-- \n\nThanks, this is obviously good. I don't think for this simple example an \nextra block is not needed unless we want to document the other options the \nallowedSigners file has in the git docs as well. I think it's better to \nreference the ssh-keygen manpage though.\n"}]}