Граф коммитов

82 Коммитов

Автор SHA1 Сообщение Дата
Johannes Schindelin 72b5158b25 t9001: do not fail only due to CR/LF issues
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14 22:37:58 -07:00
Cord Seele 463b0ea22b send-email: Fix %config_path_settings handling
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-14 14:45:49 -07:00
Junio C Hamano d3cae60efc Merge branch 'ao/t9001-fix'
* ao/t9001-fix:
  t/t9001-send-email.sh: fix '&&' chain in some tests
2011-01-05 13:31:25 -08:00
Antonio Ospite cc7e81674b t/t9001-send-email.sh: fix '&&' chain in some tests
t/README recommends chaining test assertions.

Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-01-04 15:46:29 -08:00
Junio C Hamano f2665ec9fa Merge branch 'maint'
* maint:
  gitweb: skip logo in atom feed when there is none
  t9001: Fix test prerequisites
2011-01-04 11:23:45 -08:00
Robin H. Johnson 57da204264 t9001: Fix test prerequisites
Add in missing Perl prerequisites for new tests of send-email.

Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-29 13:39:05 -08:00
Brandon Casey d2559f734b t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
The '--no-chain-reply-to' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-chain-reply-to) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports '--no' as in '--nochain-reply-to'.  More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.

See also:

907a0b1e04
84eeb687de
3fee1fe871

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-28 11:27:12 -08:00
Junio C Hamano 71d35bdb36 Merge branch 'tr/send-email-refuse-sending-unedited-cover-letter' into maint
* tr/send-email-refuse-sending-unedited-cover-letter:
  send-email: Refuse to send cover-letter template subject
2010-11-24 12:44:12 -08:00
Antonio Ospite db54c8e710 git-send-email.perl: make initial In-Reply-To apply only to first email
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-11-12 13:44:26 -08:00
Junio C Hamano 54aae5e1a0 t9001: send-email interation with --in-reply-to and --chain-reply-to
1. When --in-reply-to gives $reply_to, the first one becomes a reply to
    that message, with or without --chain-reply-to.

 2. When --chain-reply-to is in effect, all the messages are strung
    together to form a single chain.  The first message may be in reply to
    the $reply_to given by --in-reply-to command line option (see
    previous), or the root of the discussion thread.  The second one is a
    response to the first one, and the third one is a response to the
    second one, etc.

 3. When --chain-reply-to is not in effect:

    a. When --in-reply-to is used, too, the second and the subsequent ones
       become replies to $reply_to.  Together with the first rule, all
       messages become replies to $reply_to given by --in-reply-to.

    b. When --in-reply-to is not used, presumably the second and
       subsequent ones become replies to the first one, which would be the
       root.

The documentation is reasonably clear about the 1., 2. and 3a. above, I
think, even though I do not think 3b. is clearly specified.

The two tests added by this patch at least documents what happens between
these two options.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-05 14:21:05 -07:00
Junio C Hamano 7ebee44167 Merge branch 'ab/send-email-perl'
* 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-26 22:02:52 -07:00
Junio C Hamano 8796ff7f3f Merge branch 'sb/send-email-use-to-from-input'
* 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-26 22:02:03 -07:00
Junio C Hamano 9b1054d93e Merge branch 'jp/send-email-to-cmd'
* jp/send-email-to-cmd:
  git-send-email.perl: Add --to-cmd

Conflicts:
	git-send-email.perl
2010-10-26 21:52:26 -07:00
Junio C Hamano c7deb8dac1 Merge branch 'maint'
* maint:
  t/t9001-send-email.sh: fix stderr redirection in 'Invalid In-Reply-To'
  Clarify and extend the "git diff" format documentation
  git-show-ref.txt: clarify the pattern matching
  documentation: git-config minor cleanups
  Update test script annotate-tests.sh to handle missing/extra authors
