{"thread":{"id":"60257","subject":"[PATCH] pretty-formats.txt: fix whitespace","startedAt":"2023-09-22T14:10:29Z","lastAt":"2023-09-26T22:46:01Z","messageCount":10,"participants":["Josh Soref via GitGitGadget","Junio C Hamano","Josh Soref","Kristoffer Haugsbakk","Linus Arver"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"482135","messageId":"pull.950.git.1695391818917.gitgitgadget@gmail.com","threadId":"60257","inReplyTo":null,"subject":"[PATCH] pretty-formats.txt: fix whitespace","fromName":"Josh Soref via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2023-09-22T14:10:18Z","receivedAt":"2023-09-22T14:10:29Z","isPatch":true,"sender":{"key":"jsoref@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2119212?v=4"},"body":"From: Josh Soref \n\n* two spaces after periods for sentences\n* comma (before/)after `i.e.` and `e.g.`\n* comma after `etc.` when not ending a sentence\n* space before `(`\n\nSigned-off-by: Josh Soref \n---\n pretty-formats.txt: fix whitespace\n \n follow-up-to:\n https://github.com/gitgitgadget/git/pull/939#discussion_r624652778\n \n * two spaces after periods for sentences\n * comma (before/)after i.e. and e.g.\n * space before (\n \n Signed-off-by: Josh Soref jsoref@gmail.com\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-950%2Fjsoref%2Fwhitespace-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-950/jsoref/whitespace-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/950\n\n Documentation/pretty-formats.txt | 68 ++++++++++++++++----------------\n 1 file changed, 34 insertions(+), 34 deletions(-)\n\ndiff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt\nindex d38b4ab5666..f64c0a2d92e 100644\n--- a/Documentation/pretty-formats.txt\n+++ b/Documentation/pretty-formats.txt\n@@ -15,7 +15,7 @@ There are several built-in formats, and you can define\n additional formats by setting a pretty.\n config option to either another format name, or a\n 'format:' string, as described below (see\n-linkgit:git-config[1]). Here are the details of the\n+linkgit:git-config[1]). Here are the details of the\n built-in formats:\n \n * 'oneline'\n@@ -96,15 +96,15 @@ stored in the commit object. Notably, the hashes are\n displayed in full, regardless of whether --abbrev or\n --no-abbrev are used, and 'parents' information show the\n true parent commits, without taking grafts or history\n-simplification into account. Note that this format affects the way\n-commits are displayed, but not the way the diff is shown e.g. with\n-`git log --raw`. To get full object names in a raw diff format,\n+simplification into account. Note that this format affects the way\n+commits are displayed, but not the way the diff is shown, e.g., with\n+`git log --raw`. To get full object names in a raw diff format,\n use `--no-abbrev`.\n \n * 'format:'\n +\n The 'format:' format allows you to specify which information\n-you want to show. It works a little bit like printf format,\n+you want to show. It works a little bit like printf format,\n with the notable exception that you get a newline with '%n'\n instead of '\\n'.\n +\n@@ -136,13 +136,13 @@ The placeholders are:\n \t default, colors are shown only when enabled for log output\n \t (by `color.diff`, `color.ui`, or `--color`, and respecting\n \t the `auto` settings of the former if we are going to a\n-\t terminal). `%C(auto,...)` is accepted as a historical\n-\t synonym for the default (e.g., `%C(auto,red)`). Specifying\n+\t terminal). `%C(auto,...)` is accepted as a historical\n+\t synonym for the default (e.g., `%C(auto,red)`). Specifying\n \t `%C(always,...)` will show the colors even when color is\n \t not otherwise enabled (though consider just using\n \t `--color=always` to enable color for the whole output,\n \t including this format and anything else git might color).\n-\t `auto` alone (i.e. `%C(auto)`) will turn on auto coloring\n+\t `auto` alone (i.e., `%C(auto)`) will turn on auto coloring\n \t on the next placeholders until the color is switched\n \t again.\n '%m':: left (`<`), right (`>`) or boundary (`-`) mark\n@@ -177,7 +177,7 @@ The placeholders are:\n \t\t\t spaces\n '%><( )', '%><|( )':: similar to '%<( )', '%<|( )'\n \t\t\t respectively, but padding both sides\n-\t\t\t (i.e. the text is centered)\n+\t\t\t (i.e., the text is centered)\n \n - Placeholders that expand to information extracted from the commit:\n '%H':: commit hash\n@@ -225,9 +225,9 @@ The placeholders are:\n '%d':: ref names, like the --decorate option of linkgit:git-log[1]\n '%D':: ref names without the \" (\", \")\" wrapping.\n '%(decorate[:])'::\n-ref names with custom decorations. The `decorate` string may be followed by a\n-colon and zero or more comma-separated options. Option values may contain\n-literal formatting codes. These must be used for commas (`%x2C`) and closing\n+ref names with custom decorations. The `decorate` string may be followed by a\n+colon and zero or more comma-separated options. Option values may contain\n+literal formatting codes. These must be used for commas (`%x2C`) and closing\n parentheses (`%x29`), due to their role in the option syntax.\n +\n ** 'prefix=': Shown before the list of ref names. Defaults to \"{nbsp}`(`\".\n@@ -235,7 +235,7 @@ parentheses (`%x29`), due to their role in the option syntax.\n ** 'separator=': Shown between ref names. Defaults to \"`,`{nbsp}\".\n ** 'pointer=': Shown between HEAD and the branch it points to, if any.\n \t\t Defaults to \"{nbsp}`->`{nbsp}\".\n-** 'tag=': Shown before tag names. Defaults to \"`tag:`{nbsp}\".\n+** 'tag=': Shown before tag names. Defaults to \"`tag:`{nbsp}\".\n \n +\n For example, to produce decorations with no wrapping\n@@ -277,7 +277,7 @@ endif::git-rev-list[]\n \t\"X\" for a good signature that has expired,\n \t\"Y\" for a good signature made by an expired key,\n \t\"R\" for a good signature made by a revoked key,\n-\t\"E\" if the signature cannot be checked (e.g. missing key)\n+\t\"E\" if the signature cannot be checked (e.g., missing key)\n \tand \"N\" for no signature\n '%GS':: show the name of the signer for a signed commit\n '%GK':: show the key used to sign a signed commit\n@@ -287,7 +287,7 @@ endif::git-rev-list[]\n '%GT':: show the trust level for the key used to sign a signed commit\n '%gD':: reflog selector, e.g., `refs/stash@{1}` or `refs/stash@{2\n \tminutes ago}`; the format follows the rules described for the\n-\t`-g` option. The portion before the `@` is the refname as\n+\t`-g` option. The portion before the `@` is the refname as\n \tgiven on the command line (so `git log -g refs/heads/master`\n \twould yield `refs/heads/master@{0}`).\n '%gd':: shortened reflog selector; same as `%gD`, but the refname\n@@ -302,48 +302,48 @@ endif::git-rev-list[]\n '%gs':: reflog subject\n '%(trailers[:])'::\n display the trailers of the body as interpreted by\n-linkgit:git-interpret-trailers[1]. The `trailers` string may be followed by\n-a colon and zero or more comma-separated options. If any option is provided\n+linkgit:git-interpret-trailers[1]. The `trailers` string may be followed by\n+a colon and zero or more comma-separated options. If any option is provided\n multiple times, the last occurrence wins.\n +\n-** 'key=': only show trailers with specified . Matching is done\n- case-insensitively and trailing colon is optional. If option is\n+** 'key=': only show trailers with specified . Matching is done\n+ case-insensitively and trailing colon is optional. If option is\n given multiple times trailer lines matching any of the keys are\n- shown. This option automatically enables the `only` option so that\n- non-trailer lines in the trailer block are hidden. If that is not\n+ shown. This option automatically enables the `only` option so that\n+ non-trailer lines in the trailer block are hidden. If that is not\n desired it can be disabled with `only=false`. E.g.,\n `%(trailers:key=Reviewed-by)` shows trailer lines with key\n `Reviewed-by`.\n ** 'only[=]': select whether non-trailer lines from the trailer\n block should be included.\n ** 'separator=': specify a separator inserted between trailer\n- lines. When this option is not given each trailer line is\n- terminated with a line feed character. The string may contain\n- the literal formatting codes described above. To use comma as\n+ lines. When this option is not given each trailer line is\n+ terminated with a line feed character. The string may contain\n+ the literal formatting codes described above. To use comma as\n separator one must use `%x2C` as it would otherwise be parsed as\n- next option. E.g., `%(trailers:key=Ticket,separator=%x2C )`\n+ next option. E.g., `%(trailers:key=Ticket,separator=%x2C )`\n shows all trailer lines whose key is \"Ticket\" separated by a comma\n and a space.\n ** 'unfold[=]': make it behave as if interpret-trailer's `--unfold`\n- option was given. E.g.,\n+ option was given. E.g.,\n `%(trailers:only,unfold=true)` unfolds and shows all trailer lines.\n ** 'keyonly[=]': only show the key part of the trailer.\n ** 'valueonly[=]': only show the value part of the trailer.\n ** 'key_value_separator=': specify a separator inserted between\n- trailer lines. When this option is not given each trailer key-value\n- pair is separated by \": \". Otherwise it shares the same semantics\n+ trailer lines. When this option is not given each trailer key-value\n+ pair is separated by \": \". Otherwise it shares the same semantics\n as 'separator=' above.\n \n NOTE: Some placeholders may depend on other options given to the\n-revision traversal engine. For example, the `%g*` reflog options will\n+revision traversal engine. For example, the `%g*` reflog options will\n insert an empty string unless we are traversing reflog entries (e.g., by\n-`git log -g`). The `%d` and `%D` placeholders will use the \"short\"\n+`git log -g`). The `%d` and `%D` placeholders will use the \"short\"\n decoration format if `--decorate` was not already provided on the command\n line.\n \n-The boolean options accept an optional value `[=]`. The values\n-`true`, `false`, `on`, `off` etc. are all accepted. See the \"boolean\"\n-sub-section in \"EXAMPLES\" in linkgit:git-config[1]. If a boolean\n+The boolean options accept an optional value `[=]`. The values\n+`true`, `false`, `on`, `off`, etc., are all accepted. See the \"boolean\"\n+sub-section in \"EXAMPLES\" in linkgit:git-config[1]. If a boolean\n option is given with no value, it's enabled.\n \n If you add a `+` (plus sign) after '%' of a placeholder, a line-feed\n@@ -361,7 +361,7 @@ placeholder expands to a non-empty string.\n * 'tformat:'\n +\n The 'tformat:' format works exactly like 'format:', except that it\n-provides \"terminator\" semantics instead of \"separator\" semantics. In\n+provides \"terminator\" semantics instead of \"separator\" semantics. In\n other words, each commit has the message terminator character (usually a\n newline) appended, rather than a separator placed between entries.\n This means that the final entry of a single-line format will be properly\n\nbase-commit: bda494f4043963b9ec9a1ecd4b19b7d1cd9a0518\n-- \ngitgitgadget\n"},{"id":"482187","messageId":"xmqqsf75zxbv.fsf@gitster.g","threadId":"60257","inReplyTo":"pull.950.git.1695391818917.gitgitgadget@gmail.com","subject":"Re: [PATCH] pretty-formats.txt: fix whitespace","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-09-22T21:56:20Z","receivedAt":"2023-09-22T21:56:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Josh Soref via GitGitGadget\" writes:\n\n> From: Josh Soref \n>\n> * two spaces after periods for sentences\n\nAlthough I admit I tend to hit my spacebar twice after a sentence, I\nthink more people tend to just do with a single space and let the\nformatting software (like AsciiDoc) take care of the inter-sentence\nspacing. To me, this falls into \"it would be nicer if we did this\nwhen we write a new sentence, but it is not worth the patch noise if\nsomebody already wrote with a single space to change them\" category.\n\nThe title of the patch may have been written after you did the\nabove, but now it includes other changes listed below, so it may\nwant to be revised.\n\n> * comma (before/)after `i.e.` and `e.g.`\n\nThat's modern American English. I think our documentation is\nmixture so this may also fall into \"if it is already written that\nway, it is not worth the patch noise to change\" category.\n\n> * comma after `etc.` when not ending a sentence\n\nThere is one instance that says \"A, B, C, D, etc., are all accepted.\"\nwithout the comma after 'etc.' and the patch corrects it. OK.\n\n> * space before `(`\n\nIf you mean by the above that we used to say\n\n\t... as described below(see linkgit:git-config[1]))\n\nand you added a SP before \"(see\", that is a definite improvement. I\nhowever didn't find an example of a line that lacks SP before '('\nthat got corrected to have a SP there.\n\n> Signed-off-by: Josh Soref \n> ---\n\nThanks.\n\n> pretty-formats.txt: fix whitespace\n> \n> follow-up-to:\n> https://github.com/gitgitgadget/git/pull/939#discussion_r624652778\n> \n> * two spaces after periods for sentences\n> * comma (before/)after i.e. and e.g.\n> * space before (\n> \n> Signed-off-by: Josh Soref jsoref@gmail.com\n>\n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-950%2Fjsoref%2Fwhitespace-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-950/jsoref/whitespace-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/950\n>\n> Documentation/pretty-formats.txt | 68 ++++++++++++++++----------------\n> 1 file changed, 34 insertions(+), 34 deletions(-)\n>\n> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt\n> index d38b4ab5666..f64c0a2d92e 100644\n> --- a/Documentation/pretty-formats.txt\n> +++ b/Documentation/pretty-formats.txt\n> @@ -15,7 +15,7 @@ There are several built-in formats, and you can define\n> additional formats by setting a pretty.\n> config option to either another format name, or a\n> 'format:' string, as described below (see\n> -linkgit:git-config[1]). Here are the details of the\n> +linkgit:git-config[1]). Here are the details of the\n> built-in formats:\n> \n> * 'oneline'\n> @@ -96,15 +96,15 @@ stored in the commit object. Notably, the hashes are\n> displayed in full, regardless of whether --abbrev or\n> --no-abbrev are used, and 'parents' information show the\n> true parent commits, without taking grafts or history\n> -simplification into account. Note that this format affects the way\n> -commits are displayed, but not the way the diff is shown e.g. with\n> -`git log --raw`. To get full object names in a raw diff format,\n> +simplification into account. Note that this format affects the way\n> +commits are displayed, but not the way the diff is shown, e.g., with\n> +`git log --raw`. To get full object names in a raw diff format,\n> use `--no-abbrev`.\n> \n> * 'format:'\n> +\n> The 'format:' format allows you to specify which information\n> -you want to show. It works a little bit like printf format,\n> +you want to show. It works a little bit like printf format,\n> with the notable exception that you get a newline with '%n'\n> instead of '\\n'.\n> +\n> @@ -136,13 +136,13 @@ The placeholders are:\n> \t default, colors are shown only when enabled for log output\n> \t (by `color.diff`, `color.ui`, or `--color`, and respecting\n> \t the `auto` settings of the former if we are going to a\n> -\t terminal). `%C(auto,...)` is accepted as a historical\n> -\t synonym for the default (e.g., `%C(auto,red)`). Specifying\n> +\t terminal). `%C(auto,...)` is accepted as a historical\n> +\t synonym for the default (e.g., `%C(auto,red)`). Specifying\n> \t `%C(always,...)` will show the colors even when color is\n> \t not otherwise enabled (though consider just using\n> \t `--color=always` to enable color for the whole output,\n> \t including this format and anything else git might color).\n> -\t `auto` alone (i.e. `%C(auto)`) will turn on auto coloring\n> +\t `auto` alone (i.e., `%C(auto)`) will turn on auto coloring\n> \t on the next placeholders until the color is switched\n> \t again.\n> '%m':: left (`<`), right (`>`) or boundary (`-`) mark\n> @@ -177,7 +177,7 @@ The placeholders are:\n> \t\t\t spaces\n> '%><( )', '%><|( )':: similar to '%<( )', '%<|( )'\n> \t\t\t respectively, but padding both sides\n> -\t\t\t (i.e. the text is centered)\n> +\t\t\t (i.e., the text is centered)\n> \n> - Placeholders that expand to information extracted from the commit:\n> '%H':: commit hash\n> @@ -225,9 +225,9 @@ The placeholders are:\n> '%d':: ref names, like the --decorate option of linkgit:git-log[1]\n> '%D':: ref names without the \" (\", \")\" wrapping.\n> '%(decorate[:])'::\n> -ref names with custom decorations. The `decorate` string may be followed by a\n> -colon and zero or more comma-separated options. Option values may contain\n> -literal formatting codes. These must be used for commas (`%x2C`) and closing\n> +ref names with custom decorations. The `decorate` string may be followed by a\n> +colon and zero or more comma-separated options. Option values may contain\n> +literal formatting codes. These must be used for commas (`%x2C`) and closing\n> parentheses (`%x29`), due to their role in the option syntax.\n> +\n> ** 'prefix=': Shown before the list of ref names. Defaults to \"{nbsp}`(`\".\n> @@ -235,7 +235,7 @@ parentheses (`%x29`), due to their role in the option syntax.\n> ** 'separator=': Shown between ref names. Defaults to \"`,`{nbsp}\".\n> ** 'pointer=': Shown between HEAD and the branch it points to, if any.\n> \t\t Defaults to \"{nbsp}`->`{nbsp}\".\n> -** 'tag=': Shown before tag names. Defaults to \"`tag:`{nbsp}\".\n> +** 'tag=': Shown before tag names. Defaults to \"`tag:`{nbsp}\".\n> \n> +\n> For example, to produce decorations with no wrapping\n> @@ -277,7 +277,7 @@ endif::git-rev-list[]\n> \t\"X\" for a good signature that has expired,\n> \t\"Y\" for a good signature made by an expired key,\n> \t\"R\" for a good signature made by a revoked key,\n> -\t\"E\" if the signature cannot be checked (e.g. missing key)\n> +\t\"E\" if the signature cannot be checked (e.g., missing key)\n> \tand \"N\" for no signature\n> '%GS':: show the name of the signer for a signed commit\n> '%GK':: show the key used to sign a signed commit\n> @@ -287,7 +287,7 @@ endif::git-rev-list[]\n> '%GT':: show the trust level for the key used to sign a signed commit\n> '%gD':: reflog selector, e.g., `refs/stash@{1}` or `refs/stash@{2\n> \tminutes ago}`; the format follows the rules described for the\n> -\t`-g` option. The portion before the `@` is the refname as\n> +\t`-g` option. The portion before the `@` is the refname as\n> \tgiven on the command line (so `git log -g refs/heads/master`\n> \twould yield `refs/heads/master@{0}`).\n> '%gd':: shortened reflog selector; same as `%gD`, but the refname\n> @@ -302,48 +302,48 @@ endif::git-rev-list[]\n> '%gs':: reflog subject\n> '%(trailers[:])'::\n> display the trailers of the body as interpreted by\n> -linkgit:git-interpret-trailers[1]. The `trailers` string may be followed by\n> -a colon and zero or more comma-separated options. If any option is provided\n> +linkgit:git-interpret-trailers[1]. The `trailers` string may be followed by\n> +a colon and zero or more comma-separated options. If any option is provided\n> multiple times, the last occurrence wins.\n> +\n> -** 'key=': only show trailers with specified . Matching is done\n> - case-insensitively and trailing colon is optional. If option is\n> +** 'key=': only show trailers with specified . Matching is done\n> + case-insensitively and trailing colon is optional. If option is\n> given multiple times trailer lines matching any of the keys are\n> - shown. This option automatically enables the `only` option so that\n> - non-trailer lines in the trailer block are hidden. If that is not\n> + shown. This option automatically enables the `only` option so that\n> + non-trailer lines in the trailer block are hidden. If that is not\n> desired it can be disabled with `only=false`. E.g.,\n> `%(trailers:key=Reviewed-by)` shows trailer lines with key\n> `Reviewed-by`.\n> ** 'only[=]': select whether non-trailer lines from the trailer\n> block should be included.\n> ** 'separator=': specify a separator inserted between trailer\n> - lines. When this option is not given each trailer line is\n> - terminated with a line feed character. The string may contain\n> - the literal formatting codes described above. To use comma as\n> + lines. When this option is not given each trailer line is\n> + terminated with a line feed character. The string may contain\n> + the literal formatting codes described above. To use comma as\n> separator one must use `%x2C` as it would otherwise be parsed as\n> - next option. E.g., `%(trailers:key=Ticket,separator=%x2C )`\n> + next option. E.g., `%(trailers:key=Ticket,separator=%x2C )`\n> shows all trailer lines whose key is \"Ticket\" separated by a comma\n> and a space.\n> ** 'unfold[=]': make it behave as if interpret-trailer's `--unfold`\n> - option was given. E.g.,\n> + option was given. E.g.,\n> `%(trailers:only,unfold=true)` unfolds and shows all trailer lines.\n> ** 'keyonly[=]': only show the key part of the trailer.\n> ** 'valueonly[=]': only show the value part of the trailer.\n> ** 'key_value_separator=': specify a separator inserted between\n> - trailer lines. When this option is not given each trailer key-value\n> - pair is separated by \": \". Otherwise it shares the same semantics\n> + trailer lines. When this option is not given each trailer key-value\n> + pair is separated by \": \". Otherwise it shares the same semantics\n> as 'separator=' above.\n> \n> NOTE: Some placeholders may depend on other options given to the\n> -revision traversal engine. For example, the `%g*` reflog options will\n> +revision traversal engine. For example, the `%g*` reflog options will\n> insert an empty string unless we are traversing reflog entries (e.g., by\n> -`git log -g`). The `%d` and `%D` placeholders will use the \"short\"\n> +`git log -g`). The `%d` and `%D` placeholders will use the \"short\"\n> decoration format if `--decorate` was not already provided on the command\n> line.\n> \n> -The boolean options accept an optional value `[=]`. The values\n> -`true`, `false`, `on`, `off` etc. are all accepted. See the \"boolean\"\n> -sub-section in \"EXAMPLES\" in linkgit:git-config[1]. If a boolean\n> +The boolean options accept an optional value `[=]`. The values\n> +`true`, `false`, `on`, `off`, etc., are all accepted. See the \"boolean\"\n> +sub-section in \"EXAMPLES\" in linkgit:git-config[1]. If a boolean\n> option is given with no value, it's enabled.\n> \n> If you add a `+` (plus sign) after '%' of a placeholder, a line-feed\n> @@ -361,7 +361,7 @@ placeholder expands to a non-empty string.\n> * 'tformat:'\n> +\n> The 'tformat:' format works exactly like 'format:', except that it\n> -provides \"terminator\" semantics instead of \"separator\" semantics. In\n> +provides \"terminator\" semantics instead of \"separator\" semantics. In\n> other words, each commit has the message terminator character (usually a\n> newline) appended, rather than a separator placed between entries.\n> This means that the final entry of a single-line format will be properly\n>\n> base-commit: bda494f4043963b9ec9a1ecd4b19b7d1cd9a0518\n"},{"id":"482221","messageId":"CACZqfqCVsv-ZaSRWt_ejMn5f_U_1E2h7wsCgUg_50A+KHzOgkA@mail.gmail.com","threadId":"60257","inReplyTo":"xmqqsf75zxbv.fsf@gitster.g","subject":"Re: [PATCH] pretty-formats.txt: fix whitespace","fromName":"Josh Soref","fromEmail":"jsoref@gmail.com","sentAt":"2023-09-24T10:31:46Z","receivedAt":"2023-09-24T10:32:02Z","isPatch":true,"sender":{"key":"jsoref@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2119212?v=4"},"body":"Junio C Hamano wrote:\n> > * two spaces after periods for sentences\n>\n> Although I admit I tend to hit my spacebar twice after a sentence, I\n> think more people tend to just do with a single space and let the\n> formatting software (like AsciiDoc) take care of the inter-sentence\n> spacing. To me, this falls into \"it would be nicer if we did this\n> when we write a new sentence, but it is not worth the patch noise if\n> somebody already wrote with a single space to change them\" category.\n\n> The title of the patch may have been written after you did the\n> above, but now it includes other changes listed below, so it may\n> want to be revised.\n\nIndeed.\n\nWould it get revised or just abandoned in favor of something else?\n\n> > * comma (before/)after `i.e.` and `e.g.`\n>\n> That's modern American English. I think our documentation is\n> mixture so this may also fall into \"if it is already written that\n> way, it is not worth the patch noise to change\" category.\n>\n> > * comma after `etc.` when not ending a sentence\n>\n> There is one instance that says \"A, B, C, D, etc., are all accepted.\"\n> without the comma after 'etc.' and the patch corrects it. OK.\n\nIt seems like this is the only change that's of interest.\n\nDo I just make a distinct gitgitgadget PR with that change, or do I\nask it to mark that single change as a V2 to this? (given the branch\nname assumed whitespace and the only change would be a comma, it'd be\nkinda wrong...)\n\n> > * space before `(`\n>\n> If you mean by the above that we used to say\n>\n> ... as described below(see linkgit:git-config[1]))\n>\n> and you added a SP before \"(see\", that is a definite improvement. I\n> however didn't find an example of a line that lacks SP before '('\n> that got corrected to have a SP there.\n\nI'm pretty sure that's what I meant, but I can't find the change in my\ngit reflog, and I'm not quite sure how I could have made that mistake.\n"},{"id":"482289","messageId":"xmqqsf72upxk.fsf@gitster.g","threadId":"60257","inReplyTo":"CACZqfqCVsv-ZaSRWt_ejMn5f_U_1E2h7wsCgUg_50A+KHzOgkA@mail.gmail.com","subject":"Re: [PATCH] pretty-formats.txt: fix whitespace","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-09-25T17:24:07Z","receivedAt":"2023-09-25T17:24:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josh Soref writes:\n\n>> > * comma after `etc.` when not ending a sentence\n>>\n>> There is one instance that says \"A, B, C, D, etc., are all accepted.\"\n>> without the comma after 'etc.' and the patch corrects it. OK.\n>\n> It seems like this is the only change that's of interest.\n>\n> Do I just make a distinct gitgitgadget PR with that change, or do I\n> ask it to mark that single change as a V2 to this? (given the branch\n> name assumed whitespace and the only change would be a comma, it'd be\n> kinda wrong...)\n\n;-)\n\nUp to you. If I were doing this patch, I would wait and see if\nothers chime in (to support other changes in v1 that I was on the\nnegative side) and then make v2 with the changes you still believe\nin when that happens.\n\nThanks.\n"},{"id":"482304","messageId":"f3081838-ca50-4a7d-b2fc-6f0f1f1364a8@app.fastmail.com","threadId":"60257","inReplyTo":"pull.950.git.1695391818917.gitgitgadget@gmail.com","subject":"Re: [PATCH] pretty-formats.txt: fix whitespace","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2023-09-25T20:04:50Z","receivedAt":"2023-09-25T20:05:16Z","isPatch":true,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"On Fri, Sep 22, 2023, at 16:10, Josh Soref via GitGitGadget wrote:\n> From: Josh Soref \n>\n> * two spaces after periods for sentences\n\nWhere's the two-spacing convention documented? I didn't find it in\n`CodingGuidelines` or `SubmittingPatches`.\n\nThanks\n\n-- \nKristoffer Haugsbakk\n"},{"id":"482317","messageId":"CACZqfqCfvWASMPMxRpRuAUQPcprcB4RHxxke_qTZ3bFGLf3T8Q@mail.gmail.com","threadId":"60257","inReplyTo":"f3081838-ca50-4a7d-b2fc-6f0f1f1364a8@app.fastmail.com","subject":"Re: [PATCH] pretty-formats.txt: fix whitespace","fromName":"Josh Soref","fromEmail":"jsoref@gmail.com","sentAt":"2023-09-26T02:51:03Z","receivedAt":"2023-09-26T02:51:19Z","isPatch":true,"sender":{"key":"jsoref@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2119212?v=4"},"body":"> From: Josh Soref \n> * two spaces after periods for sentences\n\nKristoffer Haugsbakk wrote:\n> Where's the two-spacing convention documented? I didn't find it in\n> `CodingGuidelines` or `SubmittingPatches`.\n\nThere appeared to be too many instances of two spaces after a period\nin the file to be accidental. In some ways, it was an invitation for\npeople to indicate if they have a preference.\n\nI personally do not have a preference between two spaces after and one\nspace after, but I do have a preference against a mix of two spaces\nafter and one space after.\n\nAs it (IMO) takes effort (admittedly trivial, and quite likely\nhabitual) to insert a second space, I assume that this was a desired\nthing and the one space was the aberration, hence the patch went in\nfavor of two spaces.\n\nI'd just as soon submit a patch the other way (and if people have an\nopinion one way or the other, I'm happy to include a change to\nCodingGuidelines/SubmittingPatches based on people's opinions).\n"},{"id":"482346","messageId":"xmqqo7hoophh.fsf@gitster.g","threadId":"60257","inReplyTo":"CACZqfqCfvWASMPMxRpRuAUQPcprcB4RHxxke_qTZ3bFGLf3T8Q@mail.gmail.com","subject":"Re: [PATCH] pretty-formats.txt: fix whitespace","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-09-26T16:42:34Z","receivedAt":"2023-09-26T16:42:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josh Soref writes:\n\n> As it (IMO) takes effort (admittedly trivial, and quite likely\n> habitual) to insert a second space, I assume that this was a desired\n> thing and the one space was the aberration, hence the patch went in\n> favor of two spaces.\n\nBack in typewriter days, people were taught to leave two spaces\nafter a full stop, because on monospace output it was easier to read\nthat way. Then the desktop publishing software came and people were\nencouraged to leave the appearance up to the software.\n\nSo to old timers who have already been trained to type two spaces\nafter a sentence, it takes more effort not to type the space bar\ntwice.\n\nBut as I said already, I personally feel that the consistency\nguidelines around this area should be:\n\n (1) it would be nice if a new document does not use mixed style, but\n\n (2) it is not worth the patch noise only to \"fix\" them one way or\n the other.\n\nHere \"patch noise\" does not primarily mean the effort a producer of\nsuch a patch spends making sure what they did is correct. The cost\nof making sure unrelated mistakes do not slip into the codebase and\ndocumentation without being noticed is much higher for such a patch\nthat ought to be a mechanical conversion.\n\nThanks.\n"},{"id":"482354","messageId":"owlypm24sr6n.fsf@fine.c.googlers.com","threadId":"60257","inReplyTo":"CACZqfqCVsv-ZaSRWt_ejMn5f_U_1E2h7wsCgUg_50A+KHzOgkA@mail.gmail.com","subject":"Re: [PATCH] pretty-formats.txt: fix whitespace","fromName":"Linus Arver","fromEmail":"linusa@google.com","sentAt":"2023-09-26T18:52:16Z","receivedAt":"2023-09-26T18:52:24Z","isPatch":true,"sender":{"key":"linus@ucla.edu","avatar":null},"body":"Josh Soref writes:\n\n> Junio C Hamano wrote:\n>> > * space before `(`\n>>\n>> If you mean by the above that we used to say\n>>\n>> ... as described below(see linkgit:git-config[1]))\n>>\n>> and you added a SP before \"(see\", that is a definite improvement. I\n>> however didn't find an example of a line that lacks SP before '('\n>> that got corrected to have a SP there.\n>\n> I'm pretty sure that's what I meant, but I can't find the change in my\n> git reflog, and I'm not quite sure how I could have made that mistake.\n\nI too would support this sort of fix (fixing a missing space before\n`(`).\n\nWRT 2-space vs 1-space, I am not sure we need this because this is a\nstylistic issue. Same thing for the commas. I am much more in favor of\nchanges that would actually help users find the information they need\n(e.g., fixing spelling mistakes so that users who type in the correct\nspelling can get the expected documentation hits).\n\nFWIW we already have some guidelines about what is acceptable for doc\npatches in SubmittingPatches:\n\n We currently have a liberal mixture of US and UK English norms for\n spelling and grammar, which is somewhat unfortunate. A huge patch that\n touches the files all over the place only to correct the inconsistency\n is not welcome, though. Potential clashes with other changes that can\n result from such a patch are not worth it. We prefer to gradually\n reconcile the inconsistencies in favor of US English, with small and\n easily digestible patches, as a side effect of doing some other real\n work in the vicinity (e.g. rewriting a paragraph for clarity, while\n turning en_UK spelling to en_US). Obvious typographical fixes are much\n more welcomed (\"teh -> \"the\"), preferably submitted as independent\n patches separate from other documentation changes.\n\nand both the 2-space vs 1-space and comma changes seem to fall into the\n\"not welcome\" category.\n"},{"id":"482355","messageId":"CACZqfqC3HWOuveQdbpVEEO5KOwmnugvUmm6M0WpVu2MtUopm-w@mail.gmail.com","threadId":"60257","inReplyTo":"owlypm24sr6n.fsf@fine.c.googlers.com","subject":"Re: [PATCH] pretty-formats.txt: fix whitespace","fromName":"Josh Soref","fromEmail":"jsoref@gmail.com","sentAt":"2023-09-26T19:51:25Z","receivedAt":"2023-09-26T19:51:41Z","isPatch":true,"sender":{"key":"jsoref@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2119212?v=4"},"body":"Linus Arver wrote:\n> FWIW we already have some guidelines about what is acceptable for doc\n> patches in SubmittingPatches:\n>\n> We currently have a liberal mixture of US and UK English norms for\n> spelling and grammar, which is somewhat unfortunate. A huge patch that\n> touches the files all over the place only to correct the inconsistency\n> is not welcome, though. Potential clashes with other changes that can\n> result from such a patch are not worth it. We prefer to gradually\n> reconcile the inconsistencies in favor of US English, with small and\n> easily digestible patches, as a side effect of doing some other real\n> work in the vicinity (e.g. rewriting a paragraph for clarity, while\n> turning en_UK spelling to en_US). Obvious typographical fixes are much\n> more welcomed (\"teh -> \"the\"), preferably submitted as independent\n> patches separate from other documentation changes.\n>\n> and both the 2-space vs 1-space and comma changes seem to fall into the\n> \"not welcome\" category.\n\nOk, then, I think at this point I'll abandon this PR.\n\nI could probably find the time to justify rewriting one paragraph in\nthis single file to try to abide by the requirements, but it doesn't\nseem worth it. I'm sorry I wasted everyone's time.\n"},{"id":"482357","messageId":"owlymsx8skbp.fsf@fine.c.googlers.com","threadId":"60257","inReplyTo":"CACZqfqC3HWOuveQdbpVEEO5KOwmnugvUmm6M0WpVu2MtUopm-w@mail.gmail.com","subject":"Re: [PATCH] pretty-formats.txt: fix whitespace","fromName":"Linus Arver","fromEmail":"linusa@google.com","sentAt":"2023-09-26T21:20:26Z","receivedAt":"2023-09-26T22:46:01Z","isPatch":true,"sender":{"key":"linus@ucla.edu","avatar":null},"body":"Josh Soref writes:\n\n> Linus Arver wrote:\n>> FWIW we already have some guidelines about what is acceptable for doc\n>> patches in SubmittingPatches:\n>>\n>> We currently have a liberal mixture of US and UK English norms for\n>> spelling and grammar, which is somewhat unfortunate. A huge patch that\n>> touches the files all over the place only to correct the inconsistency\n>> is not welcome, though. Potential clashes with other changes that can\n>> result from such a patch are not worth it. We prefer to gradually\n>> reconcile the inconsistencies in favor of US English, with small and\n>> easily digestible patches, as a side effect of doing some other real\n>> work in the vicinity (e.g. rewriting a paragraph for clarity, while\n>> turning en_UK spelling to en_US). Obvious typographical fixes are much\n>> more welcomed (\"teh -> \"the\"), preferably submitted as independent\n>> patches separate from other documentation changes.\n>>\n>> and both the 2-space vs 1-space and comma changes seem to fall into the\n>> \"not welcome\" category.\n>\n> Ok, then, I think at this point I'll abandon this PR.\n>\n> I could probably find the time to justify rewriting one paragraph in\n> this single file to try to abide by the requirements, but it doesn't\n> seem worth it.\n\nThe change to make a paragraph read better (fixes to awkward wording,\nfor example) are very much appreciated and would be good as a follow-up\npatch in its own right.\n\n> I'm sorry I wasted everyone's time.\n\nPlease don't let this experience deter you from considering future\ncontributions to our documentation. Thanks.\n"}]}