* [PATCH v4] send-email: Add simple email aliases format
@ 2015-05-22 3:40 Allen Hubbe
2015-05-22 4:29 ` Eric Sunshine
0 siblings, 1 reply; 10+ messages in thread
From: Allen Hubbe @ 2015-05-22 3:40 UTC (permalink / raw
To: git; +Cc: Junio C Hamano, Eric Sunshine, Jeff King, Felipe Contreras,
Allen Hubbe
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(-)
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
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v4] send-email: Add simple email aliases format
2015-05-22 3:40 [PATCH v4] send-email: Add simple email aliases format Allen Hubbe
@ 2015-05-22 4:29 ` Eric Sunshine
2015-05-22 12:12 ` Allen Hubbe
0 siblings, 1 reply; 10+ messages in thread
From: Eric Sunshine @ 2015-05-22 4:29 UTC (permalink / raw
To: Allen Hubbe; +Cc: Git List, Junio C Hamano, Jeff King, Felipe Contreras
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.
> ++
> +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
> ++
> +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>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] send-email: Add simple email aliases format
2015-05-22 4:29 ` Eric Sunshine
@ 2015-05-22 12:12 ` Allen Hubbe
2015-05-22 14:44 ` Junio C Hamano
2015-05-22 16:53 ` Eric Sunshine
0 siblings, 2 replies; 10+ messages in thread
From: Allen Hubbe @ 2015-05-22 12:12 UTC (permalink / raw
To: Eric Sunshine; +Cc: Git List, Junio C Hamano, Jeff King, Felipe Contreras
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:
>> 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?
>
>> ++
>> +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.
> 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.
> "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.
>
> [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>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] send-email: Add simple email aliases format
2015-05-22 12:12 ` Allen Hubbe
@ 2015-05-22 14:44 ` Junio C Hamano
2015-05-22 15:39 ` Allen Hubbe
2015-05-22 16:53 ` Eric Sunshine
1 sibling, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2015-05-22 14:44 UTC (permalink / raw
To: Allen Hubbe; +Cc: Eric Sunshine, Git List, Jeff King, Felipe Contreras
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] send-email: Add simple email aliases format
2015-05-22 14:44 ` Junio C Hamano
@ 2015-05-22 15:39 ` Allen Hubbe
2015-05-22 17:17 ` Junio C Hamano
0 siblings, 1 reply; 10+ messages in thread
From: Allen Hubbe @ 2015-05-22 15:39 UTC (permalink / raw
To: Junio C Hamano; +Cc: Eric Sunshine, Git List, Jeff King, Felipe Contreras
On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] send-email: Add simple email aliases format
2015-05-22 12:12 ` Allen Hubbe
2015-05-22 14:44 ` Junio C Hamano
@ 2015-05-22 16:53 ` Eric Sunshine
2015-05-22 18:01 ` Allen Hubbe
1 sibling, 1 reply; 10+ messages in thread
From: Eric Sunshine @ 2015-05-22 16:53 UTC (permalink / raw
To: Allen Hubbe; +Cc: Git List, Junio C Hamano, Jeff King, Felipe Contreras
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.
> 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, 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
> 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.
>> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] send-email: Add simple email aliases format
2015-05-22 15:39 ` Allen Hubbe
@ 2015-05-22 17:17 ` Junio C Hamano
2015-05-22 18:03 ` Allen Hubbe
0 siblings, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2015-05-22 17:17 UTC (permalink / raw
To: Allen Hubbe; +Cc: Eric Sunshine, Git List, Jeff King, Felipe Contreras
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
- 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.
> 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.
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] send-email: Add simple email aliases format
2015-05-22 16:53 ` Eric Sunshine
@ 2015-05-22 18:01 ` Allen Hubbe
2015-05-22 18:49 ` Eric Sunshine
0 siblings, 1 reply; 10+ messages in thread
From: Allen Hubbe @ 2015-05-22 18:01 UTC (permalink / raw
To: Eric Sunshine; +Cc: Git List, Junio C Hamano, Jeff King, Felipe Contreras
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:
>> 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.
>
>> 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.
> 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.
>
> [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.
>
>>> 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.
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] send-email: Add simple email aliases format
2015-05-22 17:17 ` Junio C Hamano
@ 2015-05-22 18:03 ` Allen Hubbe
0 siblings, 0 replies; 10+ messages in thread
From: Allen Hubbe @ 2015-05-22 18:03 UTC (permalink / raw
To: Junio C Hamano; +Cc: Eric Sunshine, Git List, Jeff King, Felipe Contreras
On Fri, May 22, 2015 at 1:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.
>
> - 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.
>
>> 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.
>
>> 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.
>
> 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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] send-email: Add simple email aliases format
2015-05-22 18:01 ` Allen Hubbe
@ 2015-05-22 18:49 ` Eric Sunshine
0 siblings, 0 replies; 10+ messages in thread
From: Eric Sunshine @ 2015-05-22 18:49 UTC (permalink / raw
To: Allen Hubbe; +Cc: Git List, Junio C Hamano, Jeff King, Felipe Contreras
On Fri, May 22, 2015 at 2:01 PM, Allen Hubbe <allenbh@gmail.com> wrote:
> 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.
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-05-22 18:49 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-22 3:40 [PATCH v4] send-email: Add simple email aliases format Allen Hubbe
2015-05-22 4:29 ` Eric Sunshine
2015-05-22 12:12 ` Allen Hubbe
2015-05-22 14:44 ` Junio C Hamano
2015-05-22 15:39 ` Allen Hubbe
2015-05-22 17:17 ` Junio C Hamano
2015-05-22 18:03 ` Allen Hubbe
2015-05-22 16:53 ` Eric Sunshine
2015-05-22 18:01 ` Allen Hubbe
2015-05-22 18:49 ` Eric Sunshine
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.