{"thread":{"id":"60932","subject":"[PATCH] documentation: send-email: use camel case consistently","startedAt":"2024-02-16T05:20:05Z","lastAt":"2024-02-21T07:51:08Z","messageCount":10,"participants":["Dragan Simic","Junio C Hamano","Chris Torek"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"488782","messageId":"b0577267402f6177d8ba5646e12d7691437e6e8f.1708060779.git.dsimic@manjaro.org","threadId":"60932","inReplyTo":null,"subject":"[PATCH] documentation: send-email: use camel case consistently","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-16T05:19:56Z","receivedAt":"2024-02-16T05:20:05Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"Correct a few random \"sendemail.*\" configuration parameter names in the\ndocumentation that, for some reason, didn't use camel case format.\n\nThere's only one \"Fixes\" tag, while there should actually be a whole bunch\nof them to cover all the patches that introduced the configuration parameter\nnames fixed by this patch. I think we're fine with just one.\n\nFixes: 0ee42c86cf71 (\"config.txt: move sendemail-config.txt to config/\")\nSigned-off-by: Dragan Simic \n---\n Documentation/config/sendemail.txt | 12 ++++++------\n Documentation/git-send-email.txt | 18 +++++++++---------\n 2 files changed, 15 insertions(+), 15 deletions(-)\n\ndiff --git a/Documentation/config/sendemail.txt b/Documentation/config/sendemail.txt\nindex 7fc770ee9e69..bfdf1a633cae 100644\n--- a/Documentation/config/sendemail.txt\n+++ b/Documentation/config/sendemail.txt\n@@ -8,7 +8,7 @@ sendemail.smtpEncryption::\n \tSee linkgit:git-send-email[1] for description. Note that this\n \tsetting is not subject to the 'identity' mechanism.\n \n-sendemail.smtpsslcertpath::\n+sendemail.smtpSslCertPath::\n \tPath to ca-certificates (either a directory or a single file).\n \tSet it to an empty string to disable certificate verification.\n \n@@ -62,27 +62,27 @@ sendemail.chainReplyTo::\n sendemail.envelopeSender::\n sendemail.from::\n sendemail.headerCmd::\n-sendemail.signedoffbycc::\n+sendemail.signedOffByCc::\n sendemail.smtpPass::\n-sendemail.suppresscc::\n+sendemail.suppressCc::\n sendemail.suppressFrom::\n sendemail.to::\n-sendemail.tocmd::\n+sendemail.toCmd::\n sendemail.smtpDomain::\n sendemail.smtpServer::\n sendemail.smtpServerPort::\n sendemail.smtpServerOption::\n sendemail.smtpUser::\n sendemail.thread::\n sendemail.transferEncoding::\n sendemail.validate::\n sendemail.xmailer::\n \tThese configuration variables all provide a default for\n \tlinkgit:git-send-email[1] command-line options. See its\n \tdocumentation for details.\n \n-sendemail.signedoffcc (deprecated)::\n-\tDeprecated alias for `sendemail.signedoffbycc`.\n+sendemail.signedOffCc (deprecated)::\n+\tDeprecated alias for `sendemail.signedOffByCc`.\n \n sendemail.smtpBatchSize::\n \tNumber of messages to be sent per connection, after that a relogin\ndiff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\nindex d1ef6a204e68..31acfa186457 100644\n--- a/Documentation/git-send-email.txt\n+++ b/Documentation/git-send-email.txt\n@@ -138,7 +138,7 @@ Note that no attempts whatsoever are made to validate the encoding.\n \n --compose-encoding=::\n \tSpecify encoding of compose message. Default is the value of the\n-\t'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed.\n+\t'sendemail.composeEncoding'; if that is unspecified, UTF-8 is assumed.\n \n --transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)::\n \tSpecify the transfer encoding to be used to send the message over SMTP.\n@@ -174,7 +174,7 @@ Sending\n \tSpecify a command to run to send the email. The command should\n \tbe sendmail-like; specifically, it must support the `-i` option.\n \tThe command will be executed in the shell if necessary. Default\n-\tis the value of `sendemail.sendmailcmd`. If unspecified, and if\n+\tis the value of `sendemail.sendmailCmd`. If unspecified, and if\n \t--smtp-server is also unspecified, git-send-email will search\n \tfor `sendmail` in `/usr/sbin`, `/usr/lib` and $PATH.\n \n@@ -269,7 +269,7 @@ must be used for each option.\n \tcertificates concatenated together: see verify(1) -CAfile and\n \t-CApath for more information on these). Set it to an empty string\n \tto disable certificate verification. Defaults to the value of the\n-\t`sendemail.smtpsslcertpath` configuration variable, if set, or the\n+\t`sendemail.smtpSslCertPath` configuration variable, if set, or the\n \tbacking SSL library's compiled-in default otherwise (which should\n \tbe the best choice on most platforms).\n \n@@ -313,7 +313,7 @@ Automating\n \tSpecify a command to execute once per patch file which\n \tshould generate patch file specific \"To:\" entries.\n \tOutput of this command must be single email address per line.\n-\tDefault is the value of 'sendemail.tocmd' configuration value.\n+\tDefault is the value of 'sendemail.toCmd' configuration value.\n \n --cc-cmd=::\n \tSpecify a command to execute once per patch file which\n@@ -348,19 +348,19 @@ Automating\n \n --[no-]signed-off-by-cc::\n \tIf this is set, add emails found in the `Signed-off-by` trailer or Cc: lines to the\n-\tcc list. Default is the value of `sendemail.signedoffbycc` configuration\n+\tcc list. Default is the value of `sendemail.signedOffByCc` configuration\n \tvalue; if that is unspecified, default to --signed-off-by-cc.\n \n --[no-]cc-cover::\n \tIf this is set, emails found in Cc: headers in the first patch of\n \tthe series (typically the cover letter) are added to the cc list\n-\tfor each email set. Default is the value of 'sendemail.cccover'\n+\tfor each email set. Default is the value of 'sendemail.ccCover'\n \tconfiguration value; if that is unspecified, default to --no-cc-cover.\n \n --[no-]to-cover::\n \tIf this is set, emails found in To: headers in the first patch of\n \tthe series (typically the cover letter) are added to the to list\n-\tfor each email set. Default is the value of 'sendemail.tocover'\n+\tfor each email set. Default is the value of 'sendemail.toCover'\n \tconfiguration value; if that is unspecified, default to --no-to-cover.\n \n --suppress-cc=::\n@@ -384,7 +384,7 @@ Automating\n - 'all' will suppress all auto cc values.\n --\n +\n-Default is the value of `sendemail.suppresscc` configuration value; if\n+Default is the value of `sendemail.suppressCc` configuration value; if\n that is unspecified, default to 'self' if --suppress-from is\n specified, as well as 'body' if --no-signed-off-cc is specified.\n \n@@ -471,7 +471,7 @@ Information\n \tInstead of the normal operation, dump the shorthand alias names from\n \tthe configured alias file(s), one per line in alphabetical order. Note\n \tthat this only includes the alias name and not its expanded email addresses.\n-\tSee 'sendemail.aliasesfile' for more information about aliases.\n+\tSee 'sendemail.aliasesFile' for more information about aliases.\n \n \n CONFIGURATION\n"},{"id":"488944","messageId":"xmqqv86kx8h0.fsf@gitster.g","threadId":"60932","inReplyTo":"b0577267402f6177d8ba5646e12d7691437e6e8f.1708060779.git.dsimic@manjaro.org","subject":"Re: [PATCH] documentation: send-email: use camel case consistently","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-02-20T00:52:43Z","receivedAt":"2024-02-20T00:52:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dragan Simic writes:\n\n> Correct a few random \"sendemail.*\" configuration parameter names in the\n> documentation that, for some reason, didn't use camel case format.\n\nThanks.\n\n> There's only one \"Fixes\" tag, while there should actually be a whole bunch\n> of them to cover all the patches that introduced the configuration parameter\n> names fixed by this patch. I think we're fine with just one.\n\nI suspect that we are even better off without any. The only reason\nto have them is if we plan to cherry-pick this patch down to a\nseparate maintenance track that the \"culprit\" was cherry-picked or\nmerged to, but we typically do not do so, and if we want to do so,\nwe'd need a much better coverage.\n\nAnyway, checking the output of\n\n $ git grep -n -e '^[a-z]*\\.[a-z]*[A-Z][A-Z][a-zA-Z]*::' Documentation/config/\n\nand comparing it with the output of\n\n $ git grep -n -e '^[a-z]*\\.[a-z]*[A-Z][a-zA-Z]*::' Documentation/config/\n\nI think we should spell \"SSL\" (which is an acronym) full in capital,\nand possibly do the same for \"CC\", too.\n\nAll the other updates in this patch looked sensible, but I wasn't\nbeing particularly careful, so an extra set or two of eyes are\ncertainly appreciated in case I missed any.\n\nThanks.\n"},{"id":"488961","messageId":"33abb630c1d089e39ff48f04e586b1c0@manjaro.org","threadId":"60932","inReplyTo":"xmqqv86kx8h0.fsf@gitster.g","subject":"Re: [PATCH] documentation: send-email: use camel case consistently","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-20T06:41:29Z","receivedAt":"2024-02-20T06:41:37Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"Hello Junio,\n\nOn 2024-02-20 01:52, Junio C Hamano wrote:\n> Dragan Simic writes:\n>> There's only one \"Fixes\" tag, while there should actually be a whole \n>> bunch\n>> of them to cover all the patches that introduced the configuration \n>> parameter\n>> names fixed by this patch. I think we're fine with just one.\n> \n> I suspect that we are even better off without any. The only reason\n> to have them is if we plan to cherry-pick this patch down to a\n> separate maintenance track that the \"culprit\" was cherry-picked or\n> merged to, but we typically do not do so, and if we want to do so,\n> we'd need a much better coverage.\n\nAgreed, will drop the single \"Fixes\" tag in v2.\n\n> Anyway, checking the output of\n> \n> $ git grep -n -e '^[a-z]*\\.[a-z]*[A-Z][A-Z][a-zA-Z]*::'\n> Documentation/config/\n> \n> and comparing it with the output of\n> \n> $ git grep -n -e '^[a-z]*\\.[a-z]*[A-Z][a-zA-Z]*::' \n> Documentation/config/\n> \n> I think we should spell \"SSL\" (which is an acronym) full in capital,\n> and possibly do the same for \"CC\", too.\n\nAgreed about \"SSL\", which I also though about doing that way initially;\nwill change in v2. There are already instances of \"SSL\" being used,\nsuch as in various http.proxySSL* configuration parameter names.\n\nThough, \"CC\" should remain written as \"Cc\", because it's the way email\nheaders are capitalized, which \"Cc\" refers to.\n"},{"id":"488992","messageId":"xmqqo7cbt8a0.fsf@gitster.g","threadId":"60932","inReplyTo":"33abb630c1d089e39ff48f04e586b1c0@manjaro.org","subject":"Re: [PATCH] documentation: send-email: use camel case consistently","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-02-20T16:22:47Z","receivedAt":"2024-02-20T16:22:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dragan Simic writes:\n\n> Though, \"CC\" should remain written as \"Cc\", because it's the way email\n> headers are capitalized, which \"Cc\" refers to.\n\nE-mail headers are case insensitive, though. See above ;-).\n"},{"id":"488993","messageId":"9d0022ba5666223af94bbf450909b1ba@manjaro.org","threadId":"60932","inReplyTo":"xmqqo7cbt8a0.fsf@gitster.g","subject":"Re: [PATCH] documentation: send-email: use camel case consistently","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-20T16:29:42Z","receivedAt":"2024-02-20T16:29:44Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-20 17:22, Junio C Hamano wrote:\n> Dragan Simic writes:\n> \n>> Though, \"CC\" should remain written as \"Cc\", because it's the way email\n>> headers are capitalized, which \"Cc\" refers to.\n> \n> E-mail headers are case insensitive, though. See above ;-).\n\nI've never ever seen anyone referring to email headers as \"TO\", \"CC\" or\n\"BCC\". It's always referred to as \"To\", \"Cc\" and \"Bcc\".\n\nMoreover, RFC2076 [1] refers to them as \"To\", \"cc\" and \"bcc\". This\nmakes it debatable whether \"Cc\" and \"Bcc\" are formally the right forms\nto use in regular conversations, but also makes it clear they aren't\nto be treated as abbreviations.\n\n[1] https://datatracker.ietf.org/doc/html/rfc2076\n"},{"id":"488994","messageId":"a766ba7eb27f663eee34214714f6076d@manjaro.org","threadId":"60932","inReplyTo":"9d0022ba5666223af94bbf450909b1ba@manjaro.org","subject":"Re: [PATCH] documentation: send-email: use camel case consistently","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-20T16:50:41Z","receivedAt":"2024-02-20T16:50:43Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-20 17:29, Dragan Simic wrote:\n> On 2024-02-20 17:22, Junio C Hamano wrote:\n>> Dragan Simic writes:\n>> \n>>> Though, \"CC\" should remain written as \"Cc\", because it's the way \n>>> email\n>>> headers are capitalized, which \"Cc\" refers to.\n>> \n>> E-mail headers are case insensitive, though. See above ;-).\n> \n> I've never ever seen anyone referring to email headers as \"TO\", \"CC\" or\n> \"BCC\". It's always referred to as \"To\", \"Cc\" and \"Bcc\".\n> \n> Moreover, RFC2076 [1] refers to them as \"To\", \"cc\" and \"bcc\". This\n> makes it debatable whether \"Cc\" and \"Bcc\" are formally the right forms\n> to use in regular conversations, but also makes it clear they aren't\n> to be treated as abbreviations.\n> \n> [1] https://datatracker.ietf.org/doc/html/rfc2076\n\nHere are a few more interesting links:\n\n- https://en.wikipedia.org/wiki/Carbon_copy\n- https://bugzilla.mozilla.org/show_bug.cgi?id=212059\n- https://bugzilla.mozilla.org/show_bug.cgi?id=50826\n\nThus, \"cc\" stems from the old age of literal carbon copies, and \"bcc\" \nwas\nseemingly coined when email took over. Technically, \"CC\" and \"BCC\" (or\n\"cc\" and \"bcc\") _are_ abbreviations, but the slightly incorrect \"Cc\" and\n\"Bcc\" forms simply became widespread and took over.\n\nIf you insist on using \"CC\", I'd be fine with that, but frankly, I think\nthat would actually be confusing to the users.\n"},{"id":"489007","messageId":"xmqq8r3foup4.fsf@gitster.g","threadId":"60932","inReplyTo":"a766ba7eb27f663eee34214714f6076d@manjaro.org","subject":"Re: [PATCH] documentation: send-email: use camel case consistently","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-02-20T18:29:43Z","receivedAt":"2024-02-20T18:29:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dragan Simic writes:\n\n> If you insist on using \"CC\", I'd be fine with that, but frankly, I think\n> that would actually be confusing to the users.\n\nI do not insist; my job is to just reject what is not correct.\n\nIn this particular case, I do not think Cc is outright wrong; it\nis near the borderline, but I do not know which side of that line it\nsits.\n\nI gave you one possible rule to decide what to capitalize (namely,\nacronyms are spelled in all caps and that is how we capitalize\nhttp.proxySSLCert and imap.preformattedHTML) and if we adopt that\nrule, then sendemail.supressCc would be incorrect, simply because\ncarbon-copy should be spelled CC.\n\nYou need to give an alternative criteria that is easy to understand\nfor future developers and follow, and explain your choice in the\nproposed commit log message: \"We spell acronyms in all caps like\nHTML and SSL, but in the case of carbon-copy, we spell it as Cc\nbecause ...\".\n\nYou need to fill that \"...\" is in your proposed log message to\nexplain the choice you made in your patch text. More importantly,\nit is to help future developers so that they can easily follow the\nsame rule to spell the variable names they invented in a way\nconsistent with the rule you followed in this patch.\n\nThanks.\n"},{"id":"489019","messageId":"db01d88aa08d33f366b836170e4eb605@manjaro.org","threadId":"60932","inReplyTo":"xmqq8r3foup4.fsf@gitster.g","subject":"Re: [PATCH] documentation: send-email: use camel case consistently","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-20T19:38:26Z","receivedAt":"2024-02-20T19:38:28Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-20 19:29, Junio C Hamano wrote:\n> Dragan Simic writes:\n> \n>> If you insist on using \"CC\", I'd be fine with that, but frankly, I \n>> think\n>> that would actually be confusing to the users.\n> \n> I do not insist; my job is to just reject what is not correct.\n> \n> In this particular case, I do not think Cc is outright wrong; it\n> is near the borderline, but I do not know which side of that line it\n> sits.\n> \n> I gave you one possible rule to decide what to capitalize (namely,\n> acronyms are spelled in all caps and that is how we capitalize\n> http.proxySSLCert and imap.preformattedHTML) and if we adopt that\n> rule, then sendemail.supressCc would be incorrect, simply because\n> carbon-copy should be spelled CC.\n\nPlease, let me remind you that I already fully agreed with using\n\"SSL\". The same applies to \"HTML\", for example, but \"Cc\" should be\nan exception to that rule, IMHO.\n\n> You need to give an alternative criteria that is easy to understand\n> for future developers and follow, and explain your choice in the\n> proposed commit log message: \"We spell acronyms in all caps like\n> HTML and SSL, but in the case of carbon-copy, we spell it as Cc\n> because ...\".\n> \n> You need to fill that \"...\" is in your proposed log message to\n> explain the choice you made in your patch text. More importantly,\n> it is to help future developers so that they can easily follow the\n> same rule to spell the variable names they invented in a way\n> consistent with the rule you followed in this patch.\n\nAgreed, I'll provide a detailed rationale for using \"Cc\" vs. \"SSL\"\nin the commit description for v3, with a few references.\n"},{"id":"489043","messageId":"CAPx1GvcGhZLqHVz9=ZW-w+ebP64-8FpPSb_ef7ygXzDDTze2bA@mail.gmail.com","threadId":"60932","inReplyTo":"9d0022ba5666223af94bbf450909b1ba@manjaro.org","subject":"Re: [PATCH] documentation: send-email: use camel case consistently","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2024-02-21T00:43:26Z","receivedAt":"2024-02-21T00:43:39Z","isPatch":true,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Tue, Feb 20, 2024 at 8:42 AM Dragan Simic wrote:\n> I've never ever seen anyone referring to email headers as \"TO\", \"CC\" or\n> \"BCC\". It's always referred to as \"To\", \"Cc\" and \"Bcc\".\n\nI used some email system (back in the early 1980s) that did that. It\nfelt weird even then. I can't remember if it was some CSMail (CSNet)\nor MH(Rand Mail Handler) version that did it.\n\n> Thus, \"cc\" stems from the old age of literal carbon copies ...\n\nThat's correct. However:\n\n> and \"bcc\" was seemingly coined when email took over.\n\n\"Blind Carbon Copies\" predated email, but required adding the\nnotation separately, if it was to be added at all. (I'm just old enough\nto remember using carbon copies myself, but not old enough to\nknow what Standard Office Practice was at that time.)\n\nWhether adding a \"bcc\" notation was common I don't know;\nit seems it would be easier to leave it off if you made, say, one\noriginal and a total of 2 copies, one \"blinded\".\n\n(As your Wikipedia link notes, there was a practical limit to how\nmany carbon copies one could make in the first place.)\n\nChris\n"},{"id":"489054","messageId":"d2239d5a88ccf9806cf2873f00adc336@manjaro.org","threadId":"60932","inReplyTo":"CAPx1GvcGhZLqHVz9=ZW-w+ebP64-8FpPSb_ef7ygXzDDTze2bA@mail.gmail.com","subject":"Re: [PATCH] documentation: send-email: use camel case consistently","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-21T07:50:59Z","receivedAt":"2024-02-21T07:51:08Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-21 01:43, Chris Torek wrote:\n> On Tue, Feb 20, 2024 at 8:42 AM Dragan Simic \n> wrote:\n>> I've never ever seen anyone referring to email headers as \"TO\", \"CC\" \n>> or\n>> \"BCC\". It's always referred to as \"To\", \"Cc\" and \"Bcc\".\n> \n> I used some email system (back in the early 1980s) that did that. It\n> felt weird even then. I can't remember if it was some CSMail (CSNet)\n> or MH(Rand Mail Handler) version that did it.\n\nThat's interesting, it shows that different variants were used in the\nvery early days of email. Maybe even the all-lowercase \"cc\" and \"bcc\"\nvariants were used somewhere, at least because RFC2076 (better said,\nthe RFCs that predate it) specifies them.\n\n>> Thus, \"cc\" stems from the old age of literal carbon copies ...\n> \n> That's correct. However:\n> \n>> and \"bcc\" was seemingly coined when email took over.\n> \n> \"Blind Carbon Copies\" predated email, but required adding the\n> notation separately, if it was to be added at all. (I'm just old enough\n> to remember using carbon copies myself, but not old enough to\n> know what Standard Office Practice was at that time.)\n\nThanks for the correction. You're right, I was lazy enough not to\ncheck that blind carbon copies predate the age of email. [1]\n\nI'm also old enough to remember the literal carbon copies, I even made\na few dozens of them myself on a mechanical typewriter. They usually\nleft me with dirty fingertips. :) Though, I'm also not old enough to\nknow what the common office practice was like back then.\n\n> Whether adding a \"bcc\" notation was common I don't know;\n> it seems it would be easier to leave it off if you made, say, one\n> original and a total of 2 copies, one \"blinded\".\n> \n> (As your Wikipedia link notes, there was a practical limit to how\n> many carbon copies one could make in the first place.)\n\nExactly, it was the limitation of mechanical typewriters. Perhaps the\nlimit was around four or five carbon copies.\n\n[1] https://en.wikipedia.org/wiki/Blind_carbon_copy\n"}]}