{"thread":{"id":"39406","subject":"[PATCH v4] send-email: Add simple email aliases format","startedAt":"2015-05-22T03:40:59Z","lastAt":"2015-05-22T18:49:03Z","messageCount":10,"participants":["Allen Hubbe","Eric Sunshine","Junio C Hamano"],"isPatch":true,"patchVersion":4,"patchTotal":null},"messages":[{"id":"261878","messageId":"9f88da801466c83331d02262855e8bef4164e5eb.1432266004.git.allenbh@gmail.com","threadId":"39406","inReplyTo":null,"subject":"[PATCH v4] send-email: Add simple email aliases format","fromName":"Allen Hubbe","fromEmail":"allenbh@gmail.com","sentAt":"2015-05-22T03:40:59Z","receivedAt":"2015-05-22T03:40:59Z","isPatch":true,"sender":{"key":"allenbh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/812915?v=4"},"body":"This format is more simple than the other alias file formats, so it may\nbe preferred by some users.  The format is as follows.\n\n\t<alias>: <address|alias>[, <address|alias>...]\n\nAliases are specified one per line.  There is no line splitting.\nAnything on a line after and including a `#` symbol is considered a\ncomment, and is ignored.  Blank lines are ignored.\n\nExample of the 'simple' format:\n\n\talice: Alice W Land <awol@example.com>\n\tbob: Robert Bobbyton <bob@example.com>\n\t# this is a comment\n\t   # this is also a comment\n\tchloe: chloe@example.com\n\tabgroup: alice, bob # comment after an alias\n\tbcgrp: bob, chloe, Other <o@example.com>\n\nSigned-off-by: Allen Hubbe <allenbh@gmail.com>\n---\n\nNotes:\n    Note, v3 was sent in error.  This v4 presents changes since v2.\n    \n    This v4 extends the syntax to allow blank lines, and comments.  The test\n    case is extended with comments added to alias file input.\n    \n    The Documentation/git-send-email.txt is updated with a description of\n    the simple format.  A note is added for the other formats, directing\n    readers to check the documentation of the email clients for a\n    description.\n\n Documentation/git-send-email.txt | 24 +++++++++++++++++++++++-\n git-send-email.perl              |  8 +++++++-\n t/t9001-send-email.sh            | 27 +++++++++++++++++++++++++++\n 3 files changed, 57 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\nindex 804554609def..38ade31e0c28 100644\n--- a/Documentation/git-send-email.txt\n+++ b/Documentation/git-send-email.txt\n@@ -383,7 +383,29 @@ sendemail.aliasesFile::\n \n sendemail.aliasFileType::\n \tFormat of the file(s) specified in sendemail.aliasesFile. Must be\n-\tone of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.\n+\tone of 'simple', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.\n++\n+If the format is 'simple', then the alias file format is described below.\n+Descriptions of the other file formats to the following formats can be found in\n+the documentation of the email program of the same name.\n++\n+This 'simple' format is is as follows.\n++\n+\t<alias>: <address|alias>[, <address|alias>...]\n++\n+Aliases are specified one per line.  There is no line splitting.  Anything on a\n+line after and including a `#` symbol is considered a comment, and is ignored.\n+Blank lines are ignored.\n++\n+Example of the 'simple' format:\n++\n+\talice: Alice W Land <awol@example.com>\n+\tbob: Robert Bobbyton <bob@example.com>\n+\t# this is a comment\n+\t   # this is also a comment\n+\tchloe: chloe@example.com\n+\tabgroup: alice, bob # comment after an alias\n+\tbcgrp: bob, chloe, Other <o@example.com>\n \n sendemail.multiEdit::\n \tIf true (default), a single editor instance will be spawned to edit\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex e1e9b1460ced..716c2bc9479a 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -515,7 +515,13 @@ my %parse_alias = (\n \t\t\t       $aliases{$alias} = [ split_addrs($addr) ];\n \t\t\t  }\n \t\t      } },\n-\n+\tsimple => sub { my $fh = shift; while (<$fh>) {\n+\t\ts/#.*$//;\n+\t\tnext if /^\\s*$/;\n+\t\tif (/^\\s*(\\S+)\\s*:\\s*(.+)$/) {\n+\t\t\tmy ($alias, $addr) = ($1, $2);\n+\t\t\t$aliases{$alias} = [ split_addrs($addr) ];\n+\t\t}}},\n \tgnus => sub { my $fh = shift; while (<$fh>) {\n \t\tif (/\\(define-mail-alias\\s+\"(\\S+?)\"\\s+\"(\\S+?)\"\\)/) {\n \t\t\t$aliases{$1} = [ $2 ];\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex 7be14a4e37f7..12c1a0c76f1d 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -1549,6 +1549,33 @@ test_expect_success $PREREQ 'sendemail.aliasfile=~/.mailrc' '\n \tgrep \"^!someone@example\\.org!$\" commandline1\n '\n \n+test_expect_success $PREREQ 'sendemail.aliasfiletype=simple' '\n+\tclean_fake_sendmail && rm -fr outdir &&\n+\tgit format-patch -1 -o outdir &&\n+\t{\n+\t\techo \"alice: Alice W Land <awol@example.com>\"\n+\t\techo \"bob: Robert Bobbyton <bob@example.com>\"\n+\t\techo \"# this is a comment\"\n+\t\techo \"   # this is also a comment\"\n+\t\techo \"chloe: chloe@example.com\"\n+\t\techo \"abgroup: alice, bob # comment after an alias\"\n+\t\techo \"bcgrp: bob, chloe, Other <o@example.com>\"\n+\t} >~/.tmp-email-aliases &&\n+\tgit config --replace-all sendemail.aliasesfile \\\n+\t\t\"$(pwd)/.tmp-email-aliases\" &&\n+\tgit config sendemail.aliasfiletype simple &&\n+\tgit send-email \\\n+\t\t--from=\"Example <nobody@example.com>\" \\\n+\t\t--to=alice --to=bcgrp \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\toutdir/0001-*.patch \\\n+\t\t2>errors >out &&\n+\tgrep \"^!awol@example\\.com!$\" commandline1 &&\n+\tgrep \"^!bob@example\\.com!$\" commandline1 &&\n+\tgrep \"^!chloe@example\\.com!$\" commandline1 &&\n+\tgrep \"^!o@example\\.com!$\" commandline1\n+'\n+\n do_xmailer_test () {\n \texpected=$1 params=$2 &&\n \tgit format-patch -1 &&\n-- \n2.3.4\n"},{"id":"261880","messageId":"CAPig+cRLxk26p7DFaS+gRkKZxkRwf8g=4=j2QHX6AC2Uk5J++w@mail.gmail.com","threadId":"39406","inReplyTo":"9f88da801466c83331d02262855e8bef4164e5eb.1432266004.git.allenbh@gmail.com","subject":"Re: [PATCH v4] send-email: Add simple email aliases format","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-05-22T04:29:53Z","receivedAt":"2015-05-22T04:29:53Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe <allenbh@gmail.com> wrote:\n> This format is more simple than the other alias file formats, so it may\n> be preferred by some users. [...]\n> Signed-off-by: Allen Hubbe <allenbh@gmail.com>\n> ---\n> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\n> index 804554609def..38ade31e0c28 100644\n> --- a/Documentation/git-send-email.txt\n> +++ b/Documentation/git-send-email.txt\n> @@ -383,7 +383,29 @@ sendemail.aliasesFile::\n>\n>  sendemail.aliasFileType::\n>         Format of the file(s) specified in sendemail.aliasesFile. Must be\n> -       one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.\n> +       one of 'simple', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.\n> ++\n> +If the format is 'simple', then the alias file format is described below.\n> +Descriptions of the other file formats to the following formats can be found in\n> +the documentation of the email program of the same name.\n\nThe second sentence probably needs some proof-reading.\n\n> ++\n> +This 'simple' format is is as follows.\n> ++\n> +       <alias>: <address|alias>[, <address|alias>...]\n> ++\n> +Aliases are specified one per line.  There is no line splitting.  Anything on a\n> +line after and including a `#` symbol is considered a comment, and is ignored.\n> +Blank lines are ignored.\n\nI'm not convinced that gratuitously diverging from the\nsendmail/postfix 'aliases' format is warranted. In particular, that\nformat recognizes a comment line only when '#' is the first\nnon-whitespace character[1]; and does not consider '#' a\ncomment-introducer anywhere else in the line. By recognizing '#'\nanywhere as a comment-introducer, you may be painting this format into\na corner rather than leaving it open for someone later to extend it to\nbe more sendmail/postfix-like by, for instance, supporting name\nquoting and line-continuation[1].\n\nFor the same reason, I'm not convinced that \"simple\" is a good name.\n\"sendmail\" may indeed be a more appropriate name, even if it means\nthat this early implementation documents it as (currently) a subset of\nthe richer sendmail/postfix 'aliases' format. By doing so, we leave\nthe door open so a future person can implement additional features to\nbring it closer to that format.\n\n[1]: http://www.postfix.org/aliases.5.html\n\n> ++\n> +Example of the 'simple' format:\n> ++\n> +       alice: Alice W Land <awol@example.com>\n> +       bob: Robert Bobbyton <bob@example.com>\n> +       # this is a comment\n> +          # this is also a comment\n> +       chloe: chloe@example.com\n> +       abgroup: alice, bob # comment after an alias\n> +       bcgrp: bob, chloe, Other <o@example.com>\n"},{"id":"261895","messageId":"CAJ80satbXXBYva9qrgR1oA_f7LAHUeAm21=R-mGsWx+sDoQ9sQ@mail.gmail.com","threadId":"39406","inReplyTo":"CAPig+cRLxk26p7DFaS+gRkKZxkRwf8g=4=j2QHX6AC2Uk5J++w@mail.gmail.com","subject":"Re: [PATCH v4] send-email: Add simple email aliases format","fromName":"Allen Hubbe","fromEmail":"allenbh@gmail.com","sentAt":"2015-05-22T12:12:39Z","receivedAt":"2015-05-22T12:12:39Z","isPatch":true,"sender":{"key":"allenbh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/812915?v=4"},"body":"On Fri, May 22, 2015 at 12:29 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:\n> On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe <allenbh@gmail.com> wrote:\n>> This format is more simple than the other alias file formats, so it may\n>> be preferred by some users. [...]\n>> Signed-off-by: Allen Hubbe <allenbh@gmail.com>\n>> ---\n>> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\n>> index 804554609def..38ade31e0c28 100644\n>> --- a/Documentation/git-send-email.txt\n>> +++ b/Documentation/git-send-email.txt\n>> @@ -383,7 +383,29 @@ sendemail.aliasesFile::\n>>\n>>  sendemail.aliasFileType::\n>>         Format of the file(s) specified in sendemail.aliasesFile. Must be\n>> -       one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.\n>> +       one of 'simple', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.\n>> ++\n>> +If the format is 'simple', then the alias file format is described below.\n>> +Descriptions of the other file formats to the following formats can be found in\n>> +the documentation of the email program of the same name.\n>\n> The second sentence probably needs some proof-reading.\n\nCould you be more specific?\n\n>\n>> ++\n>> +This 'simple' format is is as follows.\n>> ++\n>> +       <alias>: <address|alias>[, <address|alias>...]\n>> ++\n>> +Aliases are specified one per line.  There is no line splitting.  Anything on a\n>> +line after and including a `#` symbol is considered a comment, and is ignored.\n>> +Blank lines are ignored.\n>\n> I'm not convinced that gratuitously diverging from the\n> sendmail/postfix 'aliases' format is warranted. In particular, that\n\nThis isn't 'sendmail', as of v2.\n\n> format recognizes a comment line only when '#' is the first\n> non-whitespace character[1]; and does not consider '#' a\n> comment-introducer anywhere else in the line. By recognizing '#'\n> anywhere as a comment-introducer, you may be painting this format into\n> a corner rather than leaving it open for someone later to extend it to\n> be more sendmail/postfix-like by, for instance, supporting name\n> quoting and line-continuation[1].\n\nIt depends what we want to do with this parser: accept existing\nsendmail aliases files in git, or enforce that git alias files are\nusable for sendmail.  I really don't expect the second to ever happen.\nThe first, maybe, but only if the alias file is edited to remove\naliases of pipes and maildirs etc.  The second may not work if we have\ncomments to the right, or aliases of aliases, which sendmail does not\nclaim to support.\n\nI don't know what sendmail would actually do with a '#' elsewhere.  It\nonly talks about having '#' at the beginning of a line, or in the\nalias name in quotes (which is not supported by this parser - proper\nhandling of quoted strings is not easy).  It doesn't say what sendmail\ndoes with '#' if the name is not quoted, and it doesn't define a\nmeaning for '#' in the definition of an alias.  If these other cases\nwould be errors for sendmail, so what if they are not errors here?\n\n>\n> For the same reason, I'm not convinced that \"simple\" is a good name.\n\nI was worried about that back in v1 before going to v2, but I really\ndon't have a strong opinion about the name.  I already changed the\nname, at the suggestion of Junio. I'd like to hear a consensus from\nyou two, or a tiebreaker from a third, before I change it again.\n\n> \"sendmail\" may indeed be a more appropriate name, even if it means\n> that this early implementation documents it as (currently) a subset of\n> the richer sendmail/postfix 'aliases' format. By doing so, we leave\n> the door open so a future person can implement additional features to\n> bring it closer to that format.\n\nOr, a future person can write a sendmail parser that is closer to that format.\n\n>\n> [1]: http://www.postfix.org/aliases.5.html\n>\n>> ++\n>> +Example of the 'simple' format:\n>> ++\n>> +       alice: Alice W Land <awol@example.com>\n>> +       bob: Robert Bobbyton <bob@example.com>\n>> +       # this is a comment\n>> +          # this is also a comment\n>> +       chloe: chloe@example.com\n>> +       abgroup: alice, bob # comment after an alias\n>> +       bcgrp: bob, chloe, Other <o@example.com>\n"},{"id":"261915","messageId":"xmqqlhggfz97.fsf@gitster.dls.corp.google.com","threadId":"39406","inReplyTo":"CAJ80satbXXBYva9qrgR1oA_f7LAHUeAm21=R-mGsWx+sDoQ9sQ@mail.gmail.com","subject":"Re: [PATCH v4] send-email: Add simple email aliases format","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-22T14:44:20Z","receivedAt":"2015-05-22T14:44:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Allen Hubbe <allenbh@gmail.com> writes:\n\n> It depends what we want to do with this parser: accept existing\n> sendmail aliases files in git, or enforce that git alias files are\n> usable for sendmail.  I really don't expect the second to ever happen.\n> The first, maybe, but only if the alias file is edited to remove\n> aliases of pipes and maildirs etc.  The second may not work if we have\n> comments to the right, or aliases of aliases, which sendmail does not\n> claim to support.\n\nLet me step back a bit.  Earlier you said your aim is not to use an\nalias file you already have and use with the MUA/MTA, but to have a\ncollection of aliases to use with git-send-email only.  Is there a\nreason to add support for a new format (whether it is compatible to\nor subset of postfix/sendmail format, or a totally new one) for that\ngoal?  What makes the existing formats unsuitable?\n"},{"id":"261918","messageId":"CAJ80sateODWDUvkAf9YbMMSYv_-=nKnBopGjgDFFSkVHuQJJMQ@mail.gmail.com","threadId":"39406","inReplyTo":"xmqqlhggfz97.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH v4] send-email: Add simple email aliases format","fromName":"Allen Hubbe","fromEmail":"allenbh@gmail.com","sentAt":"2015-05-22T15:39:39Z","receivedAt":"2015-05-22T15:39:39Z","isPatch":true,"sender":{"key":"allenbh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/812915?v=4"},"body":"On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Allen Hubbe <allenbh@gmail.com> writes:\n>\n>> It depends what we want to do with this parser: accept existing\n>> sendmail aliases files in git, or enforce that git alias files are\n>> usable for sendmail.  I really don't expect the second to ever happen.\n>> The first, maybe, but only if the alias file is edited to remove\n>> aliases of pipes and maildirs etc.  The second may not work if we have\n>> comments to the right, or aliases of aliases, which sendmail does not\n>> claim to support.\n>\n> Let me step back a bit.  Earlier you said your aim is not to use an\n> alias file you already have and use with the MUA/MTA, but to have a\n> collection of aliases to use with git-send-email only.  Is there a\n> reason to add support for a new format (whether it is compatible to\n> or subset of postfix/sendmail format, or a totally new one) for that\n> goal?  What makes the existing formats unsuitable?\n>\n\nIt's just a matter of personal preference what is suitable or not, for\nme, in my environment, etc.  Is there a reason I should use the alias\nformat of some email client, if I don't use that email client?\n\nI'm not trying to force anything on anyone else by offering this, just\nanother option that might be suitable for someone else, in their\nenvironment, as it is in mine.  People who don't like it can choose a\ndifferent option.  People who don't like any of the options can write\ntheir own like I did, or is that not allowed for some reason?\n\nI've already shown that I am willing to change the name, write the\ndocumentation, write the tests, modify the syntax, and so on.  I've\ndone the work, from +6 lines to +57 lines, as requested.  I'm not\nlooking forward to v5, v6... v10 of what was a really really simple\npatch.  If you don't like it, please don't string me along.  This is\nnot my job.  If you think the patch is generally ok, but could be\nimproved to be accepted, then let's together try to make v5 the last.\n"},{"id":"261925","messageId":"CAPig+cTsygj1g=8sQ2b=1WYsmgAVyZmHCTW=NKTGuNyQwm3VFA@mail.gmail.com","threadId":"39406","inReplyTo":"CAJ80satbXXBYva9qrgR1oA_f7LAHUeAm21=R-mGsWx+sDoQ9sQ@mail.gmail.com","subject":"Re: [PATCH v4] send-email: Add simple email aliases format","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-05-22T16:53:03Z","receivedAt":"2015-05-22T16:53:03Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, May 22, 2015 at 8:12 AM, Allen Hubbe <allenbh@gmail.com> wrote:\n> On Fri, May 22, 2015 at 12:29 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:\n>> On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe <allenbh@gmail.com> wrote:\n>>> +If the format is 'simple', then the alias file format is described below.\n>>> +Descriptions of the other file formats to the following formats can be found in\n>>> +the documentation of the email program of the same name.\n>>\n>> The second sentence probably needs some proof-reading.\n>\n> Could you be more specific?\n\nUnable to parse \"of the other file formats to the following formats\".\nI'm guessing that the \"to the following formats\" portion doesn't\nbelong.\n\n> It depends what we want to do with this parser: accept existing\n> sendmail aliases files in git, or enforce that git alias files are\n> usable for sendmail.\n\nAside from these possibilities (likely or unlikely), there is also the\nissue of breaking expectations. Precedence for this style 'aliases'\nformat was set decades ago by sendmail. People are familiar with it\nand understand its strengths and weaknesses. Even if documented as not\nbeing sendmail-compatible, because it's so similar to sendmail\n'aliases', people will expect it to work the same way, thus unless\nthere's a good reason to diverge from that standard format, it makes\nsense to be compatible with it (even if only as a proper subset).\n\n> I really don't expect the second to ever happen.\n> The first, maybe, but only if the alias file is edited to remove\n> aliases of pipes and maildirs etc.  The second may not work if we have\n> comments to the right, or aliases of aliases, which sendmail does not\n> claim to support.\n\nIt's not clear why you say that sendmail does not claim to support\naliases of aliases. Although it's true that some sources, such as [1],\nfail to mention support explicitly, other more authoritative sources\ndo[2]. Moreover, the 1993 \"sendmail\" book by Bryan Costales, with\ncontributions from Eric Allman (the creator of sendmail), talks\nexplicitly about expansion of aliases on the right-hand-side. Finally,\nsince time immemorial (at least the early 1980's), every /etc/aliases\nfile has contained the following mandatory entries:\n\n    postmaster: root\n    MAILER-DAEMON: postmaster\n\nwhich indicates clearly that alias expansion on the RHS is supported.\n\n[1]: http://www.feep.net/sendmail/tutorial/intro/aliases.html\n[2]: https://www.freebsd.org/cgi/man.cgi?query=aliases&sektion=5\n\n> I don't know what sendmail would actually do with a '#' elsewhere.  It\n> only talks about having '#' at the beginning of a line, or in the\n> alias name in quotes (which is not supported by this parser - proper\n> handling of quoted strings is not easy).  It doesn't say what sendmail\n> does with '#' if the name is not quoted, and it doesn't define a\n> meaning for '#' in the definition of an alias.  If these other cases\n> would be errors for sendmail, so what if they are not errors here?\n\nAll the more reason to stick with the documented standard. When you\ndiverge from it, you paint the format into a corner, thus closing the\ndoor on someone who wants to bring it more in line with the standard.\n\n>> For the same reason, I'm not convinced that \"simple\" is a good name.\n>> \"sendmail\" may indeed be a more appropriate name, even if it means\n>> that this early implementation documents it as (currently) a subset of\n>> the richer sendmail/postfix 'aliases' format. By doing so, we leave\n>> the door open so a future person can implement additional features to\n>> bring it closer to that format.\n>\n> Or, a future person can write a sendmail parser that is closer to that format.\n\nYes, but git maintainers must continue to support your \"simple\" format\neven if someone comes along later and adds a more proper sendmail-like\nformat alongside. That's why these questions and observations are\nbeing raised now: not to string you along and not because your\nproposal is necessarily undesirable, but because once such support\nlands in git, then it remains indefinitely and must be supported for\nthe life of the project. Long-term project health is important, which\nis why it's desirable to consider these issues early, and to avoid\npainting ourselves into a corner.\n"},{"id":"261930","messageId":"xmqqzj4wedlo.fsf@gitster.dls.corp.google.com","threadId":"39406","inReplyTo":"CAJ80sateODWDUvkAf9YbMMSYv_-=nKnBopGjgDFFSkVHuQJJMQ@mail.gmail.com","subject":"Re: [PATCH v4] send-email: Add simple email aliases format","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-22T17:17:23Z","receivedAt":"2015-05-22T17:17:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Allen Hubbe <allenbh@gmail.com> writes:\n\n> On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n>> Let me step back a bit.  Earlier you said your aim is not to use an\n>> alias file you already have and use with the MUA/MTA, but to have a\n>> collection of aliases to use with git-send-email only.  Is there a\n>> reason to add support for a new format (whether it is compatible to\n>> or subset of postfix/sendmail format, or a totally new one) for that\n>> goal?  What makes the existing formats unsuitable?\n>\n> It's just a matter of personal preference what is suitable or not, for\n> me, in my environment, etc.  Is there a reason I should use the alias\n> format of some email client, if I don't use that email client?\n\nI do not think \"should\" is a good word in the context of that\nsentence, as nobody is forcing you to choose one of the existing\nformats.  But one reason you might want to do so would be because\ngit-send-email already knows about it.\n\nIt is a different matter if you already use an email client that\nsupports your new format and you are trying to reuse an alias file\nwith that email client.  But I got an impression that was not the\ncase, so the choice seemed to me between\n\n - learning and using one of existing 5; and\n\n - inventing, adding support for, and using a new one.\n\nThat felt to me was a choice that is clearly not in favor of the\nlatter, and I was wondering if there were other reasons to shift the\nbalance.  For example, \"all of the existing formats are klunky and\ndifficult to write\" might be why \"learning and using one of existing\n5\" is not a win, compared to \"inventing, ading support for, and\nusing a new one\".  I do not know if that is the case, so I wanted to\nhear the reason why.\n\n> I'm not trying to force anything on anyone else by offering this, just\n> another option that might be suitable for someone else, in their\n> environment, as it is in mine.  People who don't like it can choose a\n> different option.  People who don't like any of the options can write\n> their own like I did, or is that not allowed for some reason?\n\nWe prefer not to carry dead code---when we add things, we would want\nto make sure it will be widely useful so that other people benefit.\n\n> I've already shown that I am willing to change the name, write the\n> documentation, write the tests, modify the syntax, and so on.  I've\n> done the work, from +6 lines to +57 lines, as requested.  I'm not\n> looking forward to v5, v6... v10 of what was a really really simple\n> patch.  If you don't like it, please don't string me along.  This is\n> not my job.\n\nYeah, I know.\n\nA trade off from contributor's side is between (1) handing the\nmaintenance to the upstream, so that a feature will stay available\nwith minimum fuss in the future, or (2) having to carry one's own\nenhancement forward every time one updates from the upstream.\n\nOn the other hand, a trade off from project's side is between (1)\nrejecting a half-way finished ware and hurting feelings of people\nand (2) accepting a half-way finished ware and having to spend\nengineering effort (e.g. making sure it fits to the rest of the\nsystem without adding dead weight) to polish it to the end.\n"},{"id":"261935","messageId":"CAJ80savzM_BL2oPiyTaPYAgnNL7F571aumGJLLw76vtryTacrg@mail.gmail.com","threadId":"39406","inReplyTo":"CAPig+cTsygj1g=8sQ2b=1WYsmgAVyZmHCTW=NKTGuNyQwm3VFA@mail.gmail.com","subject":"Re: [PATCH v4] send-email: Add simple email aliases format","fromName":"Allen Hubbe","fromEmail":"allenbh@gmail.com","sentAt":"2015-05-22T18:01:32Z","receivedAt":"2015-05-22T18:01:32Z","isPatch":true,"sender":{"key":"allenbh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/812915?v=4"},"body":"On Fri, May 22, 2015 at 12:53 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:\n> On Fri, May 22, 2015 at 8:12 AM, Allen Hubbe <allenbh@gmail.com> wrote:\n>> On Fri, May 22, 2015 at 12:29 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:\n>>> On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe <allenbh@gmail.com> wrote:\n>>>> +If the format is 'simple', then the alias file format is described below.\n>>>> +Descriptions of the other file formats to the following formats can be found in\n>>>> +the documentation of the email program of the same name.\n>>>\n>>> The second sentence probably needs some proof-reading.\n>>\n>> Could you be more specific?\n>\n> Unable to parse \"of the other file formats to the following formats\".\n> I'm guessing that the \"to the following formats\" portion doesn't\n> belong.\n\nThanks.  It's obvious now that it's pointed out.  It's hard to\nproofread one's own writing.\n\n>\n>> It depends what we want to do with this parser: accept existing\n>> sendmail aliases files in git, or enforce that git alias files are\n>> usable for sendmail.\n>\n> Aside from these possibilities (likely or unlikely), there is also the\n> issue of breaking expectations. Precedence for this style 'aliases'\n> format was set decades ago by sendmail. People are familiar with it\n> and understand its strengths and weaknesses. Even if documented as not\n> being sendmail-compatible, because it's so similar to sendmail\n> 'aliases', people will expect it to work the same way, thus unless\n> there's a good reason to diverge from that standard format, it makes\n> sense to be compatible with it (even if only as a proper subset).\n>\n>> I really don't expect the second to ever happen.\n>> The first, maybe, but only if the alias file is edited to remove\n>> aliases of pipes and maildirs etc.  The second may not work if we have\n>> comments to the right, or aliases of aliases, which sendmail does not\n>> claim to support.\n>\n> It's not clear why you say that sendmail does not claim to support\n> aliases of aliases. Although it's true that some sources, such as [1],\n> fail to mention support explicitly,\n\nThat's why I said it.\n\n> other more authoritative sources\n> do[2]. Moreover, the 1993 \"sendmail\" book by Bryan Costales, with\n> contributions from Eric Allman (the creator of sendmail), talks\n> explicitly about expansion of aliases on the right-hand-side. Finally,\n> since time immemorial (at least the early 1980's), every /etc/aliases\n> file has contained the following mandatory entries:\n>\n>     postmaster: root\n>     MAILER-DAEMON: postmaster\n>\n> which indicates clearly that alias expansion on the RHS is supported.\n\nOk, no harm then if aliases are supported.\n\n>\n> [1]: http://www.feep.net/sendmail/tutorial/intro/aliases.html\n> [2]: https://www.freebsd.org/cgi/man.cgi?query=aliases&sektion=5\n>\n>> I don't know what sendmail would actually do with a '#' elsewhere.  It\n>> only talks about having '#' at the beginning of a line, or in the\n>> alias name in quotes (which is not supported by this parser - proper\n>> handling of quoted strings is not easy).  It doesn't say what sendmail\n>> does with '#' if the name is not quoted, and it doesn't define a\n>> meaning for '#' in the definition of an alias.  If these other cases\n>> would be errors for sendmail, so what if they are not errors here?\n>\n> All the more reason to stick with the documented standard. When you\n> diverge from it, you paint the format into a corner, thus closing the\n> door on someone who wants to bring it more in line with the standard.\n\nGiving this a different name leaves the door open to someone who wants\nto write a sendmail parser.  Naming it sendmail and diverging from the\nstandard would close that door.\n\n>\n>>> For the same reason, I'm not convinced that \"simple\" is a good name.\n>>> \"sendmail\" may indeed be a more appropriate name, even if it means\n>>> that this early implementation documents it as (currently) a subset of\n>>> the richer sendmail/postfix 'aliases' format. By doing so, we leave\n>>> the door open so a future person can implement additional features to\n>>> bring it closer to that format.\n>>\n>> Or, a future person can write a sendmail parser that is closer to that format.\n>\n> Yes, but git maintainers must continue to support your \"simple\" format\n> even if someone comes along later and adds a more proper sendmail-like\n> format alongside.\n\nSomeone might implement a sendmail parser in the future, or perhaps\nnever.  So, there is the possibility.  How strong of a reason is that\nto reject some other format that is based on a colon?\n\nWhat is the harm of the two side by side?  This is only a small bit of\ncode that really shouldn't require much maintenance.  What is the harm\nto just leave it in?\n\nIf the future sendmail parser happens to support the simple format,\nand the future maintainers determine the situation to be unacceptable,\nthere is still a solution.  Simply define both names 'simple' and\n'sendmail' to refer to the same sendmail parser.  The dead code can be\nremoved.\n\n> That's why these questions and observations are\n> being raised now: not to string you along and not because your\n> proposal is necessarily undesirable, but because once such support\n> lands in git, then it remains indefinitely and must be supported for\n> the life of the project. Long-term project health is important, which\n> is why it's desirable to consider these issues early, and to avoid\n> painting ourselves into a corner.\n"},{"id":"261936","messageId":"CAJ80satx=A+SHYbvkTrUTpCSDq9UR0CKxGr=0BuLzgJJa4-x3A@mail.gmail.com","threadId":"39406","inReplyTo":"xmqqzj4wedlo.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH v4] send-email: Add simple email aliases format","fromName":"Allen Hubbe","fromEmail":"allenbh@gmail.com","sentAt":"2015-05-22T18:03:45Z","receivedAt":"2015-05-22T18:03:45Z","isPatch":true,"sender":{"key":"allenbh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/812915?v=4"},"body":"On Fri, May 22, 2015 at 1:17 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Allen Hubbe <allenbh@gmail.com> writes:\n>\n>> On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>>\n>>> Let me step back a bit.  Earlier you said your aim is not to use an\n>>> alias file you already have and use with the MUA/MTA, but to have a\n>>> collection of aliases to use with git-send-email only.  Is there a\n>>> reason to add support for a new format (whether it is compatible to\n>>> or subset of postfix/sendmail format, or a totally new one) for that\n>>> goal?  What makes the existing formats unsuitable?\n>>\n>> It's just a matter of personal preference what is suitable or not, for\n>> me, in my environment, etc.  Is there a reason I should use the alias\n>> format of some email client, if I don't use that email client?\n>\n> I do not think \"should\" is a good word in the context of that\n> sentence, as nobody is forcing you to choose one of the existing\n> formats.  But one reason you might want to do so would be because\n> git-send-email already knows about it.\n>\n> It is a different matter if you already use an email client that\n> supports your new format and you are trying to reuse an alias file\n> with that email client.  But I got an impression that was not the\n> case, so the choice seemed to me between\n>\n>  - learning and using one of existing 5; and\n\nI imagine that's what most people would do, faced with the same issue.\nI did initially go look at those formats.  Since I didn't really\nprefer any of them, I approached solving the problem in a different\nway.\n\n>\n>  - inventing, adding support for, and using a new one.\n>\n> That felt to me was a choice that is clearly not in favor of the\n> latter, and I was wondering if there were other reasons to shift the\n> balance.  For example, \"all of the existing formats are klunky and\n> difficult to write\" might be why \"learning and using one of existing\n> 5\" is not a win, compared to \"inventing, ading support for, and\n> using a new one\".  I do not know if that is the case, so I wanted to\n> hear the reason why.\n\nThat \"for example\" is it.  Why should I have to type \"alias\" before\neach alias in the file?  It's not in any way hard to do - it just\nserves no purpose other than to make the parser happy.  Perhaps the\nkeyword does serve a purpose in mutt, but for me it is pointless to\ntype that.\n\n>\n>> I'm not trying to force anything on anyone else by offering this, just\n>> another option that might be suitable for someone else, in their\n>> environment, as it is in mine.  People who don't like it can choose a\n>> different option.  People who don't like any of the options can write\n>> their own like I did, or is that not allowed for some reason?\n>\n> We prefer not to carry dead code---when we add things, we would want\n> to make sure it will be widely useful so that other people benefit.\n\n1 vote for useful.  I realize this is self serving, but I hoped\nsharing it would benefit others.\n\n>\n>> I've already shown that I am willing to change the name, write the\n>> documentation, write the tests, modify the syntax, and so on.  I've\n>> done the work, from +6 lines to +57 lines, as requested.  I'm not\n>> looking forward to v5, v6... v10 of what was a really really simple\n>> patch.  If you don't like it, please don't string me along.  This is\n>> not my job.\n>\n> Yeah, I know.\n>\n> A trade off from contributor's side is between (1) handing the\n> maintenance to the upstream, so that a feature will stay available\n> with minimum fuss in the future, or (2) having to carry one's own\n> enhancement forward every time one updates from the upstream.\n\n(3) good citizenship in open source to share one's changes to the code.\n\n>\n> On the other hand, a trade off from project's side is between (1)\n> rejecting a half-way finished ware and hurting feelings of people\n> and (2) accepting a half-way finished ware and having to spend\n> engineering effort (e.g. making sure it fits to the rest of the\n> system without adding dead weight) to polish it to the end.\n>\n\nI get that, in the general case, and especially for large features\nthat affect a lot of the user base.  How worried are you in this case,\nabout (2), for such a small amount of code that now has a more\nextensive unit test case and documentation than any of the other\noptions?\n"},{"id":"261937","messageId":"CAPig+cRc=u=AKRgp3Dn5De13WcMYFXr1QomzPY0rXAwpN5WwLA@mail.gmail.com","threadId":"39406","inReplyTo":"CAJ80savzM_BL2oPiyTaPYAgnNL7F571aumGJLLw76vtryTacrg@mail.gmail.com","subject":"Re: [PATCH v4] send-email: Add simple email aliases format","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-05-22T18:49:03Z","receivedAt":"2015-05-22T18:49:03Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, May 22, 2015 at 2:01 PM, Allen Hubbe <allenbh@gmail.com> wrote:\n> On Fri, May 22, 2015 at 12:53 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:\n>> On Fri, May 22, 2015 at 8:12 AM, Allen Hubbe <allenbh@gmail.com> wrote:\n>>>> For the same reason, I'm not convinced that \"simple\" is a good name.\n>>>> \"sendmail\" may indeed be a more appropriate name, even if it means\n>>>> that this early implementation documents it as (currently) a subset of\n>>>> the richer sendmail/postfix 'aliases' format. By doing so, we leave\n>>>> the door open so a future person can implement additional features to\n>>>> bring it closer to that format.\n>>>\n>>> Or, a future person can write a sendmail parser that is closer to that format.\n>>\n>> Yes, but git maintainers must continue to support your \"simple\" format\n>> even if someone comes along later and adds a more proper sendmail-like\n>> format alongside.\n>\n> Someone might implement a sendmail parser in the future, or perhaps\n> never.  So, there is the possibility.  How strong of a reason is that\n> to reject some other format that is based on a colon?\n\nNobody has suggested that your format should be rejected. Rather, the\nissue raised regards gratuitous divergence from the sendmail 'aliases'\nformat. You seem to be arguing in favor of gratuitous divergence\n(without explanation) despite the proposed \"proper subset\" approach\nserving your use-case just as well.\n\n> What is the harm of the two side by side?  This is only a small bit of\n> code that really shouldn't require much maintenance.  What is the harm\n> to just leave it in?\n>\n> If the future sendmail parser happens to support the simple format,\n> and the future maintainers determine the situation to be unacceptable,\n> there is still a solution.  Simply define both names 'simple' and\n> 'sendmail' to refer to the same sendmail parser.  The dead code can be\n> removed.\n\nThis \"simple solution\" doesn't work if your new format diverges from\nthe sendmail 'aliases' format, which is why the issue is being raised\nnow, in order to avoid painting ourselves into that corner. If, on the\nother hand, your new format remains a proper subset of sendmail\n'aliases', then the \"simple solution\" does work; and, as a proper\nsubset, it can just as well be named \"sendmail\" without hurting any\nfuture effort to implement missing functionality.\n"}]}