threads / patch / 39406

v4send-email: Add simple email aliases format

Subject: [PATCH v4] send-email: Add simple email aliases format

## tl;dr

10 messages between May 22, 2015 and May 22, 2015. Diffs are folded; open one to read it.

replies: 9people: 3as markdown or json

Allen Hubbe· May 22, 2015, 03:40 UTC · lore

This format is more simple than the other alias file formats, so it may be preferred by some users. The format is as follows.

	<alias>: <address|alias>[, <address|alias>...]

Aliases are specified one per line. There is no line splitting. Anything on a line after and including a `#` symbol is considered a comment, and is ignored. Blank lines are ignored.

Example of the 'simple' format:
	alice: Alice W Land <awol@example.com>
	bob: Robert Bobbyton <bob@example.com>
	# this is a comment
	   # this is also a comment
	chloe: chloe@example.com
	abgroup: alice, bob # comment after an alias
	bcgrp: bob, chloe, Other <o@example.com>
Signed-off-by: Allen Hubbe <allenbh@gmail.com>
---
Notes:
    Note, v3 was sent in error.  This v4 presents changes since v2.
    
    This v4 extends the syntax to allow blank lines, and comments.  The test
    case is extended with comments added to alias file input.
    
    The Documentation/git-send-email.txt is updated with a description of
    the simple format.  A note is added for the other formats, directing
    readers to check the documentation of the email clients for a
    description.
 Documentation/git-send-email.txt | 24 +++++++++++++++++++++++-
 git-send-email.perl              |  8 +++++++-
 t/t9001-send-email.sh            | 27 +++++++++++++++++++++++++++
 3 files changed, 57 insertions(+), 2 deletions(-)
Show changes to 3 files +57 −2

Documentation/git-send-email.txt, git-send-email.perl, t/t9001-send-email.sh

diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 804554609def..38ade31e0c28 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -383,7 +383,29 @@ sendemail.aliasesFile::
 
 sendemail.aliasFileType::
 	Format of the file(s) specified in sendemail.aliasesFile. Must be
-	one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.
+	one of 'simple', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.
++
+If the format is 'simple', then the alias file format is described below.
+Descriptions of the other file formats to the following formats can be found in
+the documentation of the email program of the same name.
++
+This 'simple' format is is as follows.
++
+	<alias>: <address|alias>[, <address|alias>...]
++
+Aliases are specified one per line.  There is no line splitting.  Anything on a
+line after and including a `#` symbol is considered a comment, and is ignored.
+Blank lines are ignored.
++
+Example of the 'simple' format:
++
+	alice: Alice W Land <awol@example.com>
+	bob: Robert Bobbyton <bob@example.com>
+	# this is a comment
+	   # this is also a comment
+	chloe: chloe@example.com
+	abgroup: alice, bob # comment after an alias
+	bcgrp: bob, chloe, Other <o@example.com>
 
 sendemail.multiEdit::
 	If true (default), a single editor instance will be spawned to edit
diff --git a/git-send-email.perl b/git-send-email.perl
index e1e9b1460ced..716c2bc9479a 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -515,7 +515,13 @@ my %parse_alias = (
 			       $aliases{$alias} = [ split_addrs($addr) ];
 			  }
 		      } },
