When an initial --in-reply-to is supplied, make it apply only to the
first message; --[no-]chain-reply-to setting are honored by second and
subsequent messages; this is also how the git-format-patch option with
the same name behaves.
Moreover, when $initial_reply_to is asked to the user interactively it
is asked as the "Message-ID to be used as In-Reply-To for the _first_
email", this makes the user think that the second and subsequent
patches are not using it but are considered as replies to the first
message or chained according to the --[no-]chain-reply setting.
Look at the v2 series in the illustration to see what the new behavior
ensures:
(before the patch) | (after the patch)
[PATCH 0/2] Here is what I did... | [PATCH 0/2] Here is what I did...
[PATCH 1/2] Clean up and tests | [PATCH 1/2] Clean up and tests
[PATCH 2/2] Implementation | [PATCH 2/2] Implementation
[PATCH v2 0/3] Here is a reroll | [PATCH v2 0/3] Here is a reroll
[PATCH v2 1/3] Clean up | [PATCH v2 1/3] Clean up
[PATCH v2 2/3] New tests | [PATCH v2 2/3] New tests
[PATCH v2 3/3] Implementation | [PATCH v2 3/3] Implementation
This is the typical behaviour we want when we send a series with cover
letter in reply to some discussion, the new patch series should appear
as a separate subtree in the discussion.
Also update the documentation on --in-reply-to to describe the new
behavior.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
1. When --in-reply-to gives $reply_to, the first one becomes a reply to
that message, with or without --chain-reply-to.
2. When --chain-reply-to is in effect, all the messages are strung
together to form a single chain. The first message may be in reply to
the $reply_to given by --in-reply-to command line option (see
previous), or the root of the discussion thread. The second one is a
response to the first one, and the third one is a response to the
second one, etc.
3. When --chain-reply-to is not in effect:
a. When --in-reply-to is used, too, the second and the subsequent ones
become replies to $reply_to. Together with the first rule, all
messages become replies to $reply_to given by --in-reply-to.
b. When --in-reply-to is not used, presumably the second and
subsequent ones become replies to the first one, which would be the
root.
The documentation is reasonably clear about the 1., 2. and 3a. above, I
think, even though I do not think 3b. is clearly specified.
The two tests added by this patch at least documents what happens between
these two options.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ab/send-email-perl:
send-email: extract_valid_address use qr// regexes
send-email: is_rfc2047_quoted use qr// regexes
send-email: use Perl idioms in while loop
send-email: make_message_id use "require" instead of "use"
send-email: send_message die on $!, not $?
send-email: use (?:) instead of () if no match variables are needed
send-email: sanitize_address use qq["foo"], not "\"foo\""
send-email: sanitize_address use $foo, not "$foo"
send-email: use \E***\Q instead of \*\*\*
send-email: cleanup_compose_files doesn't need a prototype
send-email: unique_email_list doesn't need a prototype
send-email: file_declares_8bit_cte doesn't need a prototype
send-email: get_patch_subject doesn't need a prototype
send-email: use lexical filehandles during sending
send-email: use lexical filehandles for $compose
send-email: use lexical filehandle for opendir
Conflicts:
git-send-email.perl
* sb/send-email-use-to-from-input:
send-email: Don't leak To: headers between patches
send-email: Use To: headers in patch files
Conflicts:
git-send-email.perl
* maint:
t/t9001-send-email.sh: fix stderr redirection in 'Invalid In-Reply-To'
Clarify and extend the "git diff" format documentation
git-show-ref.txt: clarify the pattern matching
documentation: git-config minor cleanups
Update test script annotate-tests.sh to handle missing/extra authors
If the first patch in a series has a To: header in the file and the
second patch in the series doesn't the address from the first patch will
be part of the To: addresses in the second patch. Fix this by treating the
to list like the cc list. Have an initial to list come from the command
line, user input and config options. Then build up a to list from each
patch and concatenate the two together before sending the patch. Finally,
reset the list after sending each patch so the To: headers from a patch
don't get used for the next one.
Reported-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change `while(<$fh>) { my $c = $_' to `while(my $c = <$fh>) {', and
use `chomp $c' instead of `$c =~ s/\n$//g;', the two are equivalent in
this case.
I've also changed the --cccmd test so that we test for the stripping
of whitespace at the beginning of the lines returned from the
--cccmd. I think we probably shouldn't do this, but it was there
already so I haven't changed the behavior.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's a minor annoyance when you take the painstaking time to setup To:
headers for each patch in a large series, and then go out to send the
series with git-send-email and watch git ignore the To: headers in the
patch files.
Therefore, always add To: headers from a patch file to the To: headers
for that message. Keep the prompt for the blanket To: header so as to
not break scripts (and user expectations). This means even if a patch
has a To: header, git will prompt for the To: address. Otherwise, we'll
need to introduce interface breakage to either request the header for
each patch missing a To: header or default the header to whatever To:
address is found first (be it in a patch or from user input). Both of
these options don't seem very obvious/useful.
Reported-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Tested-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the ability to use a command line --to-cmd=cmd
to create the list of "To:" addresses.
Used a shared routine for --cc-cmd and --to-cmd.
Did not use IPC::Open2, leaving that for Ævar if
ever he decides to fix the other bugs he might find.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Every so often, someone sends out an unedited cover-letter template.
Add a simple check to send-email that refuses to send if the subject
contains "*** SUBJECT HERE ***", with an option --force to override.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the setup code in t/t9001-send-email.sh to use
test_expect_success. This way it isn't needlessly run in environments
where the test prerequisites aren't met.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change this test to skip test with test prerequisites, and to do setup
work in tests. This improves the skipped statistics on platforms where
the test isn't run.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove the PROG=* assignment from t9001-send-email.sh. It's been there
since v1.4.0-rc1~30 when the test was originally added, but only tests
that source annotate-tests.sh need it, it was seemingly introduced to
this test via copy/paste coding.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ab/tap:
t/README: document more test helpers
t/README: proposed rewording...
t/README: Document the do's and don'ts of tests
t/README: Add a section about skipping tests
t/README: Document test_expect_code
t/README: Document test_external*
t/README: Document the prereq functions, and 3-arg test_*
t/README: Typo: paralell -> parallel
t/README: The trash is in 't/trash directory.$name'
t/t9700/test.pl: don't access private object members, use public access methods
t9700: Use Test::More->builder, not $Test::Builder::Test
tests: Say "pass" rather than "ok" on empty lines for TAP
tests: Skip tests in a way that makes sense under TAP
test-lib: output a newline before "ok" under a TAP harness
test-lib: Make the test_external_* functions TAP-aware
test-lib: Adjust output to be valid TAP format
Supplying backslashed, extended regular expressions to grep is not
portable. Use egrep instead.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SKIP messages are now part of the TAP plan. A TAP harness now knows
why a particular test was skipped and can report that information. The
non-TAP harness built into Git's test-lib did nothing special with
these messages, and is unaffected by these changes.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-send-email passes on an 8bit mail as-is even if it does not
declare a content-type. Because the user can edit email between
format-patch and send-email, such invalid mails are unfortunately not
very hard to come by.
Make git-send-email stop and ask about the encoding to use if it
encounters any such mail. Also provide a configuration setting to
permanently configure an encoding.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's no way to override the sendemail.to, sendemail.cc, and
sendemail.bcc config settings. Add options allowing the user to tell
git to ignore the config settings and take whatever is on the command
line.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using a dollar sign in double quotes isn't portable. Escape them with
a backslash or replace the double quotes with single quotes.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The '--no-chain-reply-to' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-chain-reply-to) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports '--no' as in '--nochain-reply-to'. More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Give a warning message when send-email uses chain-reply-to to thread the
messages because of the current default, not because the user explicitly
asked to, either from the command line or from the configuration.
This way, by the time 1.7.0 switches the default, everybody will be ready.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds the option to specify the envelope sender as "auto" which
would pick the 'from' address. This is good because now we can specify
the address only in one place in $HOME/.gitconfig and change it easily.
[jc: added tests]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some MTAs reject Cc: lines longer than 78 chars.
Avoid this by using the same join as "To:" ",\n\t"
so each subsequent Cc entry is on a new line.
RCPT TO: should have a single entry per line.
see: http://www.ietf.org/rfc/rfc2821.txt
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the shell is not specified using the '#!' notation, then the OS will
use '/bin/sh' to execute the script which may not produce the desired
results. In particular, /bin/sh on Solaris interprets '^' specially which
has an effect on the sed command that this patch touches.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For another patch series I'm working on I needed some tests
for the cc-cmd feature of git-send-email.
This patch adds 3 tests for the feature and for the possibility
to specify --suppress-cc multiple times, and fixes two bugs.
The first bug is that the --suppress-cc option for `cccmd' was
misspelled as `ccmd' in the code. The second bug, which is
actually found only with my other series, is that the argument
to the cccmd is never quoted, so the cccmd would fail with
patch file names containing a space.
A third bug I fix (in the docs) is that the bodycc argument was
actually spelled ccbody in the documentation and bash completion.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Cc: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mh/maint-fix-send-email-threaded:
doc/send-email: clarify the behavior of --in-reply-to with --no-thread
send-email: fix non-threaded mails
add a test for git-send-email for non-threaded mails
Conflicts:
git-send-email.perl
t/t9001-send-email.sh
An earlier commit 15da108 ("send-email: 'References:' should only
reference what is sent", 2009-04-13) broke logic to set up threading
information for the next message by rewriting "!" to "not" without
understanding the precedence rules of the language.
Namely,
! defined $reply_to || length($reply_to) == 0
was changed to
not defined $reply_to || length($reply_to) == 0
which is
not (defined $reply_to || length($reply_to) == 0)
and different from what was intended, which is
(not defined $reply_to) || (length($reply_to) == 0)
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After commit 3e0c4ff (send-email: respect in-reply-to regardless of
threading, 2009-03-01) the variable $thread was only used for prompting
for an "In-Reply-To", but not for controlling whether the "In-Reply-To"
and "References" fields should be written into the email.
Thus these fields were always used beginning with the second mail and it
was not possible to produce non-threaded mails anymore.
However, a later commit 15da108 ("send-email: 'References:' should only
reference what is sent", 2009-04-13) introduced a regression with the
side effect to make non-threaded mails possible again, but only when
--no-chain-reply-to was used.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rest of the git source has been converted to use upper-case character
encoding names to assist older platforms. The charset attribute of MIME
is defined to be case-insensitive, but older platforms may still have an
easier time dealing with upper-case rather than lower-case. So do so for
send-email too.
Update t9001 to handle the changes.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The '--no-thread' option is a Getopt::Long boolean option. The '--no-'
prefix (as in --no-thread) for boolean options is not supported in
Getopt::Long version 2.32 which was released with Perl 5.8.0. This version
only supports '--no' as in '--nothread'. More recent versions of
Getopt::Long, such as version 2.34, support either prefix. So use the older
form in the tests.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These scripts all test git programs that are written in
perl, and thus obviously won't work if NO_PERL is defined.
We pass NO_PERL to the scripts from the building Makefile
via the GIT-BUILD-OPTIONS file.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 6e18251 (send-email: refactor and ensure prompting doesn't loop
forever) introduced an ask function, which unfortunately had a nasty
bug. This caused it not to accept anything but the default reply to the
"Who should the emails appear to be from?" prompt, and nothing but
ctrl-d to the "Who should the emails be sent to?" and "Message-ID to be
used as In-Reply-To for the first email?" prompts.
This commit corrects the issues and adds a test to confirm the fix.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sanitize_address assumes that quoted addresses (e.g., "first last"
<first.last@example.com) do not need rfc2047 encoding, but this is
not always the case.
For example, various places in send-email extract addresses using
parse_address_line. parse_address_line returns the addresses already
quoted (e.g., "first last" <first.last@example.com), but not rfc2047
encoded.
This patch makes sanitize_address stricter about what needs rfc2047
encoding and adds a test demonstrating where I noticed the problem.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit c18f75a (send-email: add tests for refactored prompting, 2009-03-28)
added two tests which went interactive under the dash shell.
This patch corrects the issue, reported by Björn Steinbrink.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 6e18251 made the "Send this email?" prompt assume yes if confirm
= "inform" when it was unable to get a valid response. However, the
"yes" assumption only worked correctly for the first email. This commit
fixes the issue and confirms the fix by modifying the existing test for
the prompt to send multiple emails.
Reported by Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Several old tests were written before test_cmp was introduced, convert
these to test_cmp.
If were are at it, fix the order of the arguments where necessary to
make expected come first, so the command shows how the test result
deviates from the correct output.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3e0c4ff (send-email: respect in-reply-to regardless of threading,
2009-03-01) fixed the handling of the In-Reply-To header when both
--no-thread and --in-reply-to are in effect. Add a test for it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email violates the principle of least surprise by automatically
cc'ing additional recipients without confirming this with the user.
This patch teaches send-email a --confirm option. It takes the
following values:
--confirm=always always confirm before sending
--confirm=never never confirm before sending
--confirm=cc confirm before sending when send-email has
automatically added addresses from the patch to
the Cc list
--confirm=compose confirm before sending the first message when
using --compose. (Needed to maintain backwards
compatibility with existing behavior.)
--confirm=auto 'cc' + 'compose'
If sendemail.confirm is unconfigured, the option defaults to 'compose'
if any suppress-Cc related options have been used, otherwise it defaults
to 'auto'.
Unfortunately, it is impossible to introduce this patch such that it
helps new users without potentially annoying some existing users. We
attempt to mitigate the latter by:
* Allowing the user to set 'git config sendemail.confirm never'
* Allowing the user to say 'all' after the first prompt to not be
prompted on remaining emails during the same invocation.
* Telling the user about the 'sendemail.confirm' setting if it is
unconfigured whenever we prompt due to Cc before sending.
* Only prompting if no --suppress related options have been passed, as
using such an option is likely to indicate an experienced send-email
user.
There is a slight fib in message informing the user of the
sendemail.confirm setting and this is intentional. Setting 'auto'
differs from leaving sendemail.confirm unset in two ways: 1) 'auto'
obviously squelches the informational message; 2) 'auto' prompts when
the Cc list has been expanded even in the presence of a --suppress
related option, where leaving sendemail.confirm unset does not. This is
intentional to keep the message simple, and to avoid adding another
sendemail.confirm value ('auto-except-suppress'?).
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 6564828 (git-send-email: Generalize auto-cc recipient
mechanism., 2007-12-25) we can suppress automatic Cc generation
separately for each of the possible address sources. However,
--suppress-cc=sob suppressed both SOB lines and body (but not header)
Cc lines, contrary to the name.
Change --suppress-cc=sob to mean only SOB lines, and add separate
choices 'bodycc' (body Cc lines) and 'body' (both 'sob' and 'bodycc').
The option --no-signed-off-by-cc now acts like --suppress-cc=sob,
which is not backwards compatible but matches the name of the option.
Also update the documentation and add a few tests.
Original patch by me. Revised by Thomas Rast, who contributed the
documentation and test updates.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git format-patch is given multiple --cc arguments, it generates a
Cc header that looks like:
Cc: first@example.com,
second@example.com,
third@example.com
Before this commit, send-email was unable to handle such a message as it
did not handle folded header lines, nor multiple recipients in a Cc
line.
This patch:
- Unfolds header lines by pre-processing the header before extracting
any of its fields.
- Handles Cc lines with multiple recipients.
- Adds use of Mail::Address if available for splitting Cc line and
the "Who should the emails be sent to?" prompt", with fall back to
existing split_addrs() function.
- Tests the new functionality and adds two tests for detecting whether
"From:" appears correctly in message body when patch author differs
from patch sender.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The loop picks elements from @ARGV one by one, sifts them into arguments
meant for format-patch and the script itself, and pushes them to @files
and @rev_list_opts arrays. Pick elements from @ARGV starting at the
beginning using shift, instead of at the end using pop, as push appends
them to the end of the array.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
