summaryrefslogtreecommitdiff
path: root/git-send-email.perl
AgeCommit message (Collapse)AuthorFilesLines
2012-10-25git-send-email: add rfc2047 quoting for "=?"Libravatar Krzysztof Mazur1-1/+1
For raw subjects rfc2047 quoting is needed not only for non-ASCII characters, but also for any possible rfc2047 in it. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: introduce quote_subject()Libravatar Krzysztof Mazur1-6/+19
The quote_rfc2047() always adds RFC2047 quoting. To avoid quoting ASCII subjects, before calling quote_rfc2047() subject must be tested for non-ASCII characters. This patch introduces a new quote_subject() function, which performs the test and calls quote_rfc2047 only if necessary. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: skip RFC2047 quoting for ASCII subjectsLibravatar Krzysztof Mazur1-1/+2
The git-send-email always use RFC2047 subject quoting for files with "broken" encoding - non-ASCII files without Content-Transfer-Encoding, even for ASCII subjects. This is harmless but unnecessarily ugly for people reading the raw headers. This patch skips rfc2047 quoting when the subject does not need it. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: use compose-encoding for SubjectLibravatar Krzysztof Mazur1-4/+4
The commit "git-send-email: introduce compose-encoding" introduced the compose-encoding option to specify the introduction email encoding (--compose option), but the email Subject encoding was still hardcoded to UTF-8. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-10git-send-email: introduce compose-encodingLibravatar Krzysztof Mazur1-1/+8
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-09-12Merge branch 'sb/send-email-reconfirm-fix'Libravatar Junio C Hamano1-2/+4
* sb/send-email-reconfirm-fix: send-email: initial_to and initial_reply_to are both optional
2012-09-06send-email: initial_to and initial_reply_to are both optionalLibravatar Stephen Boyd1-2/+4
We may pick up additional recipients from the format-patch output files we are sending, in which case it is perfectly valid to leave the @initial_to empty when the prompt asks. We may want to start a new discussion thread without replying to anything, and it is valid to leave $initial_reply_to empty. An earlier update to avoid y@example.com stuffed in address fields did not take these two cases into account. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-03Merge branch 'jc/send-email-reconfirm'Libravatar Junio C Hamano1-3/+13
Validate interactive input to "git send-email" to avoid common mistakes such as saying "y<RETURN>" to sender mail address whose prompt is given with a correctly guessed default. * jc/send-email-reconfirm: send-email: validate & reconfirm interactive responses
2012-08-14send-email: validate & reconfirm interactive responsesLibravatar Junio C Hamano1-3/+13
People answer 'y' to "Who should the emails appear to be from?" and 'n' to "Message-ID to be used as In-Reply-To for the first email?" for some unknown reason. While it is possible that your local username really is "y" and you are sending the mail to your local colleagues, it is possible, and some might even say it is likely, that it is a user error. Fortunately, our interactive prompter already has input validation mechanism built-in. Enhance it so that we can optionally reconfirm and allow the user to pass an input that does not validate, and "softly" require input to the sender, in-reply-to, and recipient to contain "@" and "." in this order, which would catch most cases of mistakes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-31send-email: improve RFC2047 quote parsingLibravatar Thomas Rast1-4/+6
The RFC2047 unquoting, used to parse email addresses in From and Cc headers, is broken in several ways: * It erroneously substitutes ' ' for '_' in *the whole* header, even outside the quoted field. [Noticed by Christoph.] * It is too liberal in its matching, and happily matches the start of one quoted chunk against the end of another, or even just something that looks like such an end. [Noticed by Junio.] * It fundamentally cannot cope with encodings that are not a superset of ASCII, nor several (incompatible) encodings in the same header. This patch fixes the first two by doing a more careful decoding of the outer quoting (e.g. "=AB" to represent an octet whose value is 0xAB). Fixing the fundamental issues is left for a future, more intrusive, patch. Noticed-by: Christoph Miebach <christoph.miebach@web.de> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-09send-email: multiedit is a boolean config optionLibravatar Jeff King1-1/+1
The sendemail.multiedit variable is meant to be a boolean. However, it is not marked as such in the code, which means we store its value literally. Thus in the do_edit function, perl ends up coercing it to a boolean value according to perl rules, not git rules. This works for "0", but "false", "no", or "off" will erroneously be interpreted as true. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-18Merge branch 'md/smtp-tls-hello-again'Libravatar Junio C Hamano1-1/+1
* md/smtp-tls-hello-again: send-email: Honour SMTP domain when using TLS
2011-10-15send-email: Honour SMTP domain when using TLSLibravatar Matthew Daley1-1/+1
git-send-email sends two SMTP EHLOs when using TLS encryption, however only the first, unencrypted EHLO uses the SMTP domain that can be optionally specified by the user (--smtp-domain). This is because the call to hello() that produces the second, encrypted EHLO does not pass the SMTP domain as an argument, and hence a default of 'localhost.localdomain' is used instead. Fix by passing in the SMTP domain in this call. Signed-off-by: Matthew Daley <mattjd@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14send-email: Fix %config_path_settings handlingLibravatar Cord Seele1-2/+10
cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) broke the expansion of aliases. This was caused by treating %config_path_settings, newly introduced in said patch, like %config_bool_settings instead of like %config_settings. Copy from %config_settings, making it more readable. While at it add basic test for expansion of aliases, and for path expansion, which would catch this error. Nb. there were a few issues that were responsible for this error: 1. %config_bool_settings and %config_settings despite similar name have different semantic. %config_bool_settings values are arrays where the first element is (reference to) the variable to set, and second element is default value... which admittedly is a bit cryptic. More readable if more verbose option would be to use hash reference, e.g.: my %config_bool_settings = ( "thread" => { variable => \$thread, default => 1}, [...] %config_settings values are either either reference to scalar variable or reference to array. In second case it means that option (or config option) is multi-valued. BTW. this is similar to what Getopt::Long does. 2. In cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) the setting "aliasesfile" was moved from %config_settings to newly introduced %config_path_settings. But the loop that parses settings from %config_path_settings was copy'n'pasted *wrongly* from %config_bool_settings instead of from %config_settings. It looks like cec5dae author cargo-culted this change... 3. 994d6c6 (send-email: address expansion for common mailers, 2006-05-14) didn't add test for alias expansion to t9001-send-email.sh Signed-off-by: Cord Seele <cowose@gmail.com> Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12Merge branch 'cs/perl-config-path-send-email'Libravatar Junio C Hamano1-1/+9
* cs/perl-config-path-send-email: use new Git::config_path() for aliasesfile Add Git::config_path()
2011-10-12Merge branch 'zj/send-email-authen-sasl'Libravatar Junio C Hamano1-0/+6
* zj/send-email-authen-sasl: send-email: auth plain/login fix
2011-09-30use new Git::config_path() for aliasesfileLibravatar Cord Seele1-1/+9
Signed-off-by: Cord Seele <cowose@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-29send-email: auth plain/login fixLibravatar Zbigniew Jędrzejewski-Szmek1-0/+6
git send-email was not authenticating properly when communicating over TLS with a server supporting only AUTH PLAIN and AUTH LOGIN. This is e.g. the standard server setup under debian with exim4 and probably everywhere where system accounts are used. The problem (only?) exists when libauthen-sasl-cyrus-perl (Authen::SASL::Cyrus) is installed. Importing Authen::SASL::Perl makes Authen::SASL use the perl implementation which works better. The solution is based on this forum thread: http://www.perlmonks.org/?node_id=904354. This patch is tested by sending it. Without this fix, the interaction with the server failed like this: $ git send-email --smtp-encryption=tls --smtp-server=... --smtp-debug=1 change1.patch ... Net::SMTP::SSL=GLOB(0x238f668)<<< 250-AUTH LOGIN PLAIN Password: Net::SMTP::SSL=GLOB(0x238f668)>>> AUTH Net::SMTP::SSL=GLOB(0x238f668)<<< 501 5.5.2 AUTH mechanism must be specified 5.5.2 AUTH mechanism must be specified Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-12send-email: add option -hLibravatar Clemens Buchacher1-1/+4
Most other git commands print a synopsis when passed -h. Make send-email do the same. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-29git-send-email: fix missing space in error messageLibravatar Sylvain Rabot1-1/+1
When the command cannot make a connection to the SMTP server the error message to diagnose the broken configuration is issued. However, when an optional smtp-server-port is given and needs to be reported, the message lacked a space between "hello=<smtp-domain>" and "port=<smtp-server-port>". Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-24Merge branch 'ao/send-email-irt'Libravatar Junio C Hamano1-1/+2
* ao/send-email-irt: git-send-email.perl: make initial In-Reply-To apply only to first email t9001: send-email interation with --in-reply-to and --chain-reply-to
2010-11-24Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: imap-send: link against libcrypto for HMAC and others git-send-email.perl: Deduplicate "to:" and "cc:" entries with names mingw: do not set errno to 0 on success
2010-11-24Merge branch 'tr/send-email-refuse-sending-unedited-cover-letter' into maintLibravatar Junio C Hamano1-0/+13
* tr/send-email-refuse-sending-unedited-cover-letter: send-email: Refuse to send cover-letter template subject
2010-11-24git-send-email.perl: Deduplicate "to:" and "cc:" entries with namesLibravatar Joe Perches1-1/+1
If an email address in the "to:" list is in the style "First Last <email@domain.tld>", ie: not just a bare address like "email@domain.tld", and the same named entry style exists in the "cc:" list, the current logic will not remove the entry from the "cc:" list. Add logic to better deduplicate the "cc:" list by also matching the email address with angle brackets. Signed-off-by: Joe Perches <joe@perches.com> 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-1/+2
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 'ab/send-email-perl'Libravatar Junio C Hamano1-39/+35
* ab/send-email-perl: send-email: extract_valid_address use qr// regexes send-email: is_rfc2047_quoted use qr// regexes send-email: use Perl idioms in while loop send-email: make_message_id use "require" instead of "use" send-email: send_message die on $!, not $? send-email: use (?:) instead of () if no match variables are needed send-email: sanitize_address use qq["foo"], not "\"foo\"" send-email: sanitize_address use $foo, not "$foo" send-email: use \E***\Q instead of \*\*\* send-email: cleanup_compose_files doesn't need a prototype send-email: unique_email_list doesn't need a prototype send-email: file_declares_8bit_cte doesn't need a prototype send-email: get_patch_subject doesn't need a prototype send-email: use lexical filehandles during sending send-email: use lexical filehandles for $compose send-email: use lexical filehandle for opendir Conflicts: git-send-email.perl
2010-10-26Merge branch 'sb/send-email-use-to-from-input'Libravatar Junio C Hamano1-8/+17
* sb/send-email-use-to-from-input: send-email: Don't leak To: headers between patches send-email: Use To: headers in patch files Conflicts: git-send-email.perl
2010-10-26Merge branch 'ab/require-perl-5.8'Libravatar Junio C Hamano1-1/+2
* ab/require-perl-5.8: perl: use "use warnings" instead of -w perl: bump the required Perl version to 5.8 from 5.6.[21]
2010-10-26Merge branch 'jp/send-email-to-cmd'Libravatar Junio C Hamano1-17/+34
* jp/send-email-to-cmd: git-send-email.perl: Add --to-cmd Conflicts: git-send-email.perl
2010-10-26Merge branch 'po/sendemail'Libravatar Junio C Hamano1-3/+9
* po/sendemail: New send-email option smtpserveroption. Remove @smtp_host_parts variable as not used. Minor indentation fix.
2010-10-04send-email: Don't leak To: headers between patchesLibravatar Stephen Boyd1-8/+10
If the first patch in a series has a To: header in the file and the second patch in the series doesn't the address from the first patch will be part of the To: addresses in the second patch. Fix this by treating the to list like the cc list. Have an initial to list come from the command line, user input and config options. Then build up a to list from each patch and concatenate the two together before sending the patch. Finally, reset the list after sending each patch so the To: headers from a patch don't get used for the next one. Reported-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: extract_valid_address use qr// regexesLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: is_rfc2047_quoted use qr// regexesLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use Perl idioms in while loopLibravatar Ævar Arnfjörð Bjarmason1-3/+2
Change `while(<$fh>) { my $c = $_' to `while(my $c = <$fh>) {', and use `chomp $c' instead of `$c =~ s/\n$//g;', the two are equivalent in this case. I've also changed the --cccmd test so that we test for the stripping of whitespace at the beginning of the lines returned from the --cccmd. I think we probably shouldn't do this, but it was there already so I haven't changed the behavior. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: make_message_id use "require" instead of "use"Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Change the use of Sys::Hostname from a "use" to a "require". The former happens in an implicit BEGIN block and is thus immune from the if block it's contained in, so it's always loaded. This should speed up the invocation of git-send-email by a few milliseconds. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: send_message die on $!, not $?Libravatar Ævar Arnfjörð Bjarmason1-1/+1
If close fails we want to emit errno, not the return code of whatever happened to be the child process run. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use (?:) instead of () if no match variables are neededLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: sanitize_address use qq["foo"], not "\"foo\""Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Perl provides an alternate quote syntax which can make using "" inside interpolated strings easier to read. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: sanitize_address use $foo, not "$foo"Libravatar Ævar Arnfjörð Bjarmason1-1/+1
There's no reason to explicitly stringify a variable in Perl unless it's an overloaded object and you want to call overload::StrVal, otherwise it's just creating a new scalar redundantly. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use \E***\Q instead of \*\*\*Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Change the regex introduced in a03bc5b to use the \E...\Q escape syntax instead of using backslashes. It's more readable like this, and easier to grep for. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: cleanup_compose_files doesn't need a prototypeLibravatar Ævar Arnfjörð Bjarmason1-3/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: unique_email_list doesn't need a prototypeLibravatar Ævar Arnfjörð Bjarmason1-2/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: file_declares_8bit_cte doesn't need a prototypeLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: get_patch_subject doesn't need a prototypeLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use lexical filehandles during sendingLibravatar Ævar Arnfjörð Bjarmason1-7/+7
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use lexical filehandles for $composeLibravatar Ævar Arnfjörð Bjarmason1-11/+11
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use lexical filehandle for opendirLibravatar Ævar Arnfjörð Bjarmason1-3/+3
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29Merge branch 'tr/send-email-refuse-sending-unedited-cover-letter'Libravatar Junio C Hamano1-0/+13
* tr/send-email-refuse-sending-unedited-cover-letter: send-email: Refuse to send cover-letter template subject
2010-09-29Merge branch 'ab/send-email-catfile'Libravatar Junio C Hamano1-1/+2
* ab/send-email-catfile: send-email: use catfile() to concatenate files
2010-09-29send-email: Use To: headers in patch filesLibravatar Stephen Boyd1-0/+7
It's a minor annoyance when you take the painstaking time to setup To: headers for each patch in a large series, and then go out to send the series with git-send-email and watch git ignore the To: headers in the patch files. Therefore, always add To: headers from a patch file to the To: headers for that message. Keep the prompt for the blanket To: header so as to not break scripts (and user expectations). This means even if a patch has a To: header, git will prompt for the To: address. Otherwise, we'll need to introduce interface breakage to either request the header for each patch missing a To: header or default the header to whatever To: address is found first (be it in a patch or from user input). Both of these options don't seem very obvious/useful. Reported-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Tested-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>