Re: [PATCH v4 6/6] send-email: add option --cite to quote the message body

On 06/09/2016 01:49 PM, Matthieu Moy wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> 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

Re: [PATCH v4 5/6] send-email: --in-reply-to= populate header fields

On 06/09/2016 11:45 AM, Matthieu Moy wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> 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-ema

Re: [PATCH v4 5/6] send-email: --in-reply-to= populate header fields

On 06/08/2016 08:23 PM, Junio C Hamano wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> 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 t

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/14/2016 12:47 AM, Eric Wong wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> wrote: On 06/09/2016 02:21 AM, Eric Wong wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> wrote: Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1]. Should we handle \n\r at

Re: [PATCH v3 2/6] t9001: check email address is in Cc: field

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

Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison

On 06/09/2016 08:01 AM, Matthieu Moy wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> writes: On 06/08/2016 06:09 PM, Junio C Hamano wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> writes: Actually we had issues when trying to refactor send-email's email parsing loo

Re: [PATCH v4 3/6] send-email: shorten send-email's output

On 06/09/2016 08:17 AM, Matthieu Moy wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> 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.pat

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/09/2016 02:21 AM, Eric Wong wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> 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 fil

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/09/2016 08:51 AM, Eric Sunshine wrote: On Wed, Jun 8, 2016 at 7:54 PM, Samuel GROOT <samuel.gr...@grenoble-inp.org> wrote: On 06/08/2016 10:17 PM, Junio C Hamano wrote: Eric Sunshine <sunsh...@sunshineco.com> writes: An embedded CR probably shouldn't happen, but I'm n

Re: [PATCH v4 4/6] send-email: create email parser subroutine

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

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/08/2016 09:31 PM, Junio C Hamano wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> 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 subr

Re: [PATCH v4 3/6] send-email: shorten send-email's output

On 06/08/2016 09:33 PM, Junio C Hamano wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> writes: On 06/08/2016 07:37 PM, Junio C Hamano wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> writes: + printf("Adding cc: %s fr

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/08/2016 07:58 PM, Junio C Hamano wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> writes: +sub parse_email { + my %mail = (); + my $fh = shift; + my $last_header; + # Unfold and parse multiline header fields + while (<$fh>) { +

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/08/2016 08:12 PM, Eric Sunshine wrote: On Wed, Jun 8, 2016 at 1:58 PM, Junio C Hamano <gits...@pobox.com> wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> writes: +sub parse_email { + my %mail = (); + my $fh = shift; + my $last_header; + # Unfold and par

Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison

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

Re: [PATCH v4 4/6] send-email: create email parser subroutine

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

Re: [PATCH v4 2/6] t9001: check email address is in Cc: field

On 06/08/2016 07:34 PM, Junio C Hamano wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> 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 $

Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison

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

Re: [PATCH v4 3/6] send-email: shorten send-email's output

On 06/08/2016 07:37 PM, Junio C Hamano wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> writes: + printf("Adding cc: %s from From: header\n", + $1) unless $quiet; +

Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison

On 06/08/2016 06:09 PM, Junio C Hamano wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> 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 referenc

Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison

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

[PATCH v4 6/6] send-email: add option --cite to quote the message body

-off-by: Tom RUSSELLO <tom.russe...@grenoble-inp.org> Signed-off-by: Samuel GROOT <samuel.gr...@grenoble-inp.org> Signed-off-by: Matthieu MOY <matthieu@grenoble-inp.fr> --- Documentation/git-send-email.txt | 8 git-send-email.perl

[PATCH v4 5/6] send-email: --in-reply-to= populate header fields

Signed-off-by: Tom RUSSELLO <tom.russe...@grenoble-inp.org> Signed-off-by: Samuel GROOT <samuel.gr...@grenoble-inp.org> Signed-off-by: Matthieu MOY <matthieu@grenoble-inp.fr> --- Documentation/git-send-email.txt | 9 +++-- git-send-email.perl

[PATCH v4 2/6] t9001: check email address is in Cc: field

Check if the given utf-8 email address is in the Cc: field. Signed-off-by: Tom RUSSELLO <tom.russe...@grenoble-inp.org> Signed-off-by: Samuel GROOT <samuel.gr...@grenoble-inp.org> Signed-off-by: Matthieu MOY <matthieu@grenoble-inp.fr> --- t/t9001-send-email.sh | 4 ++--

[PATCH v4 4/6] send-email: create email parser subroutine

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 <samuel.gr...@grenoble-inp.org> Signed-off-by: Tom RUSSELLO <

[PATCH v4 3/6] send-email: shorten send-email's output

Messages displayed by `send-email` should be shortened to avoid displaying unnecessary information. Signed-off-by: Samuel GROOT <samuel.gr...@grenoble-inp.org> Signed-off-by: Tom RUSSELLO <tom.russe...@grenoble-inp.org> Signed-off-by: Matthieu MOY <matthieu@grenoble-inp.fr

[PATCH v4 1/6] t9001: non order-sensitive file comparison

Tests might fail if lines compared in text files don't have the same order. Signed-off-by: Samuel GROOT <samuel.gr...@grenoble-inp.org> Signed-off-by: Tom RUSSELLO <tom.russe...@grenoble-inp.org> Signed-off-by: Matthieu MOY <matthieu@grenoble-inp.fr> --- t/t9001-

[no subject]

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

Re: [PATCH v3 3/6] t9001: shorten send-email's output

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

Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison

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

Re: [WIP-PATCH 0/2] send-email: refactor the email parser loop

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

Re: [WIP-PATCH 0/2] send-email: refactor the email parser loop

On 05/29/2016 08:05 PM, Matthieu Moy wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> 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

Re: [WIP-PATCH 1/2] send-email: create email parser subroutine

On 05/29/2016 07:53 PM, Matthieu Moy wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> 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

Re: [WIP-PATCH 0/2] send-email: refactor the email parser loop

On 05/28/2016 05:04 PM, Matthieu Moy wrote: Eric Wong <e...@80x24.org> writes: Samuel GROOT <samuel.gr...@grenoble-inp.org> wrote: (mbox) Adding cc: A<aut...@example.com> from line 'Cc: A<aut...@example.com>, One<o...@example.com>' (mbox) Adding cc: On

Re: [WIP-PATCH 1/2] send-email: create email parser subroutine

On 05/29/2016 01:33 AM, Eric Wong wrote: Matthieu Moy <matthieu@grenoble-inp.fr> wrote: Samuel GROOT <samuel.gr...@grenoble-inp.org> writes: Parsing and processing in send-email is done in the same loop. To make the code more maintainable, we create two subroutines: -

[WIP-PATCH 0/2] send-email: refactor the email parser loop

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

[WIP-PATCH 1/2] send-email: create email parser subroutine

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 <samuel.gr...@grenoble-inp.org> Signed-off-b

[WIP-PATCH 2/2] send-email: use refactored subroutine to parse patches

Use the two subroutines `parse_email` and `parse_header` introduced in previous commit to parse patches. Signed-off-by: Samuel GROOT <samuel.gr...@grenoble-inp.org> Signed-off-by: Tom RUSSELLO <tom.russe...@grenoble-inp.org> Signed-off-by: Matthieu MOY <matthieu@grenoble-inp.fr

Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to

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

Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to

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.

Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to

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

Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to

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

Re: [RFC-PATCH 0/2] send-email: new --quote-mail option

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

Re: [RFC/PATCH] Formatting variables in the documentation

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)