summaryrefslogtreecommitdiff
path: root/Documentation/git-send-email.txt
AgeCommit message (Collapse)AuthorFilesLines
2014-06-20Merge branch 'mt/send-email-cover-to-cc'Libravatar Junio C Hamano1-0/+12
* 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
2014-05-21Documentation: use "command-line" when used as a compound adjective, and fix ↵Libravatar Jason St. John1-3/+3
other minor grammatical issues Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-29git-send-email: two new options: to-cover, cc-coverLibravatar Michael S. Tsirkin1-0/+12
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>
2013-07-18send-email: be explicit with SSL certificate verificationLibravatar Ramkumar Ramachandra1-0/+6
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>
2013-04-07send-email: make annotate configurableLibravatar Felipe Contreras1-2/+3
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>
2013-02-27git-send-email: use git credential to obtain passwordLibravatar Michal Nazarewicz1-2/+2
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>
2013-02-01Documentation: avoid poor-man's small caps GITLibravatar Thomas Ackermann1-1/+1
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>
2012-10-10git-send-email: introduce compose-encodingLibravatar Krzysztof Mazur1-0/+4
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>
2012-02-27send-email: document the --smtp-debug optionLibravatar Zbigniew Jędrzejewski-Szmek1-0/+4
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>
2011-07-06Documentation: use [verse] for SYNOPSIS sectionsLibravatar Martin von Zweigbergk1-0/+1
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>
2011-04-15Documentation: publicize hints for sending patches with GMailLibravatar Jonathan Nieder1-3/+16
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>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-15/+0
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.
2010-12-10Merge branch 'maint'Libravatar Junio C Hamano1-0/+3
2010-12-10Add --force to git-send-email documentationLibravatar Alejandro R. Sedeño1-0/+3
Signed-off-by: Alejandro R. Sedeño <asedeno@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-12git-send-email.perl: make initial In-Reply-To apply only to first emailLibravatar Antonio Ospite1-5/+20
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>
2010-10-26Merge branch 'jp/send-email-to-cmd'Libravatar Junio C Hamano1-1/+7
* jp/send-email-to-cmd: git-send-email.perl: Add --to-cmd Conflicts: git-send-email.perl
2010-09-27git-send-email.perl: Add --to-cmdLibravatar Joe Perches1-1/+7
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>
2010-09-06New send-email option smtpserveroption.Libravatar Pascal Obry1-0/+9
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>
2010-06-27Merge branch 'tr/send-email-8bit'Libravatar Junio C Hamano1-0/+9
* tr/send-email-8bit: send-email: ask about and declare 8bit mails
2010-06-18send-email: ask about and declare 8bit mailsLibravatar Thomas Rast1-0/+9
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>
2010-05-08Merge branch 'bg/send-email-smtpdomain'Libravatar Junio C Hamano1-0/+7
* bg/send-email-smtpdomain: send-email: Cleanup smtp-domain and add config Document send-email --smtp-domain send-email: Don't use FQDNs without a '.' send-email: Cleanup { style
2010-05-04Documentation/git-send-email: Add "Use gmail as the smtp server"Libravatar Ping Yin1-0/+15
Signed-off-by: Ping Yin <pkufranky@gmail.com> Acked by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-10send-email: Cleanup smtp-domain and add configLibravatar Brian Gernhardt1-1/+2
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>
2010-04-10Document send-email --smtp-domainLibravatar Brian Gernhardt1-0/+6
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-26Merge branch 'jc/1.7.0-send-email-no-thread-default'Libravatar Junio C Hamano1-3/+3
* jc/1.7.0-send-email-no-thread-default: send-email: make --no-chain-reply-to the default Conflicts: git-send-email.perl
2009-11-30Merge branch 'fc/send-email-envelope'Libravatar Junio C Hamano1-3/+4
2009-11-27send-email: automatic envelope senderLibravatar Felipe Contreras1-3/+4
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>
2009-11-13add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"Libravatar Jonathan Nieder1-2/+2
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>
2009-08-22send-email: make --no-chain-reply-to the defaultLibravatar Junio C Hamano1-3/+3
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>
2009-07-31Documentation: git-send-email: correct statement about standard portsLibravatar Wesley J. Landaker1-2/+3
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>
2009-07-31Documentation: git-send-email: fix submission port numberLibravatar Wesley J. Landaker1-1/+1
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>
2009-07-22Improve doc for format-patch threading options.Libravatar Yann Dirson1-5/+16
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>
2009-06-18Test cccmd in t9001-send-email.sh and fix some bugsLibravatar Paolo Bonzini1-2/+2
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>
2009-06-12Merge branch 'mh/maint-fix-send-email-threaded' into mh/fix-send-email-threadedLibravatar Junio C Hamano1-2/+3
* 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
2009-06-12doc/send-email: clarify the behavior of --in-reply-to with --no-threadLibravatar Markus Heidelberg1-2/+3
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>
2009-06-11Merge branch 'maint'Libravatar Junio C Hamano1-0/+4
* maint: Documentation: git-send-mail can take rev-list arg to drive format-patch rebase--interactive: remote stray closing parenthesis
2009-06-11Documentation: git-send-mail can take rev-list arg to drive format-patchLibravatar Paolo Bonzini1-0/+4
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>
2009-05-31Merge branch 'mw/send-email'Libravatar Junio C Hamano1-12/+15
* 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
2009-05-13send-email: Add config option for sender addressLibravatar Trent Piepho1-3/+6
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>
2009-04-22Add parsing of elm aliases to git-send-emailLibravatar Bill Pemberton1-1/+1
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>
2009-04-14Docs: send-email: --smtp-server-port can take symbolic portsLibravatar Michael Witten1-1/+3
Signed-off-by: Michael Witten <mfwitten@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-14Docs: send-email: Refer to CONFIGURATION section for sendemail.multieditLibravatar Michael Witten1-3/+4
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>
2009-04-14Docs: send-email: Put options back into alphabetical orderLibravatar Michael Witten1-11/+11
Signed-off-by: Michael Witten <mfwitten@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07git-send-email.txt: clarify which options take an argument.Libravatar Matthieu Moy1-17/+17
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-17git-send-email.txt: describe --compose betterLibravatar Stephen Boyd1-7/+6
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-05Merge branch 'js/send-email'Libravatar Junio C Hamano1-8/+40
* 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
2009-03-02send-email: add --confirm option and configuration settingLibravatar Jay Soffian1-0/+21
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>
2009-02-18Documentation: Note file formats send-email acceptsLibravatar Todd Zullinger1-0/+13
Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-14send-email: --suppress-cc improvementsLibravatar Jay Soffian1-8/+19
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>
2009-01-11Merge branch 'mh/maint-sendmail-cc-doc' into maintLibravatar Junio C Hamano1-0/+1
* mh/maint-sendmail-cc-doc: doc/git-send-email: mention sendemail.cc config variable