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 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>
Attempting to prompt when the tty is closed (typically when running from
cron) is pointless and emits a warning. This patch causes ask() to
return early, squelching the warning.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Several places in send-email prompt for input, and will do so forever
when the input is EOF. This is poor behavior when send-email is run
unattended (say from cron).
This patch refactors the prompting to an ask() function which takes a
prompt, an optional default, and an optional regex to validate the
input. The function returns on EOF, or if a default is provided and the
user simply types return, or if the input passes the validating regex
(which accepts all input by default). The ask() function gives up after
10 tries in case of invalid input.
There are four callers of the function:
1) "Who should the emails appear to be from?" which provides a default
sender. Previously the user would have to type ctrl-d to accept the
default. Now the user can just hit return, or type ctrl-d.
2) "Who should the emails be sent to?". Previously this prompt passed a
second argument ("") to $term->readline() which was ignored. I believe
the intent was to allow the user to just hit return. Now the user
can do so, or type ctrl-d.
3) "Message-ID to be used as In-Reply-To for the first email?".
Previously this prompt passed a second argument (effectively undef) to
$term->readline() which was ignored. I believe the intent was the same
as for (2), to allow the user to just hit return. Now the user can do
so, or type ctrl-d.
4) "Send this email?". Previously this prompt would loop forever until
it got a valid reply. Now it stops prompting on EOF or a valid reply. In
the case where confirm = "inform", it now defaults to "y" on EOF or the
user hitting return, otherwise an invalid reply causes send-email to
terminate.
A followup patch adds tests for the new functionality.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
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>
git-send-email supports the --in-reply-to option even with
--no-thread. However, the code that adds the relevant mail headers
was guarded by a test for --thread.
Remove the test, so that the user's choice is respected.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit eed6ca7 caused a minor regression when it switched to using
tempfile() to generate the temporary compose file. Since tempfile()
creates the file at the time it generates the filename, zero-length
temporary files are being left behind unless --compose is used (in which
case the file is cleaned up).
This patch fixes the regression by not calling tempfile() to generate
the compose filename unless --compose is in use.
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>
send-email is supposed to be able to run from outside a repo. This
ability was broken by commits caf0c3d6 (make the message file name more
specific) and 5df9fcf6 (interpret unknown files as revision lists).
This commit provides a fix for both.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Matt Kraai points out that calling parse_line() assuming that the caller
ever passes only one argument is a bug waiting to happen, and he is
right.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Correctly handle email addresses containing quoted commas, e.g.
"Zhu, Yi" <yi.zhu@intel.com>, "Li, Shaohua" <shaohua.li@intel.com>
The commas inside the double quotes are not separators.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.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>
* ph/send-email:
git send-email: ask less questions when --compose is used.
git send-email: add --annotate option
git send-email: interpret unknown files as revision lists
git send-email: make the message file name more specific.
See: http://www.washington.edu/pine/tech-notes/low-level.html
Entries with a fcc or comment field after the address weren't parsed
correctly.
Continuation lines, identified by leading spaces, were also not handled.
Distribution lists which had ( ) around a list of addresses did not have
the parenthesis removed.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When --compose is used, we can grab the From/Subject/In-Reply-To from the
edited summary, let it be so and don't ask the user silly questions.
The summary templates gets quite revamped, and includes the list of
patches subjects that are going to be sent with this batch.
When having a body full of empty lines, the summary isn't sent. Document
that in the git-send-email manpage fully.
Note: It doesn't deal with To/Cc/Bcc yet.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows to review every patch (and fix various aspects of them, or
comment them) in an editor just before being sent. Combined to the fact
that git send-email can now process revision lists, this makes git
send-email and efficient way to review and send patches interactively.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Filter out all the arguments git-send-email doesn't like to a
git format-patch command, that dumps its content to a safe directory.
Barf when a file/revision conflict occurs, allow it to be overriden
--[no-]format-patch.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This helps editors choosing their syntax hilighting properly.
Also make the file live under the git directory.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Start 1.6.0.4 cycle
add instructions on how to send patches to the mailing list with Gmail
Documentation/gitattributes: Add subsection header for each attribute
git send-email: avoid leaking directory file descriptors.
send-pack: do not send out single-level refs such as refs/stash
fix overlapping memcpy in normalize_absolute_path
pack-objects: avoid reading uninitalized data
correct cache_entry allocation
Conflicts:
RelNotes
The documentation now mentions sendemail.signedoffbycc instead
of sendemail.signedoffcc in order to match with the options
--signed-off-by-cc; the code has been updated to reflect this
as well, but sendemail.signedoffcc is still handled.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The options are partitioned into more digestible groups.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There is also now a configuration variable:
sendemail[.<identity>].validate
Signed-off-by: Michael Witten <mfwitten@mit.edu>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
All of the descriptions are aligned, shorter,
better arranged, and no line is greater than
78 columns.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Specifically, boolean options are now listed in the form
--[no-]option
and both forms of documentation now consistently use
--[no-]signed-off-by-cc
Signed-off-by: Michael Witten <mfwitten@mit.edu>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In 8291db6 (git-send-email: add charset header if we add encoded 'From',
2007-11-16), "$1" is used from a regexp without using () to capture
anything in $1. Later, when that value was used, it causes a warning about
a variable being undefined, instead of using the correct value for
comparison (not that it makes difference in the current code that does not
do actual re-encoding).
Signed-off-by: Peter Valdemar Mørch <peter@morch.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you misuse a git command, you are shown the usage string.
But this is currently shown in the dashed form. So if you just
copy what you see, it will not work, when the dashed form
is no longer supported.
This patch makes git commands show the dash-less version.
For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
generates a dash-less usage string now.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Send HELO again after a successful STARTTLS command to refresh the list of
extensions. These may be different to what is returned over a clear
connection (for example the AUTH command may be accepted over a secure
connection, but not over a clear connection).
Furthermore, this behaviour is recommended by RFC 2487
(http://www.ietf.org/rfc/rfc2487.txt).
Signed-off-by: Robert Shearman <robertshearman@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the previous TLS patch, send-email would attempt to STARTTLS at
the beginning of every mail, despite reusing the last connection. We
simply skip further encryption checks after successful TLS initiation.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the previous patch, not configuring any encryption (either on or
off) would leave $smtp_encryption undefined. We simply set it to the
empty string in that case.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We do this by handing over the Net::SMTP instance to Net::SMTP::SSL,
which avoids Net::SMTP::TLS and its weird error checking. This trick
is due to Brian Evins.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a fifo is given, validation must be skipped because we can't
read the fifo twice. Ideally git-send-email would cache the read
data instead of attempting to read twice, but for now just skip
validation.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When interactively supplying addresses to send an email to with
send-email, whitespace after the separation comma (as in 'list, jc')
wasn't ignored. This meant that resolving of the alias ' jc' would
fail, sending an email only to list. With this patch, the optional
trailing whitespace is ignored.
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/maint-send-email-compose:
send-email: rfc2047-quote subject lines with non-ascii characters
send-email: specify content-type of --compose body
Conflicts:
t/t9001-send-email.sh
Due to 065096c (git-send-email.perl: Handle shell metacharacters in
$EDITOR properly, 2008-05-04) which is a backward incompatible change (but
it makes handling of EDITOR consistent with other parts of the system),
the test script t9001 had to be adjusted.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Need to quote all special characters, not just the first one
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We always use 'utf-8' as the encoding, since we currently
have no way of getting the information from the user.
This also refactors the quoting of recipient names, since
both processes can share the rfc2047 quoting code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the compose message contains non-ascii characters, then
we assume it is in utf-8 and include the appropriate MIME
headers. If the user has already included a MIME-Version
header, then we assume they know what they are doing and
don't add any headers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* bd/tests:
Rename the test trash directory to contain spaces.
Fix tests breaking when checkout path contains shell metacharacters
Don't use the 'export NAME=value' in the test scripts.
lib-git-svn.sh: Fix quoting issues with paths containing shell metacharacters
test-lib.sh: Fix some missing path quoting
Use test_set_editor in t9001-send-email.sh
test-lib.sh: Add a test_set_editor function to safely set $VISUAL
git-send-email.perl: Handle shell metacharacters in $EDITOR properly
config.c: Escape backslashes in section names properly
git-rebase.sh: Fix --merge --abort failures when path contains whitespace
Conflicts:
t/t9115-git-svn-dcommit-funky-renames.sh
This fixes the git-send-perl semantics for launching an editor when
$GIT_EDITOR (or friends) contains shell metacharacters to match
launch_editor() in builtin-tag.c. If we use the current approach
(sh -c '$0 $@' "$EDITOR" files ...), we see it fails when $EDITOR has
shell metacharacters:
$ sh -x -c '$0 $@' "$VISUAL" "foo"
+ "$FAKE_EDITOR" foo
"$FAKE_EDITOR": 1: "$FAKE_EDITOR": not found
Whereas builtin-tag.c will invoke sh -c "$EDITOR \"$@\"".
Thus, this patch changes git-send-email.perl to use the same method as the
C utilities, and additionally updates t/t9001-send-email.sh to test for
this bug.
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some projects prefer to always CC patches to a given mailing list. In
these cases, it's handy to configure that address once.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We might not have some configuration variables available, but if the
user doesn't care about that, neither should we. Still use the
repository if it is available, though.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The logic to countermand suppression of Cc to the signers with a more
explicit --signed-off-by option done in 6564828 (git-send-email:
Generalize auto-cc recipient mechanism) suffers from a double-negation
error.
A --signed-off-cc option, when false, should actively suppress CC: to be
generated out of S-o-b lines, and it should refrain from suppressing when
it is true.
It also fixes "(sob) Adding cc:" status output; earlier it included the
line terminator LF inside '%s', which was totally bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
