summaryrefslogtreecommitdiff
path: root/git-send-email.perl
AgeCommit message (Collapse)AuthorFilesLines
2009-09-25send-email: fix obscure error when encryption=tls and smtp cannot connectLibravatar Yakov Lerner1-1/+1
When encryption=tls and we cannot connect to the SMTP server, git-send-email was printing an obtuse perl error: Can't call method "command" on an undefined value at git-send-email line 927. This can occur when smtp host or port is misspelled, or the network is down, and encryption has been set to tls. Instead we expect some familiar "Cannot connect to SERVER:PORT" message. Fix it to print normal "smtp can't connect" diagnostics. Signed-off-by: Yakov Lerner <iler.ml@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-08-05Merge branch 'maint-1.6.3' into maintLibravatar Junio C Hamano1-1/+0
* maint-1.6.3: Better usage string for reflog. hg-to-git: don't import the unused popen2 module send-email: remove debug trace config: Keep inner whitespace verbatim
2009-08-04send-email: remove debug traceLibravatar Erik Faye-Lund1-1/+0
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
2009-07-25Merge branch 'jk/maint-send-email-alias-loop'Libravatar Junio C Hamano1-7/+11
* jk/maint-send-email-alias-loop: send-email: detect cycles in alias expansion
2009-07-24send-email: detect cycles in alias expansionLibravatar Jeff King1-7/+11
With the previous code, an alias cycle like: $ echo 'alias a b' >aliases $ echo 'alias b a' >aliases $ git config sendemail.aliasesfile aliases $ git config sendemail.aliasfiletype mutt would put send-email into an infinite loop. This patch detects the situation and complains to the user. Signed-off-by: Jeff King <peff@peff.net> 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-1/+1
* 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-12send-email: fix a typo in a commentLibravatar Markus Heidelberg1-1/+1
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-12send-email: fix threaded mails without chain-reply-toLibravatar Markus Heidelberg1-1/+2
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>
2009-06-12send-email: fix non-threaded mailsLibravatar Markus Heidelberg1-1/+2
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>
2009-06-09send-email: use UTF-8 rather than utf-8 for consistencyLibravatar Brandon Casey1-2/+2
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>
2009-06-09git-send-email.perl: improve detection of MIME encoded-wordsLibravatar Brandon Casey1-1/+9
According to rfc2047, an encoded word has the following form: encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" charset = token encoding = token token = <Any CHAR except SPACE, CTLs, and especials> especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = <Any printable ASCII character other than "?" or SPACE> And rfc822 defines CHARs and CTLs as: CHAR = <any ASCII character> ; ( 0-177, 0.-127.) CTL = <any ASCII control ; ( 0- 37, 0.- 31.) character and DEL> ; ( 177, 127.) The original code only detected rfc2047 encoded strings when the charset was UTF-8. This patch generalizes the matching expression and breaks the check for an rfc2047 encoded string into its own function. There's no real functional change, since any properly rfc2047 encoded string would have fallen through the remaining 'if' statements and been returned unchanged. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-31Merge branch 'mw/send-email'Libravatar Junio C Hamano1-8/+12
* 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-23Merge branch 'tp/send-email-from-config'Libravatar Junio C Hamano1-0/+1
* tp/send-email-from-config: send-email: Add config option for sender address
2009-05-21git-send-email: Handle quotes when parsing .mailrc filesLibravatar Eric W. Biederman1-1/+1
It is legal and not uncommon to use quotes in a .mailrc file so you can include a persons fullname as well as their email alias. Handle this by using quotewords instead of split when parsing .mailrc files. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-13send-email: Add config option for sender addressLibravatar Trent Piepho1-0/+1
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-0/+8
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-14send-email: Remove superfluous `my $editor = ...'Libravatar Michael Witten1-2/+0
Not only was it a repeat, but it also had no effect. Signed-off-by: Michael Witten <mfwitten@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-14send-email: 'References:' should only reference what is sentLibravatar Michael Witten1-4/+10
If someone responded with a negative (n|no) to the confirmation, then the Message-ID of the discarded email is no longer used in the References: header of subsequent emails. Consequently, send_message() now returns 1 if the message was sent and 0 otherwise. Signed-off-by: Michael Witten <mfwitten@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-14send-email: Handle "GIT:" rather than "GIT: " during --composeLibravatar Michael Witten1-2/+2
This should make things a little more robust in terms of user input; before, even the program got it wrong by outputting a line with only "GIT:", which was left in place as a header, because there would be no following space character. Signed-off-by: Michael Witten <mfwitten@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-04send-email: fix nasty bug in ask() functionLibravatar Jay Soffian1-2/+2
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>
2009-04-02send-email: ensure quoted addresses are rfc2047 encodedLibravatar Jay Soffian1-1/+2
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>
2009-04-01send-email: ask_default should apply to all emails, not just the firstLibravatar Jay Soffian1-2/+1
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>
2009-04-01send-email: don't attempt to prompt if tty is closedLibravatar Jay Soffian1-0/+3
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>
2009-03-29send-email: refactor and ensure prompting doesn't loop foreverLibravatar Jay Soffian1-32/+34
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>
2009-03-17Merge branch 'tr/maint-1.6.0-send-email-irt'Libravatar Junio C Hamano1-1/+1
* tr/maint-1.6.0-send-email-irt: send-email: test --no-thread --in-reply-to combination send-email: respect in-reply-to regardless of threading Conflicts: t/t9001-send-email.sh
2009-03-02send-email: add --confirm option and configuration settingLibravatar Jay Soffian1-23/+61
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-03-02send-email: respect in-reply-to regardless of threadingLibravatar Thomas Rast1-1/+1
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>
2009-02-23send-email: don't create temporary compose file until it is neededLibravatar Jay Soffian1-9/+11
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>
2009-02-14send-email: --suppress-cc improvementsLibravatar Jay Soffian1-9/+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-02-14send-email: handle multiple Cc addresses when reading mbox messageLibravatar Jay Soffian1-67/+86
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>
2009-02-14send-email: allow send-email to run outside a repoLibravatar Jay Soffian1-2/+11
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>
2008-12-21send-email: futureproof split_addrs() subLibravatar Junio C Hamano1-1/+1
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>
2008-12-19Merge branch 'maint' to sync with GIT 1.6.0.6Libravatar Junio C Hamano1-3/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-19git-send-email: handle email address with quoted commaLibravatar Wu Fengguang1-3/+8
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>
2008-11-30send-email: do not reverse the command line argumentsLibravatar Junio C Hamano1-1/+1
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>
2008-11-27Merge branch 'ph/send-email'Libravatar Junio C Hamano1-74/+172
* 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.
2008-11-26send-email: Fix Pine address book parsingLibravatar Trent Piepho1-3/+6
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>
2008-11-11git send-email: ask less questions when --compose is used.Libravatar Pierre Habouzit1-73/+114
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>
2008-11-11git send-email: add --annotate optionLibravatar Pierre Habouzit1-2/+24
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>
2008-11-11git send-email: interpret unknown files as revision listsLibravatar Pierre Habouzit1-5/+42
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>
2008-11-11git send-email: make the message file name more specific.Libravatar Pierre Habouzit1-3/+1
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>
2008-11-02Merge branch 'maint'Libravatar Junio C Hamano1-2/+1
* 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
2008-11-01git send-email: avoid leaking directory file descriptors.Libravatar Pierre Habouzit1-2/+1
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-01send-email: signedoffcc -> signedoffbycc, but handle bothLibravatar Michael Witten1-4/+5
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>
2008-10-01Docs: send-email: Create logical groupings for --help textLibravatar Michael Witten1-27/+34
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>
2008-10-01send-email: change --no-validate to boolean --[no-]validateLibravatar Michael Witten1-4/+5
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>
2008-10-01Docs: send-email usage text much sexierLibravatar Michael Witten1-68/+26
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>
2008-10-01Docs: send-email's usage text and man page mention same optionsLibravatar Michael Witten1-4/+4
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>
2008-07-25Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Makefile: fix shell quoting tests: propagate $(TAR) down from the toplevel Makefile index-pack.c: correctly initialize appended objects send-email: find body-encoding correctly