On 06/09/2016 01:49 PM, Matthieu Moy wrote:
Samuel GROOT writes:
If used with `in-reply-to=`, cite the message body of the given
email file. Otherwise, do nothing.
It should at least warn when --in-reply-to= is not given
(either no --in-reply-to or --in-reply-to=). I don't see any
use
On 06/09/2016 11:45 AM, Matthieu Moy wrote:
Samuel GROOT writes:
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index edbba3a..21776f0 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -84,13 +84,16 @@ See the
On 06/08/2016 08:23 PM, Junio C Hamano wrote:
Samuel GROOT writes:
+if ($initial_reply_to && -f $initial_reply_to) {
+ my $error = validate_patch($initial_reply_to);
This call is wrong, isn't it?
You are not going to send out the message you are responding to (the
me
On 06/14/2016 12:47 AM, Eric Wong wrote:
Samuel GROOT wrote:
On 06/09/2016 02:21 AM, Eric Wong wrote:
Samuel GROOT wrote:
Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
Should we handle \n\r at end of line as well?
"\n\r" can never happen with local $/ = &qu
On 06/09/2016 07:55 AM, Matthieu Moy wrote:
Tom Russello writes:
Check if the given utf-8 email address is in the Cc: field.
I wouldn't harm to explain what was the problem with existing code here.
If I understand correctly, that would be:
Existing code just checked that the address appea
On 06/09/2016 08:01 AM, Matthieu Moy wrote:
Samuel GROOT writes:
On 06/08/2016 06:09 PM, Junio C Hamano wrote:
Samuel GROOT writes:
Actually we had issues when trying to refactor send-email's email
parsing loop [1]. Email addresses in output file `commandeline1` in
tests weren
On 06/09/2016 08:17 AM, Matthieu Moy wrote:
Samuel GROOT writes:
@@ -647,10 +647,10 @@ test_expect_success $PREREQ '--suppress-cc=all' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-body <<\EOF
0001-Second.patch
-(mbox) Add
On 06/09/2016 02:21 AM, Eric Wong wrote:
Samuel GROOT wrote:
Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
Should we handle \n\r at end of line as well?
"\n\r" can never happen with local $/ = "\n"
If the email file contains "\n\r", settin
On 06/09/2016 08:51 AM, Eric Sunshine wrote:
On Wed, Jun 8, 2016 at 7:54 PM, Samuel GROOT
wrote:
On 06/08/2016 10:17 PM, Junio C Hamano wrote:
Eric Sunshine writes:
An embedded CR probably shouldn't happen, but I'm not convinced that
folding it out is a good idea. I would think
On 06/08/2016 10:17 PM, Junio C Hamano wrote:
Eric Sunshine writes:
An embedded CR probably shouldn't happen, but I'm not convinced that
folding it out is a good idea. I would think that you'd want to
preserve the header's value verbatim. If anything, I'd expect to see
the regex tightened to:
On 06/08/2016 09:31 PM, Junio C Hamano wrote:
Samuel GROOT writes:
I think it's the best way to do it indeed. Furthermore, we did trim
CRs and LFs in header fields, but not in the message, making the
subroutine inconsistent.
Should we rename the subroutine to `parse_header` or leave it
On 06/08/2016 09:33 PM, Junio C Hamano wrote:
Samuel GROOT writes:
On 06/08/2016 07:37 PM, Junio C Hamano wrote:
Samuel GROOT writes:
+ printf("Adding cc: %s from From: header\n",
+ $1) unl
On 06/08/2016 07:58 PM, Junio C Hamano wrote:
Samuel GROOT writes:
+sub parse_email {
+ my %mail = ();
+ my $fh = shift;
+ my $last_header;
+ # Unfold and parse multiline header fields
+ while (<$fh>) {
+ last if /^\s*$/;
You stop at the
On 06/08/2016 08:12 PM, Eric Sunshine wrote:
On Wed, Jun 8, 2016 at 1:58 PM, Junio C Hamano wrote:
Samuel GROOT writes:
+sub parse_email {
+ my %mail = ();
+ my $fh = shift;
+ my $last_header;
+ # Unfold and parse multiline header fields
+ while (<
On 06/08/2016 06:56 PM, Junio C Hamano wrote:
> The earliest address pa...@example.com and later addresses have
> quite different meaning (the first one is meant to be the envelope
> sender address, and does not name a recipient). While I think it is
> a good idea to tell the test that the order o
On 06/08/2016 08:32 PM, Junio C Hamano wrote:
Eric Sunshine writes:
+ # Separate body from header
+ $mail{"body"} = [(<$fh>)];
+
+ return \%mail;
The name of the local thing is not observable from the caller, but
because this is "parse-email-header" and returns "header fields"
wit
On 06/08/2016 07:34 PM, Junio C Hamano wrote:
Samuel GROOT writes:
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 56ad8ce..943e6b7 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -888,8 +888,8 @@ test_expect_success $PREREQ 'utf8 Cc is rfc2047 en
On 06/08/2016 07:17 PM, Junio C Hamano wrote:
Here is an illustration of an organization that I think would be
easier to read, and would result in a more readable patch when
modification is made on top. The first two hunks collapse the
overall "setup" steps that appear as three separate tests in
On 06/08/2016 07:37 PM, Junio C Hamano wrote:
Samuel GROOT writes:
+ printf("Adding cc: %s from From: header\n",
+ $1) unless $quiet;
+ printf("Adding to: %s fro
On 06/08/2016 06:09 PM, Junio C Hamano wrote:
Samuel GROOT writes:
Actually we had issues when trying to refactor send-email's email
parsing loop [1]. Email addresses in output file `commandeline1` in
tests weren't sorted the same way as the reference file it was
compared to. E.g
On 06/08/2016 04:22 PM, Remi Galan Alfonso wrote:
+test_cmp_noorder () {
+sort "$1" >"$1_noorder"
+sort "$2" >"$2_noorder"
+test_cmp $1 $2
You meant `test_cmp "$1_noorder" "$2_noorder"`, I guess.
Yes, thanks for pointing it out!
--
To unsubscribe from this list: send t
-off-by: Tom RUSSELLO
Signed-off-by: Samuel GROOT
Signed-off-by: Matthieu MOY
---
Documentation/git-send-email.txt | 8
git-send-email.perl | 81 ++--
t/t9001-send-email.sh| 32
3 files changed, 117 insertions
Take an email message file, parse it and fill the "From", "To", "Cc",
"In-reply-to", "References" fields appropriately.
If `--compose` option is set, it will also fill the subject field with
`Re: ['s subject]` in the introductory message.
S
Check if the given utf-8 email address is in the Cc: field.
Signed-off-by: Tom RUSSELLO
Signed-off-by: Samuel GROOT
Signed-off-by: Matthieu MOY
---
t/t9001-send-email.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index
We need a simple and generic way to parse an email file.
Since it would be hard to include and maintain an external library,
create an simple email parser subroutine to parse an email file.
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by: Matthieu MOY
---
We chose to
Messages displayed by `send-email` should be shortened to avoid displaying
unnecessary information.
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by: Matthieu MOY
---
git-send-email.perl | 22 +--
t/t9001-send-email.sh | 58
Tests might fail if lines compared in text files don't have the same
order.
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by: Matthieu MOY
---
t/t9001-send-email.sh | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/t/t9001-send-email
The purpose of this series of patches is to implement a new
"quote-email" feature integrated in the current `--in-reply-to` option.
* The first 2 patches make the tests less dependent to
`git send-email`'s exact output.
* Third patch makes `git send-email` a bit less verbose.
* Fourth pa
On 06/08/2016 10:36 AM, Eric Wong wrote:
Tom Russello wrote:
Messages displayed by `send-email` should be shortened to avoid displaying
unnecesseray informations.
unnecessary information.
In some of your other patches, the 'grep' can probably
be better replaced by 'fgrep' for fixed strings.
On 06/08/2016 03:07 AM, Junio C Hamano wrote:
I am having a hard time guessing what prompted you to sort the
output, i.e. what problem you were trying to solve. It cannot be
because addresses on a list (e.g. Cc:) could come out in an
indeterministic order, because the address that a test expects
On 05/29/2016 01:33 AM, Eric Wong wrote:
Matthieu Moy wrote:
Samuel GROOT writes:
Parsing and processing in send-email is done in the same loop.
To make the code more maintainable, we create two subroutines:
- `parse_email` to separate header and body
- `parse_header` to retrieve data from
On 05/30/2016 04:20 PM, Matthieu Moy wrote:
Is the "lots of email" format still used?
AFAICT, it was initially supported for backward compatibility, and then
no one removed it, but I wouldn't be surprised if no one actually used
it.
I vaguely remember a message from Ryan Anderson being surpris
On 05/29/2016 08:05 PM, Matthieu Moy wrote:
Samuel GROOT writes:
Should we take what Eric suggested (see below) as standard output?
Since the headers are already shown after those lines, it's
redundant to have the entire line. And we could add
trailers after the headers (with a blank
On 05/29/2016 07:53 PM, Matthieu Moy wrote:
Samuel GROOT writes:
So should we merge parse_email and parse_header in one unique
subroutine?
At least on the user (i.e. caller of the API) side, one function is
probably enough.
I will do that, as soon as we decide what's best be
On 05/28/2016 05:04 PM, Matthieu Moy wrote:
Eric Wong writes:
Samuel GROOT wrote:
(mbox) Adding cc: A from line 'Cc: A,
One'
(mbox) Adding cc: One from line 'Cc: A,
One'
Though `git send-email` now outputs something like:
(mbox) Adding cc: A from li
On 05/29/2016 01:33 AM, Eric Wong wrote:
Matthieu Moy wrote:
Samuel GROOT writes:
Parsing and processing in send-email is done in the same loop.
To make the code more maintainable, we create two subroutines:
- `parse_email` to separate header and body
- `parse_header` to retrieve data from
While working on the new option `quote-email`, we needed to parse an
email file. Since the work is already done, but the parsing and data
processing are in the same loop, we wanted to refactor the parser, to
make the code more maintainable.
This is still WIP, and one of the main issue (and we need
Parsing and processing in send-email is done in the same loop.
To make the code more maintainable, we create two subroutines:
- `parse_email` to separate header and body
- `parse_header` to retrieve data from header
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by
Use the two subroutines `parse_email` and `parse_header` introduced in
previous commit to parse patches.
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by: Matthieu MOY
---
git-send-email.perl | 179 +---
1 file changed, 59
On 05/25/2016 08:31 PM, Matthieu Moy wrote:
So, a possible UI would be:
git send-email --in-reply-to= => just set In-Reply-To: field.
git send-email --in-reply-to= => set In-Reply-To, To and Cc.
git send-email --in-reply-to= --cite => in addition, add the
body of the message quoted w
On 05/23/2016 10:00 PM, Matthieu Moy wrote:
I don't think this is right: I often reply to an email with a single
patch, for which it would clearly be overkill to have a cover-letter.
Yes indeed, we are working on inserting the quoted message body in the
patch's "below-triple-dash" section.
On 05/23/2016 09:55 PM, Eric Wong wrote:
Tom Russello wrote:
This new option takes an email message file, parses it, fills the "To",
"Subject" and "Cc" fields appropriately and quote the message.
This option involves the `--compose` mode to edit the cover letter quoting the
given email.
Coo
On 05/23/2016 10:07 PM, Matthieu Moy wrote:
Eric Wong writes:
Tom Russello wrote:
+ #Message body
+ while (<$fh>) {
+ #for files containing crlf line endings
+ $_=~ s/\r//g;
+ my $space="";
+ if (/^[^>]/) {
+
On 05/23/2016 09:38 PM, Matthieu Moy wrote:
Tom Russello writes:
Hello,
With the current send-email command, you can send a series of patches "in reply
to" an email.
This patch adds a new option to `git send-email`, `--quote-mail=`, to
I think the option name should be --quote-email. Even
Some people have suggested to standardize documentation's formatting to
make it more consistent.
[1] 2015-04-29 20:13:53 GMT, Junio C Hamano wrote:
Interesting. What I happen to use when populating the git-manpages
repository would have wider impact to the users, as I hear that some
(or many)
45 matches
Mail list logo
