path: root/Documentation/git-send-email.txt
AgeCommit message (Collapse)Author
2011-03-11doc: drop author/documentation sections from most pagesJeff King
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-11Merge branch 'maint'Junio C Hamano
2010-12-10Add --force to git-send-email documentationAlejandro R. Sedeño
Signed-off-by: Alejandro R. Sedeño <> Signed-off-by: Junio C Hamano <>
2010-11-12git-send-email.perl: make initial In-Reply-To apply only to first emailAntonio Ospite
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 <> Signed-off-by: Junio C Hamano <>
2010-10-27Merge branch 'jp/send-email-to-cmd'Junio C Hamano
* 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-cmdJoe Perches
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 <> Signed-off-by: Junio C Hamano <>
2010-09-07New send-email option smtpserveroption.Pascal Obry
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 <> Signed-off-by: Junio C Hamano <>
2010-06-27Merge branch 'tr/send-email-8bit'Junio C Hamano
* tr/send-email-8bit: send-email: ask about and declare 8bit mails
2010-06-18send-email: ask about and declare 8bit mailsThomas Rast
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 <> Signed-off-by: Junio C Hamano <>
2010-05-09Merge branch 'bg/send-email-smtpdomain'Junio C Hamano
* 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"Ping Yin
Signed-off-by: Ping Yin <> Acked by: Sverre Rabbelier <> Signed-off-by: Junio C Hamano <>
2010-04-10send-email: Cleanup smtp-domain and add configBrian Gernhardt
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 <> Signed-off-by: Junio C Hamano <>
2010-04-10Document send-email --smtp-domainBrian Gernhardt
Signed-off-by: Brian Gernhardt <> Signed-off-by: Junio C Hamano <>
2009-12-26Merge branch 'jc/1.7.0-send-email-no-thread-default'Junio C Hamano
* 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'Junio C Hamano
2009-11-28send-email: automatic envelope senderFelipe Contreras
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 <> Signed-off-by: Junio C Hamano <>
2009-11-13add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"Jonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>
2009-08-23send-email: make --no-chain-reply-to the defaultJunio C Hamano
In 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 <>
2009-07-31Documentation: git-send-email: correct statement about standard portsWesley J. Landaker
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 <> Signed-off-by: Junio C Hamano <>
2009-07-31Documentation: git-send-email: fix submission port numberWesley J. Landaker
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 <> Signed-off-by: Junio C Hamano <>
2009-07-23Improve doc for format-patch threading options.Yann Dirson
This hopefully makes the relationship between threading options of format-patch and send-email easier to grasp. Signed-off-by: Yann Dirson <> Signed-off-by: Junio C Hamano <>
2009-06-18Test cccmd in and fix some bugsPaolo Bonzini
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 <> Cc: Markus Heidelberg <> Signed-off-by: Junio C Hamano <>
2009-06-12Merge branch 'mh/maint-fix-send-email-threaded' into mh/fix-send-email-threadedJunio C Hamano
* 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/
2009-06-12doc/send-email: clarify the behavior of --in-reply-to with --no-threadMarkus Heidelberg
Also remove the argument from --[no-]chain-reply-to. Signed-off-by: Markus Heidelberg <> Signed-off-by: Junio C Hamano <>
2009-06-12Merge branch 'maint'Junio C Hamano
* maint: Documentation: git-send-mail can take rev-list arg to drive format-patch rebase--interactive: remote stray closing parenthesis
2009-06-12Documentation: git-send-mail can take rev-list arg to drive format-patchPaolo Bonzini
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 <> Signed-off-by: Junio C Hamano <>
2009-05-31Merge branch 'mw/send-email'Junio C Hamano
* 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-14send-email: Add config option for sender addressTrent Piepho
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 <> Signed-off-by: Junio C Hamano <>
2009-04-23Add parsing of elm aliases to git-send-emailBill Pemberton
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 <> Signed-off-by: Junio C Hamano <>
2009-04-14Docs: send-email: --smtp-server-port can take symbolic portsMichael Witten
Signed-off-by: Michael Witten <> Signed-off-by: Junio C Hamano <>
2009-04-14Docs: send-email: Refer to CONFIGURATION section for sendemail.multieditMichael Witten
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 <> Signed-off-by: Junio C Hamano <>
2009-04-14Docs: send-email: Put options back into alphabetical orderMichael Witten
Signed-off-by: Michael Witten <> Signed-off-by: Junio C Hamano <>
2009-04-08git-send-email.txt: clarify which options take an argument.Matthieu Moy
Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2009-03-17git-send-email.txt: describe --compose betterStephen Boyd
Signed-off-by: Stephen Boyd <> Signed-off-by: Junio C Hamano <>
2009-03-05Merge branch 'js/send-email'Junio C Hamano
* 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-03send-email: add --confirm option and configuration settingJay Soffian
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 <> Signed-off-by: Junio C Hamano <>
2009-02-19Documentation: Note file formats send-email acceptsTodd Zullinger
Signed-off-by: Todd Zullinger <> Signed-off-by: Junio C Hamano <>
2009-02-15send-email: --suppress-cc improvementsJay Soffian
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 <> Signed-off-by: Junio C Hamano <>
2009-01-12Merge branch 'mh/maint-sendmail-cc-doc' into maintJunio C Hamano
* mh/maint-sendmail-cc-doc: doc/git-send-email: mention config variable
2009-01-07Merge branch 'mh/maint-sendmail-cc-doc'Junio C Hamano
* mh/maint-sendmail-cc-doc: doc/git-send-email: mention config variable
2008-12-29doc/git-send-email: mention config variableMarkus Heidelberg
This variable was added in 5f8b9fc (git-send-email: add a new configuration variable, 2008-04-27), but is not yet refered to by the documentation. Signed-off-by: Markus Heidelberg <> Signed-off-by: Junio C Hamano <>
2008-12-27git-send-email.txt: move --format-patch paragraph to a proper locationAdeodato Simó
When introducing --format-patch, its documentation was accidentally inserted in the middle of documentation for --validate. Signed-off-by: Adeodato Simó <> Signed-off-by: Junio C Hamano <>
2008-12-10Fix typos in documentationAlexander Potashev
Signed-off-by: Alexander Potashev <> Signed-off-by: Junio C Hamano <>
2008-11-12git send-email: ask less questions when --compose is used.Pierre Habouzit
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 <> Signed-off-by: Junio C Hamano <>
2008-11-12git send-email: add --annotate optionPierre Habouzit
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 <> Signed-off-by: Junio C Hamano <>
2008-11-12git send-email: interpret unknown files as revision listsPierre Habouzit
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 <> Signed-off-by: Junio C Hamano <>
2008-10-01send-email: signedoffcc -> signedoffbycc, but handle bothMichael Witten
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 <> Acked-by: Jeff King <> Signed-off-by: Shawn O. Pearce <>
2008-10-01Docs: send-email: Create logical groupings for man textMichael Witten
The options are partitioned into more digestible groups. Within these groups, the options are sorted alphabetically. Signed-off-by: Michael Witten <> Acked-by: Jeff King <> Signed-off-by: Shawn O. Pearce <>
2008-10-01Docs: send-email: Remove unnecessary config variable descriptionMichael Witten
The config variables are mentioned within the descriptions of the command line options with which they are associated. Signed-off-by: Michael Witten <> Acked-by: Jeff King <> Signed-off-by: Shawn O. Pearce <>
2008-10-01Docs: send-email: --chain_reply_to -> --[no-]chain-reply-toMichael Witten
Signed-off-by: Michael Witten <> Acked-by: Jeff King <> Signed-off-by: Shawn O. Pearce <>