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
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
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
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
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
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
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
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
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
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
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
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
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>) {
+
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
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
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
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 $
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
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;
+
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
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
-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
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
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 ++--
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 <
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
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-
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
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
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
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
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
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
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
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:
-
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
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
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
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
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
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
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
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)
44 matches
Mail list logo