From: Allen Hubbe <allenbh@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH v5 1/1] send-email: Add sendmail email aliases format
Date: Sat, 23 May 2015 19:01:01 -0400 [thread overview]
Message-ID: <CAJ80savjia5ywQcUzGidBx=Jb378YjYT=ZdBt5hQ6WdReTLj0g@mail.gmail.com> (raw)
In-Reply-To: <xmqq7frzcgx2.fsf@gitster.dls.corp.google.com>
On Sat, May 23, 2015 at 2:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
>>> index 804554609def..97387fd27a8d 100644
>>> --- a/Documentation/git-send-email.txt
>>> +++ b/Documentation/git-send-email.txt
>>> @@ -383,7 +383,42 @@ 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 'sendmail', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'.
>
> We prefer to append to an existing list of equals, not prepend.
>
I initially thought to put it last, too. I'll move it back to the end.
I moved it to the beginning, because it seemed odd to me for only the
last thing in the list to have a further description. If the intent
is that eventually (perhaps in an ideal world), the other formats will
have expanded documentation, too, then you are right that adding new
things to the end makes the most sense.
>>> ++
>>> +If the format is 'sendmail', then the alias file format is described below.
>>> +Descriptions of the other file formats can be found by searching the
>>> +documentation of the email program of the same name.
>
> The phrasing feels somewhat awkward. How about dropping the first
> line, pretending as if 'sendmail' is also fully 'sendmail' format,
> and then describe the limitations (like you already did below)? I
> have a feeling that other formats have similar limitations (e.g. I
> do not think piping to commands in any other formats would be
> supported by send-email), and other people can follow suit and
> describe the limitations.
>
> That is, drop the paragraph that describes the basics (which can be
> learned by searching the documentation of the email program of the
> same name), and dive right into the differences.
>
> IOW,
>
> What an alias file in each format looks like can be found in
> the documentation of the email program of the same name. The
> differences and limitations from the standard formats are
> described below:
> +
> --
> sendmail;;
>>> +* Quoted aliases and quoted addresses are not supported: lines that
>>> + contain a `"` symbol are ignored.
>>> +* Line continuations are not supported: any lines that start with
>>> + whitespace, or end with a `\` symbol are ignored.
>>> +* Warnings are printed on the standard error output for any explicitly
>>> + unsupported constructs, and any other lines that are not recognized
>>> + by the parser.
> --
Alright.
Thanks for showing me '--'. I had some trouble with asciidoc, where
my intention was to insert a bulleted list between two paragraphs in a
containing definition-list item. The paragraph that I intended to be
after the bulleted list was instead nested in the last bulleted item
in the list.
The documentation for asciidoc soesn't seem to be very helpful in
describing this construct. There is one example, that I could find,
and I didn't find a description of the syntax for it. Perhaps I
missed it among all the other uses of a series of '-'. I don't see
any way for this to distinguish between different levels of nesting,
like a block of --/-- in another block of --/--; that might be
syntactically indistinguishable from a block of --/-- followed by
another block of --/--.
>
> That way, limitations and deviations of other formats can be added
> later in a consistent way.
>
> Just a thought.
next prev parent reply other threads:[~2015-05-23 23:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-23 13:21 [PATCH v5 1/1] send-email: Add sendmail email aliases format Allen Hubbe
2015-05-23 17:45 ` Junio C Hamano
2015-05-23 18:00 ` Junio C Hamano
2015-05-23 23:01 ` Allen Hubbe [this message]
2015-05-23 18:07 ` Junio C Hamano
2015-05-23 22:24 ` Allen Hubbe
2015-05-25 12:47 ` Allen Hubbe
2015-05-25 16:32 ` Junio C Hamano
2015-05-25 21:12 ` Junio C Hamano
2015-05-25 21:35 ` Junio C Hamano
2015-05-26 1:51 ` Allen Hubbe
2015-05-26 1:58 ` Junio C Hamano
2015-05-26 2:16 ` Allen Hubbe
2015-05-26 2:55 ` Junio C Hamano
2015-05-26 3:34 ` Junio C Hamano
2015-05-26 18:47 ` Eric Sunshine
2015-05-26 19:10 ` Eric Sunshine
2015-05-26 19:41 ` Allen Hubbe
2015-05-26 20:53 ` Eric Sunshine
2015-05-26 21:04 ` Allen Hubbe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ80savjia5ywQcUzGidBx=Jb378YjYT=ZdBt5hQ6WdReTLj0g@mail.gmail.com' \
--to=allenbh@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).