2010-10-19 14:15:51 -07:00
Antonio Ospite 5b57413cb3 t/t9001-send-email.sh: fix stderr redirection in 'Invalid In-Reply-To'
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-19 14:15:30 -07:00
Stephen Boyd 3c3bb51c3b send-email: Don't leak To: headers between patches
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-10-04 00:12:13 -07:00
Ævar Arnfjörð Bjarmason 41ae8f1d6c send-email: use Perl idioms in while loop
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-30 12:20:33 -07:00
Junio C Hamano b886656403 Merge branch 'tr/send-email-refuse-sending-unedited-cover-letter'
* tr/send-email-refuse-sending-unedited-cover-letter:
  send-email: Refuse to send cover-letter template subject
2010-09-29 15:26:12 -07:00
Stephen Boyd 21802cd328 send-email: Use To: headers in patch files
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>
2010-09-29 13:24:04 -07:00
Joe Perches 6e74e075d2 git-send-email.perl: Add --to-cmd
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-27 12:36:57 -07:00
Thomas Rast a03bc5b6ad send-email: Refuse to send cover-letter template subject
Every so often, someone sends out an unedited cover-letter template.
Add a simple check to send-email that refuses to send if the subject
contains "*** SUBJECT HERE ***", with an option --force to override.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-08 09:11:15 -07:00
Ævar Arnfjörð Bjarmason f9444147fa t/t9001-send-email.sh: convert setup code to tests
Change the setup code in t/t9001-send-email.sh to use
test_expect_success. This way it isn't needlessly run in environments
where the test prerequisites aren't met.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18 12:43:23 -07:00
Ævar Arnfjörð Bjarmason 57cd35e6ad t/t9001-send-email.sh: change from skip_all=* to prereq skip
Change this test to skip test with test prerequisites, and to do setup
work in tests. This improves the skipped statistics on platforms where
the test isn't run.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18 12:43:23 -07:00
Ævar Arnfjörð Bjarmason 3731231d4c t/t9001-send-email.sh: Remove needless PROG=* assignment
Remove the PROG=* assignment from t9001-send-email.sh. It's been there
since v1.4.0-rc1~30 when the test was originally added, but only tests
that source annotate-tests.sh need it, it was seemingly introduced to
this test via copy/paste coding.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18 12:43:23 -07:00
Junio C Hamano 2a16315031 Merge branch 'ab/tap'
* ab/tap:
  t/README: document more test helpers
  t/README: proposed rewording...
  t/README: Document the do's and don'ts of tests
  t/README: Add a section about skipping tests
  t/README: Document test_expect_code
  t/README: Document test_external*
  t/README: Document the prereq functions, and 3-arg test_*
  t/README: Typo: paralell -> parallel
  t/README: The trash is in 't/trash directory.$name'
  t/t9700/test.pl: don't access private object members, use public access methods
  t9700: Use Test::More->builder, not $Test::Builder::Test
  tests: Say "pass" rather than "ok" on empty lines for TAP
  tests: Skip tests in a way that makes sense under TAP
  test-lib: output a newline before "ok" under a TAP harness
  test-lib: Make the test_external_* functions TAP-aware
  test-lib: Adjust output to be valid TAP format
2010-07-07 11:18:44 -07:00
Brandon Casey 3183286238 t/t9001: use egrep when regular expressions are involved
Supplying backslashed, extended regular expressions to grep is not
portable.  Use egrep instead.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-29 09:31:48 -07:00
Ævar Arnfjörð Bjarmason fadb5156e4 tests: Skip tests in a way that makes sense under TAP
SKIP messages are now part of the TAP plan. A TAP harness now knows
why a particular test was skipped and can report that information. The
non-TAP harness built into Git's test-lib did nothing special with
these messages, and is unaffected by these changes.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-25 10:08:20 -07:00
Thomas Rast 3cae7e5b2b send-email: ask about and declare 8bit mails
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-06-18 08:47:32 -07:00
Stephen Boyd f434c083a0 send-email: add --no-cc, --no-to, and --no-bcc
There's no way to override the sendemail.to, sendemail.cc, and
sendemail.bcc config settings. Add options allowing the user to tell
git to ignore the config settings and take whatever is on the command
line.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-08 15:55:42 -08:00
Stephen Boyd 9524cf2993 fix portability issues with $ in double quotes
Using a dollar sign in double quotes isn't portable. Escape them with
a backslash or replace the double quotes with single quotes.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-26 15:16:54 -08:00
Brandon Casey 907a0b1e04 t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
The '--no-chain-reply-to' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-chain-reply-to) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports '--no' as in '--nochain-reply-to'.  More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-03 10:07:17 -08:00
Junio C Hamano 0c7cc135c5 Merge branch 'fc/send-email-envelope' 2009-11-30 14:42:50 -08:00
Nanako Shiraishi 528fb08732 prepare send-email for smoother change of --chain-reply-to default
Give a warning message when send-email uses chain-reply-to to thread the
messages because of the current default, not because the user explicitly
asked to, either from the command line or from the configuration.

