* mt/send-email-cover-to-cc:
t9001: avoid non-portable '\n' with sed
test/send-email: to-cover, cc-cover tests
git-send-email: two new options: to-cover, cc-cover
Allow extracting To/Cc addresses from the first patch
(typically the cover letter), and use them as To/Cc addresses of the
remainder of the series.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When initiating an SSL connection without explicitly specifying the
SSL certificate verification mode, Net::SMTP::SSL defaults to no
verification, but recent versions of the module gives a warning
against this use of the default.
Enable certificate verification by default, using /etc/ssl/certs as
the default path for certificates of certificate authorities. This
path can be overriden by the --smtp-ssl-cert-path command line
option and the sendemail.smtpSSLCertPath configuration variable.
Passing an empty string as the path for CA certificates path disables
the SSL certificate verification explicitly, which does not trigger
the warning from recent versions of Net::SMTP::SSL.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Helped-by: Brian M. Carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some people always do --annotate, lets not force them to always type
that.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If smtp_user is provided but smtp_pass is not, instead of
prompting for password, make git-send-email use git
credential command instead.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the earlier days, we used to spell the name of the system as GIT,
to simulate as if it were typeset with capital G and IT in small
caps. Later we stopped doing so at around 1.6.5 days.
Let's stop doing so throughout the documentation. The name to refer
to the whole system (and the concept it embodies) is "Git"; the
command end-users type is "git". And document this in the coding
guideline.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The introduction email (--compose option) have encoding hardcoded to
UTF-8, but invoked editor may not use UTF-8 encoding.
The encoding used by patches can be changed by the "8bit-encoding"
option, but this option does not have effect on introduction email
and equivalent for introduction email is missing.
Added compose-encoding command line option and sendemail.composeencoding
configuration option specify encoding of introduction email.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option was already shown in -h output, so it should be documented
in the man page.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Suggested-by: David A. Greene <greened@obbligato.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The SYNOPSIS sections of most commands that span several lines already
use [verse] to retain line breaks. Most commands that don't span
several lines seem not to use [verse]. In the HTML output, [verse]
does not only preserve line breaks, but also makes the section
indented, which causes a slight inconsistency between commands that
use [verse] and those that don't. Use [verse] in all SYNOPSIS sections
for consistency.
Also remove the blank lines from git-fetch.txt and git-rebase.txt to
align with the other man pages. In the case of git-rebase.txt, which
already uses [verse], the blank line makes the [verse] not apply to
the last line, so removing the blank line also makes the formatting
within the document more consistent.
While at it, add single quotes to 'git cvsimport' for consistency with
other commands.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The hints in SubmittingPatches about stopping GMail from clobbering
patches are widely useful both as examples of "git send-email" and
"git imap-send" usage.
Move the documentation to the appropriate places.
While at it, don't encourage storing passwords in config files.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The point of these sections is generally to:
1. Give credit where it is due.
2. Give the reader an idea of where to ask questions or
file bug reports.
But they don't do a good job of either case. For (1), they
are out of date and incomplete. A much more accurate answer
can be gotten through shortlog or blame. For (2), the
correct contact point is generally git@vger, and even if you
wanted to cc the contact point, the out-of-date and
incomplete fields mean you're likely sending to somebody
useless.
So let's drop the fields entirely from all manpages except
git(1) itself. We already point people to the mailing list
for bug reports there, and we can update the Authors section
to give credit to the major contributors and point to
shortlog and blame for more information.
Each page has a "This is part of git" footer, so people can
follow that to the main git manpage.
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>
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>
The new command line parameter --smtp-server-option or default
configuration sendemail.smtpserveroption can be used to pass
specific options to the SMTP server. Update the documentation
accordingly.
Signed-off-by: Pascal Obry <pascal@obry.net>
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>
The way the code stored --smtp-domain was unlike its handling of other
similar options. Bring it in line with the others by:
- Renaming $mail_domain to $smtp_domain to match the command line
option. Also move its declaration from near the top of the file to
near other option variables.
- Removing $mail_domain_default. The variable was used once and only
served to move the default away from where it gets used.
- Adding a sendemail.smtpdomain config option. smtp-domain was the
only SMTP configuration option that couldn't be set in the user's
.gitconfig.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.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>
Use the new "git var GIT_EDITOR" feature to decide what editor to
use, instead of duplicating its logic elsewhere. This should make
the behavior of commands in edge cases (e.g., editor names with
spaces) a little more consistent.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In http://article.gmane.org/gmane.comp.version-control.git/109790 I
threatened to announce a change to the default threading style used by
send-email to no-chain-reply-to (i.e. the second and subsequent messages
will all be replies to the first one), unless nobody objected, in 1.6.3.
Nobody objected, as far as I can dig the list archive. But when nothing
happened in 1.6.3 nor 1.6.4, nobody from the camp who complained loudly
that led to the message did not complain either.
So I am guessing that after all nobody cares about this. But 1.7.0 is a
good time to change this, and as I said in the message, I personally think
it is a good change, so here it is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current documentation states that servers typically listen on port
465 and calls this "ssmtp". While it's true that many mail servers use
port 465 for SSL smtp, this is non-standard, and hails from the days
before smtp and submission TLS support, that arrived in RFC2487 and
RFC3207. Port 465 is actually assigned by IANA for unrelated purposes,
and is mostly still used by mail servers today only to support Outlook
Express.
In any case, this patch helps the documentation better reflect both
standards and reality, while still helpfully mentioning ports numbers
that a user may wish to specify.
Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current documentation confuses non-standard SSL smtp port 465 with
submission port 587 (RFC 4406). This patch just changes the referenced
number.
Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This hopefully makes the relationship between threading options of
format-patch and send-email easier to grasp.
Signed-off-by: Yann Dirson <ydirson@altern.org>
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
Also remove the argument from --[no-]chain-reply-to.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-send-email docs do not mention except in the usage lines
the combined patch formatting/sending ability of git-send-email.
This patch expands on the possible arguments to git-send-email
and explains the meaning of the rev-list argument.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mw/send-email:
send-email: Remove superfluous `my $editor = ...'
send-email: 'References:' should only reference what is sent
send-email: Handle "GIT:" rather than "GIT: " during --compose
Docs: send-email: --smtp-server-port can take symbolic ports
Docs: send-email: Refer to CONFIGURATION section for sendemail.multiedit
Docs: send-email: Put options back into alphabetical order
The sender address, as specified with the '--from' command line option,
couldn't be set in the config file. So add a new config option,
'sendemail.from', which sets it. One can use 'sendemail.<identity>.from'
as well of course, which is likely the more useful case.
The sender address would default to GIT_AUTHOR_IDENT, which is usually the
right thing, but this doesn't allow switching based on the identity
selected. It's possible to switch the SMTP server and envelope sender by
using the '--identity' option, in which case one probably wants to use a
different from address as well, but this had to be manually specified.
The documentation for 'from' is also corrected somewhat. If '--from' is
specified (or the new sendemail.from option is used) then the user isn't
prompted. The default with no '--from' option (or sendemail.from option)
is GIT_AUTHOR_IDENT first then GIT_COMMITTER_IDENT, not just
GIT_COMMITTER_IDENT.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
elm stores a text file version of the aliases that is
<alias> = <comment> = <email address>
This adds the parsing of this file to git-send-email
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace description of sendemail.multiedit in --annotate docs
with a reference to the CONFIGURATION section.
Add such a reference to the --compose documentation.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/send-email:
send-email: add --confirm option and configuration setting
send-email: don't create temporary compose file until it is needed
send-email: --suppress-cc improvements
send-email: handle multiple Cc addresses when reading mbox message
send-email: allow send-email to run outside a repo
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>