-
+	simple => sub { my $fh = shift; while (<$fh>) {
+		s/#.*$//;
+		next if /^\s*$/;
+		if (/^\s*(\S+)\s*:\s*(.+)$/) {
+			my ($alias, $addr) = ($1, $2);
+			$aliases{$alias} = [ split_addrs($addr) ];
+		}}},
 	gnus => sub { my $fh = shift; while (<$fh>) {
 		if (/\(define-mail-alias\s+"(\S+?)"\s+"(\S+?)"\)/) {
 			$aliases{$1} = [ $2 ];
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 7be14a4e37f7..12c1a0c76f1d 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1549,6 +1549,33 @@ test_expect_success $PREREQ 'sendemail.aliasfile=~/.mailrc' '
 	grep "^!someone@example\.org!$" commandline1
 '
 
+test_expect_success $PREREQ 'sendemail.aliasfiletype=simple' '
+	clean_fake_sendmail && rm -fr outdir &&
+	git format-patch -1 -o outdir &&
+	{
+		echo "alice: Alice W Land <awol@example.com>"
+		echo "bob: Robert Bobbyton <bob@example.com>"
+		echo "# this is a comment"
+		echo "   # this is also a comment"
+		echo "chloe: chloe@example.com"
+		echo "abgroup: alice, bob # comment after an alias"
+		echo "bcgrp: bob, chloe, Other <o@example.com>"
+	} >~/.tmp-email-aliases &&
+	git config --replace-all sendemail.aliasesfile \
+		"$(pwd)/.tmp-email-aliases" &&
+	git config sendemail.aliasfiletype simple &&
+	git send-email \
+		--from="Example <nobody@example.com>" \
+		--to=alice --to=bcgrp \
+		--smtp-server="$(pwd)/fake.sendmail" \
+		outdir/0001-*.patch \
+		2>errors >out &&
+	grep "^!awol@example\.com!$" commandline1 &&
+	grep "^!bob@example\.com!$" commandline1 &&
+	grep "^!chloe@example\.com!$" commandline1 &&
+	grep "^!o@example\.com!$" commandline1
+'
+
 do_xmailer_test () {
 	expected=$1 params=$2 &&
 	git format-patch -1 &&
-- 
2.3.4
Eric Sunshine· May 22, 2015, 04:29 UTC · re: Allen Hubbe · lore

Re: [PATCH v4] send-email: Add simple email aliases format

On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe <allenbh@gmail.com> wrote:
Show 18 quoted lines
> This format is more simple than the other alias file formats, so it may
> be preferred by some users. [...]
> Signed-off-by: Allen Hubbe <allenbh@gmail.com>
> ---
> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
> index 804554609def..38ade31e0c28 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -383,7 +383,29 @@ sendemail.aliasesFile::
>
>  sendemail.aliasFileType::
>         Format of the file(s) specified in sendemail.aliasesFile. Must be
> -       one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.
> +       one of 'simple', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.
> ++
> +If the format is 'simple', then the alias file format is described below.
> +Descriptions of the other file formats to the following formats can be found in
> +the documentation of the email program of the same name.
The second sentence probably needs some proof-reading.
Show 8 quoted lines
> ++
> +This 'simple' format is is as follows.
> ++
> +       <alias>: <address|alias>[, <address|alias>...]
> ++
> +Aliases are specified one per line.  There is no line splitting.  Anything on a
> +line after and including a `#` symbol is considered a comment, and is ignored.
> +Blank lines are ignored.

I'm not convinced that gratuitously diverging from the sendmail/postfix 'aliases' format is warranted. In particular, that format recognizes a comment line only when '#' is the first non-whitespace character[1]; and does not consider '#' a comment-introducer anywhere else in the line. By recognizing '#' anywhere as a comment-introducer, you may be painting this format into a corner rather than leaving it open for someone later to extend it to be more sendmail/postfix-like by, for instance, supporting name quoting and line-continuation[1].

For the same reason, I'm not convinced that "simple" is a good name. "sendmail" may indeed be a more appropriate name, even if it means that this early implementation documents it as (currently) a subset of the richer sendmail/postfix 'aliases' format. By doing so, we leave the door open so a future person can implement additional features to bring it closer to that format.

[1]: http://www.postfix.org/aliases.5.html
Show 10 quoted lines
> ++
> +Example of the 'simple' format:
> ++
> +       alice: Alice W Land <awol@example.com>
> +       bob: Robert Bobbyton <bob@example.com>
> +       # this is a comment
> +          # this is also a comment
> +       chloe: chloe@example.com
> +       abgroup: alice, bob # comment after an alias
> +       bcgrp: bob, chloe, Other <o@example.com>
Allen Hubbe· May 22, 2015, 12:12 UTC · re: Eric Sunshine · lore

Re: [PATCH v4] send-email: Add simple email aliases format

On Fri, May 22, 2015 at 12:29 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 21 quoted lines
> On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe <allenbh@gmail.com> wrote:
>> This format is more simple than the other alias file formats, so it may
>> be preferred by some users. [...]
>> Signed-off-by: Allen Hubbe <allenbh@gmail.com>
>> ---
>> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
>> index 804554609def..38ade31e0c28 100644
>> --- a/Documentation/git-send-email.txt
>> +++ b/Documentation/git-send-email.txt
>> @@ -383,7 +383,29 @@ sendemail.aliasesFile::
>>
>>  sendemail.aliasFileType::
>>         Format of the file(s) specified in sendemail.aliasesFile. Must be
>> -       one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.
>> +       one of 'simple', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.
>> ++
>> +If the format is 'simple', then the alias file format is described below.
>> +Descriptions of the other file formats to the following formats can be found in
>> +the documentation of the email program of the same name.
>
> The second sentence probably needs some proof-reading.
Could you be more specific?
Show 12 quoted lines
>
>> ++
>> +This 'simple' format is is as follows.
>> ++
>> +       <alias>: <address|alias>[, <address|alias>...]
>> ++
>> +Aliases are specified one per line.  There is no line splitting.  Anything on a
>> +line after and including a `#` symbol is considered a comment, and is ignored.
>> +Blank lines are ignored.
>
> I'm not convinced that gratuitously diverging from the
> sendmail/postfix 'aliases' format is warranted. In particular, that
This isn't 'sendmail', as of v2.
Show 7 quoted lines
> format recognizes a comment line only when '#' is the first
> non-whitespace character[1]; and does not consider '#' a
> comment-introducer anywhere else in the line. By recognizing '#'
> anywhere as a comment-introducer, you may be painting this format into
> a corner rather than leaving it open for someone later to extend it to
> be more sendmail/postfix-like by, for instance, supporting name
> quoting and line-continuation[1].

It depends what we want to do with this parser: accept existing sendmail aliases files in git, or enforce that git alias files are usable for sendmail. I really don't expect the second to ever happen. The first, maybe, but only if the alias file is edited to remove aliases of pipes and maildirs etc. The second may not work if we have comments to the right, or aliases of aliases, which sendmail does not claim to support.

I don't know what sendmail would actually do with a '#' elsewhere. It only talks about having '#' at the beginning of a line, or in the alias name in quotes (which is not supported by this parser - proper handling of quoted strings is not easy). It doesn't say what sendmail does with '#' if the name is not quoted, and it doesn't define a meaning for '#' in the definition of an alias. If these other cases would be errors for sendmail, so what if they are not errors here?

>
> For the same reason, I'm not convinced that "simple" is a good name.

I was worried about that back in v1 before going to v2, but I really don't have a strong opinion about the name. I already changed the name, at the suggestion of Junio. I'd like to hear a consensus from you two, or a tiebreaker from a third, before I change it again.

Show 5 quoted lines
> "sendmail" may indeed be a more appropriate name, even if it means
> that this early implementation documents it as (currently) a subset of
> the richer sendmail/postfix 'aliases' format. By doing so, we leave
> the door open so a future person can implement additional features to
> bring it closer to that format.
Or, a future person can write a sendmail parser that is closer to that format.
Show 13 quoted lines
>
> [1]: http://www.postfix.org/aliases.5.html
>
>> ++
>> +Example of the 'simple' format:
>> ++
>> +       alice: Alice W Land <awol@example.com>
>> +       bob: Robert Bobbyton <bob@example.com>
>> +       # this is a comment
>> +          # this is also a comment
>> +       chloe: chloe@example.com
>> +       abgroup: alice, bob # comment after an alias
>> +       bcgrp: bob, chloe, Other <o@example.com>
Junio C Hamano· May 22, 2015, 14:44 UTC · re: Allen Hubbe · lore

Re: [PATCH v4] send-email: Add simple email aliases format

Allen Hubbe <allenbh@gmail.com> writes:
Show 7 quoted lines
> It depends what we want to do with this parser: accept existing
> sendmail aliases files in git, or enforce that git alias files are
> usable for sendmail.  I really don't expect the second to ever happen.
> The first, maybe, but only if the alias file is edited to remove
> aliases of pipes and maildirs etc.  The second may not work if we have
> comments to the right, or aliases of aliases, which sendmail does not
> claim to support.

Let me step back a bit. Earlier you said your aim is not to use an alias file you already have and use with the MUA/MTA, but to have a collection of aliases to use with git-send-email only. Is there a reason to add support for a new format (whether it is compatible to or subset of postfix/sendmail format, or a totally new one) for that goal? What makes the existing formats unsuitable?

Allen Hubbe· May 22, 2015, 15:39 UTC · re: Junio C Hamano · lore

Re: [PATCH v4] send-email: Add simple email aliases format

On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 17 quoted lines
> Allen Hubbe <allenbh@gmail.com> writes:
>
>> It depends what we want to do with this parser: accept existing
>> sendmail aliases files in git, or enforce that git alias files are
>> usable for sendmail.  I really don't expect the second to ever happen.
>> The first, maybe, but only if the alias file is edited to remove
>> aliases of pipes and maildirs etc.  The second may not work if we have
>> comments to the right, or aliases of aliases, which sendmail does not
>> claim to support.
>
> Let me step back a bit.  Earlier you said your aim is not to use an
> alias file you already have and use with the MUA/MTA, but to have a
> collection of aliases to use with git-send-email only.  Is there a
> reason to add support for a new format (whether it is compatible to
> or subset of postfix/sendmail format, or a totally new one) for that
> goal?  What makes the existing formats unsuitable?
>

It's just a matter of personal preference what is suitable or not, for me, in my environment, etc. Is there a reason I should use the alias format of some email client, if I don't use that email client?

I'm not trying to force anything on anyone else by offering this, just another option that might be suitable for someone else, in their environment, as it is in mine. People who don't like it can choose a different option. People who don't like any of the options can write their own like I did, or is that not allowed for some reason?

I've already shown that I am willing to change the name, write the documentation, write the tests, modify the syntax, and so on. I've done the work, from +6 lines to +57 lines, as requested. I'm not looking forward to v5, v6... v10 of what was a really really simple patch. If you don't like it, please don't string me along. This is not my job. If you think the patch is generally ok, but could be improved to be accepted, then let's together try to make v5 the last.

Junio C Hamano· May 22, 2015, 17:17 UTC · re: Allen Hubbe · lore

Re: [PATCH v4] send-email: Add simple email aliases format

Allen Hubbe <allenbh@gmail.com> writes:
Show 12 quoted lines
> On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Let me step back a bit.  Earlier you said your aim is not to use an
>> alias file you already have and use with the MUA/MTA, but to have a
>> collection of aliases to use with git-send-email only.  Is there a
>> reason to add support for a new format (whether it is compatible to
>> or subset of postfix/sendmail format, or a totally new one) for that
>> goal?  What makes the existing formats unsuitable?
>
> It's just a matter of personal preference what is suitable or not, for
> me, in my environment, etc.  Is there a reason I should use the alias
> format of some email client, if I don't use that email client?

I do not think "should" is a good word in the context of that sentence, as nobody is forcing you to choose one of the existing formats. But one reason you might want to do so would be because git-send-email already knows about it.

It is a different matter if you already use an email client that supports your new format and you are trying to reuse an alias file with that email client. But I got an impression that was not the case, so the choice seemed to me between

 - learning and using one of existing 5; and
 - inventing, adding support for, and using a new one.

That felt to me was a choice that is clearly not in favor of the latter, and I was wondering if there were other reasons to shift the balance. For example, "all of the existing formats are klunky and difficult to write" might be why "learning and using one of existing 5" is not a win, compared to "inventing, ading support for, and using a new one". I do not know if that is the case, so I wanted to hear the reason why.

Show 5 quoted lines
> I'm not trying to force anything on anyone else by offering this, just
> another option that might be suitable for someone else, in their
> environment, as it is in mine.  People who don't like it can choose a
> different option.  People who don't like any of the options can write
> their own like I did, or is that not allowed for some reason?

We prefer not to carry dead code---when we add things, we would want to make sure it will be widely useful so that other people benefit.

Show 6 quoted lines
> I've already shown that I am willing to change the name, write the
> documentation, write the tests, modify the syntax, and so on.  I've
> done the work, from +6 lines to +57 lines, as requested.  I'm not
> looking forward to v5, v6... v10 of what was a really really simple
> patch.  If you don't like it, please don't string me along.  This is
> not my job.
Yeah, I know.

A trade off from contributor's side is between (1) handing the maintenance to the upstream, so that a feature will stay available with minimum fuss in the future, or (2) having to carry one's own enhancement forward every time one updates from the upstream.

On the other hand, a trade off from project's side is between (1) rejecting a half-way finished ware and hurting feelings of people and (2) accepting a half-way finished ware and having to spend engineering effort (e.g. making sure it fits to the rest of the system without adding dead weight) to polish it to the end.

Allen Hubbe· May 22, 2015, 18:03 UTC · re: Junio C Hamano · lore

Re: [PATCH v4] send-email: Add simple email aliases format

On Fri, May 22, 2015 at 1:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 26 quoted lines
> Allen Hubbe <allenbh@gmail.com> writes:
>
>> On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>>> Let me step back a bit.  Earlier you said your aim is not to use an
>>> alias file you already have and use with the MUA/MTA, but to have a
>>> collection of aliases to use with git-send-email only.  Is there a
>>> reason to add support for a new format (whether it is compatible to
>>> or subset of postfix/sendmail format, or a totally new one) for that
>>> goal?  What makes the existing formats unsuitable?
>>
>> It's just a matter of personal preference what is suitable or not, for
>> me, in my environment, etc.  Is there a reason I should use the alias
>> format of some email client, if I don't use that email client?
>
> I do not think "should" is a good word in the context of that
> sentence, as nobody is forcing you to choose one of the existing
> formats.  But one reason you might want to do so would be because
> git-send-email already knows about it.
>
> It is a different matter if you already use an email client that
> supports your new format and you are trying to reuse an alias file
> with that email client.  But I got an impression that was not the
> case, so the choice seemed to me between
>
>  - learning and using one of existing 5; and

I imagine that's what most people would do, faced with the same issue. I did initially go look at those formats. Since I didn't really prefer any of them, I approached solving the problem in a different way.

Show 10 quoted lines
>
>  - inventing, adding support for, and using a new one.
>
> That felt to me was a choice that is clearly not in favor of the
> latter, and I was wondering if there were other reasons to shift the
> balance.  For example, "all of the existing formats are klunky and
> difficult to write" might be why "learning and using one of existing
> 5" is not a win, compared to "inventing, ading support for, and
> using a new one".  I do not know if that is the case, so I wanted to
> hear the reason why.

That "for example" is it. Why should I have to type "alias" before each alias in the file? It's not in any way hard to do - it just serves no purpose other than to make the parser happy. Perhaps the keyword does serve a purpose in mutt, but for me it is pointless to type that.

Show 9 quoted lines
>
>> I'm not trying to force anything on anyone else by offering this, just
>> another option that might be suitable for someone else, in their
>> environment, as it is in mine.  People who don't like it can choose a
>> different option.  People who don't like any of the options can write
>> their own like I did, or is that not allowed for some reason?
>
> We prefer not to carry dead code---when we add things, we would want
> to make sure it will be widely useful so that other people benefit.

1 vote for useful. I realize this is self serving, but I hoped sharing it would benefit others.

Show 14 quoted lines
>
>> I've already shown that I am willing to change the name, write the
>> documentation, write the tests, modify the syntax, and so on.  I've
>> done the work, from +6 lines to +57 lines, as requested.  I'm not
>> looking forward to v5, v6... v10 of what was a really really simple
>> patch.  If you don't like it, please don't string me along.  This is
>> not my job.
>
> Yeah, I know.
>
> A trade off from contributor's side is between (1) handing the
> maintenance to the upstream, so that a feature will stay available
> with minimum fuss in the future, or (2) having to carry one's own
> enhancement forward every time one updates from the upstream.
(3) good citizenship in open source to share one's changes to the code.
Show 7 quoted lines
>
> On the other hand, a trade off from project's side is between (1)
> rejecting a half-way finished ware and hurting feelings of people
> and (2) accepting a half-way finished ware and having to spend
> engineering effort (e.g. making sure it fits to the rest of the
> system without adding dead weight) to polish it to the end.
>

I get that, in the general case, and especially for large features that affect a lot of the user base. How worried are you in this case, about (2), for such a small amount of code that now has a more extensive unit test case and documentation than any of the other options?

Eric Sunshine· May 22, 2015, 16:53 UTC · re: Allen Hubbe · lore

Re: [PATCH v4] send-email: Add simple email aliases format

On Fri, May 22, 2015 at 8:12 AM, Allen Hubbe <allenbh@gmail.com> wrote:
Show 9 quoted lines
> On Fri, May 22, 2015 at 12:29 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe <allenbh@gmail.com> wrote:
>>> +If the format is 'simple', then the alias file format is described below.
>>> +Descriptions of the other file formats to the following formats can be found in
>>> +the documentation of the email program of the same name.
>>
>> The second sentence probably needs some proof-reading.
>
> Could you be more specific?

Unable to parse "of the other file formats to the following formats". I'm guessing that the "to the following formats" portion doesn't belong.

> It depends what we want to do with this parser: accept existing
> sendmail aliases files in git, or enforce that git alias files are
> usable for sendmail.

Aside from these possibilities (likely or unlikely), there is also the issue of breaking expectations. Precedence for this style 'aliases' format was set decades ago by sendmail. People are familiar with it and understand its strengths and weaknesses. Even if documented as not being sendmail-compatible, because it's so similar to sendmail 'aliases', people will expect it to work the same way, thus unless there's a good reason to diverge from that standard format, it makes sense to be compatible with it (even if only as a proper subset).

Show 5 quoted lines
> I really don't expect the second to ever happen.
> The first, maybe, but only if the alias file is edited to remove
> aliases of pipes and maildirs etc.  The second may not work if we have
> comments to the right, or aliases of aliases, which sendmail does not
> claim to support.

It's not clear why you say that sendmail does not claim to support aliases of aliases. Although it's true that some sources, such as [1], fail to mention support explicitly, other more authoritative sources do[2]. Moreover, the 1993 "sendmail" book by Bryan Costales, with contributions from Eric Allman (the creator of sendmail), talks explicitly about expansion of aliases on the right-hand-side. Finally, since time immemorial (at least the early 1980's), every /etc/aliases file has contained the following mandatory entries:

    postmaster: root
    MAILER-DAEMON: postmaster
which indicates clearly that alias expansion on the RHS is supported.

[1]: http://www.feep.net/sendmail/tutorial/intro/aliases.html [2]: https://www.freebsd.org/cgi/man.cgi?query=aliases&sektion=5

Show 7 quoted lines
> I don't know what sendmail would actually do with a '#' elsewhere.  It
> only talks about having '#' at the beginning of a line, or in the
> alias name in quotes (which is not supported by this parser - proper
> handling of quoted strings is not easy).  It doesn't say what sendmail
> does with '#' if the name is not quoted, and it doesn't define a
> meaning for '#' in the definition of an alias.  If these other cases
> would be errors for sendmail, so what if they are not errors here?

All the more reason to stick with the documented standard. When you diverge from it, you paint the format into a corner, thus closing the door on someone who wants to bring it more in line with the standard.

Show 8 quoted lines
>> For the same reason, I'm not convinced that "simple" is a good name.
>> "sendmail" may indeed be a more appropriate name, even if it means
>> that this early implementation documents it as (currently) a subset of
>> the richer sendmail/postfix 'aliases' format. By doing so, we leave
>> the door open so a future person can implement additional features to
>> bring it closer to that format.
>
> Or, a future person can write a sendmail parser that is closer to that format.

Yes, but git maintainers must continue to support your "simple" format even if someone comes along later and adds a more proper sendmail-like format alongside. That's why these questions and observations are being raised now: not to string you along and not because your proposal is necessarily undesirable, but because once such support lands in git, then it remains indefinitely and must be supported for the life of the project. Long-term project health is important, which is why it's desirable to consider these issues early, and to avoid painting ourselves into a corner.

Allen Hubbe· May 22, 2015, 18:01 UTC · re: Eric Sunshine · lore

Re: [PATCH v4] send-email: Add simple email aliases format

On Fri, May 22, 2015 at 12:53 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 14 quoted lines
> On Fri, May 22, 2015 at 8:12 AM, Allen Hubbe <allenbh@gmail.com> wrote:
>> On Fri, May 22, 2015 at 12:29 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe <allenbh@gmail.com> wrote:
>>>> +If the format is 'simple', then the alias file format is described below.
>>>> +Descriptions of the other file formats to the following formats can be found in
>>>> +the documentation of the email program of the same name.
>>>
>>> The second sentence probably needs some proof-reading.
>>
>> Could you be more specific?
>
> Unable to parse "of the other file formats to the following formats".
> I'm guessing that the "to the following formats" portion doesn't
> belong.

Thanks. It's obvious now that it's pointed out. It's hard to proofread one's own writing.

Show 23 quoted lines
>
>> It depends what we want to do with this parser: accept existing
>> sendmail aliases files in git, or enforce that git alias files are
>> usable for sendmail.
>
> Aside from these possibilities (likely or unlikely), there is also the
> issue of breaking expectations. Precedence for this style 'aliases'
> format was set decades ago by sendmail. People are familiar with it
> and understand its strengths and weaknesses. Even if documented as not
> being sendmail-compatible, because it's so similar to sendmail
> 'aliases', people will expect it to work the same way, thus unless
> there's a good reason to diverge from that standard format, it makes
> sense to be compatible with it (even if only as a proper subset).
>
>> I really don't expect the second to ever happen.
>> The first, maybe, but only if the alias file is edited to remove
>> aliases of pipes and maildirs etc.  The second may not work if we have
>> comments to the right, or aliases of aliases, which sendmail does not
>> claim to support.
>
> It's not clear why you say that sendmail does not claim to support
> aliases of aliases. Although it's true that some sources, such as [1],
> fail to mention support explicitly,
That's why I said it.
Show 11 quoted lines
> other more authoritative sources
> do[2]. Moreover, the 1993 "sendmail" book by Bryan Costales, with
> contributions from Eric Allman (the creator of sendmail), talks
> explicitly about expansion of aliases on the right-hand-side. Finally,
> since time immemorial (at least the early 1980's), every /etc/aliases
> file has contained the following mandatory entries:
>
>     postmaster: root
>     MAILER-DAEMON: postmaster
>
> which indicates clearly that alias expansion on the RHS is supported.
Ok, no harm then if aliases are supported.
Show 15 quoted lines
>
> [1]: http://www.feep.net/sendmail/tutorial/intro/aliases.html
> [2]: https://www.freebsd.org/cgi/man.cgi?query=aliases&sektion=5
>
>> I don't know what sendmail would actually do with a '#' elsewhere.  It
>> only talks about having '#' at the beginning of a line, or in the
>> alias name in quotes (which is not supported by this parser - proper
>> handling of quoted strings is not easy).  It doesn't say what sendmail
>> does with '#' if the name is not quoted, and it doesn't define a
>> meaning for '#' in the definition of an alias.  If these other cases
>> would be errors for sendmail, so what if they are not errors here?
>
> All the more reason to stick with the documented standard. When you
> diverge from it, you paint the format into a corner, thus closing the
> door on someone who wants to bring it more in line with the standard.

Giving this a different name leaves the door open to someone who wants to write a sendmail parser. Naming it sendmail and diverging from the standard would close that door.

Show 13 quoted lines
>
>>> For the same reason, I'm not convinced that "simple" is a good name.
>>> "sendmail" may indeed be a more appropriate name, even if it means
>>> that this early implementation documents it as (currently) a subset of
>>> the richer sendmail/postfix 'aliases' format. By doing so, we leave
>>> the door open so a future person can implement additional features to
>>> bring it closer to that format.
>>
>> Or, a future person can write a sendmail parser that is closer to that format.
>
> Yes, but git maintainers must continue to support your "simple" format
> even if someone comes along later and adds a more proper sendmail-like
> format alongside.

Someone might implement a sendmail parser in the future, or perhaps never. So, there is the possibility. How strong of a reason is that to reject some other format that is based on a colon?

What is the harm of the two side by side? This is only a small bit of code that really shouldn't require much maintenance. What is the harm to just leave it in?

If the future sendmail parser happens to support the simple format, and the future maintainers determine the situation to be unacceptable, there is still a solution. Simply define both names 'simple' and 'sendmail' to refer to the same sendmail parser. The dead code can be removed.

Show 7 quoted lines
> That's why these questions and observations are
> being raised now: not to string you along and not because your
> proposal is necessarily undesirable, but because once such support
> lands in git, then it remains indefinitely and must be supported for
> the life of the project. Long-term project health is important, which
> is why it's desirable to consider these issues early, and to avoid
> painting ourselves into a corner.
Eric Sunshine· May 22, 2015, 18:49 UTC · re: Allen Hubbe · lore

Re: [PATCH v4] send-email: Add simple email aliases format

On Fri, May 22, 2015 at 2:01 PM, Allen Hubbe <allenbh@gmail.com> wrote:
Show 18 quoted lines
> On Fri, May 22, 2015 at 12:53 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Fri, May 22, 2015 at 8:12 AM, Allen Hubbe <allenbh@gmail.com> wrote:
>>>> For the same reason, I'm not convinced that "simple" is a good name.
>>>> "sendmail" may indeed be a more appropriate name, even if it means
>>>> that this early implementation documents it as (currently) a subset of
>>>> the richer sendmail/postfix 'aliases' format. By doing so, we leave
>>>> the door open so a future person can implement additional features to
>>>> bring it closer to that format.
>>>
>>> Or, a future person can write a sendmail parser that is closer to that format.
>>
>> Yes, but git maintainers must continue to support your "simple" format
>> even if someone comes along later and adds a more proper sendmail-like
>> format alongside.
>
> Someone might implement a sendmail parser in the future, or perhaps
> never.  So, there is the possibility.  How strong of a reason is that
> to reject some other format that is based on a colon?

Nobody has suggested that your format should be rejected. Rather, the issue raised regards gratuitous divergence from the sendmail 'aliases' format. You seem to be arguing in favor of gratuitous divergence (without explanation) despite the proposed "proper subset" approach serving your use-case just as well.

Show 9 quoted lines
> What is the harm of the two side by side?  This is only a small bit of
> code that really shouldn't require much maintenance.  What is the harm
> to just leave it in?
>
> If the future sendmail parser happens to support the simple format,
> and the future maintainers determine the situation to be unacceptable,
> there is still a solution.  Simply define both names 'simple' and
> 'sendmail' to refer to the same sendmail parser.  The dead code can be
> removed.

This "simple solution" doesn't work if your new format diverges from the sendmail 'aliases' format, which is why the issue is being raised now, in order to avoid painting ourselves into that corner. If, on the other hand, your new format remains a proper subset of sendmail 'aliases', then the "simple solution" does work; and, as a proper subset, it can just as well be named "sendmail" without hurting any future effort to implement missing functionality.

← back to recent threads