This way, by the time 1.7.0 switches the default, everybody will be ready.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-29 00:51:35 -08:00
Felipe Contreras c89e324145 send-email: automatic envelope sender
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-27 23:45:24 -08:00
Junio C Hamano 4f333bc1d3 t9001: test --envelope-sender option of send-email
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-22 12:08:44 -08:00
Joe Perches 02461e0e28 git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s
Some MTAs reject Cc: lines longer than 78 chars.
Avoid this by using the same join as "To:" ",\n\t"
so each subsequent Cc entry is on a new line.

RCPT TO: should have a single entry per line.
see: http://www.ietf.org/rfc/rfc2821.txt

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-09 17:02:21 -07:00
Brandon Casey 977e289e0d t/t9001-send-email.sh: ensure generated script is executed with $SHELL_PATH
If the shell is not specified using the '#!' notation, then the OS will
use '/bin/sh' to execute the script which may not produce the desired
results.  In particular, /bin/sh on Solaris interprets '^' specially which
has an effect on the sed command that this patch touches.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-23 16:41:27 -07:00
Paolo Bonzini cb8a9bd518 Test cccmd in t9001-send-email.sh and fix some bugs
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-18 09:55:59 -07:00
Junio C Hamano 95a877a34c Merge branch 'mh/maint-fix-send-email-threaded' into mh/fix-send-email-threaded
* 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-12 09:23:43 -07:00
Markus Heidelberg f74fe34b96 send-email: fix threaded mails without chain-reply-to
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-12 09:22:15 -07:00
Markus Heidelberg d67114a5f3 add a test for git-send-email for threaded mails without chain-reply-to
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-12 09:22:14 -07:00
Markus Heidelberg 5e9758e296 send-email: fix non-threaded mails
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-12 09:20:21 -07:00
Markus Heidelberg 32ae83194b add a test for git-send-email for non-threaded mails
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-12 09:20:18 -07:00
Brandon Casey d1fff6fce0 send-email: use UTF-8 rather than utf-8 for consistency
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-09 00:15:57 -07:00
Brandon Casey 84eeb687de t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
The '--no-thread' option is a Getopt::Long boolean option. The '--no-'
prefix (as in --no-thread) for boolean options is not supported in
Getopt::Long version 2.32 which was released with Perl 5.8.0. This version
only supports '--no' as in '--nothread'.  More recent versions of
Getopt::Long, such as version 2.34, support either prefix. So use the older
form in the tests.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-25 08:54:18 -07:00
Jeff King 1b19ccd236 tests: skip perl tests if NO_PERL is defined
These scripts all test git programs that are written in
perl, and thus obviously won't work if NO_PERL is defined.
We pass NO_PERL to the scripts from the building Makefile
via the GIT-BUILD-OPTIONS file.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-08 22:42:16 -07:00
Jay Soffian 0da43a685a send-email: fix nasty bug in ask() function
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-04 22:53:32 -07:00
Jay Soffian a61c0ffa44 send-email: ensure quoted addresses are rfc2047 encoded
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-02 10:46:21 -07:00
Jay Soffian 3b3637c3f1 send-email: correct two tests which were going interactive
Commit c18f75a (send-email: add tests for refactored prompting, 2009-03-28)
added two tests which went interactive under the dash shell.

This patch corrects the issue, reported by Björn Steinbrink.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-02 10:46:21 -07:00
Jay Soffian dc1460aa8d send-email: ask_default should apply to all emails, not just the first
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-01 11:11:21 -07:00