The idea of this helper is that we want to save the current
value of a config variable and then restore it again after
the test completes. However, there's no point in actually
saving the value; it should always be restored to the string
"never" (which you can confirm by instrumenting
save_confirm to print the value it finds).
Let's just replace it with a single test_when_finished call.
Suggested-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The confirmation tests in t9001 all save the value of
sendemail.confirm, do something to it, then restore it at
the end, in a way that breaks the &&-chain (they are not
wrong, because they save the $? value, but it fools
--chain-lint).
Instead, they can all use test_when_finished, and we can
even make the code simpler by factoring out the shared
lines.
Note that we can _almost_ use test_config here, except that:
1. We do not restore the config with test_unconfig, but by
setting it back to some prior value.
2. We are not always setting a config variable. Sometimes
the change to be undone is unsetting it entirely.
We could teach test_config to handle these cases, but it's
not worth the complexity for a single call-site.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are tests which are missing a link in their &&-chain,
but during a setup phase. We may fail to notice failure in
commands that build the test environment, but these are
typically not expected to fail at all (but it's still good
to double-check that our test environment is what we
expect).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only Perl version 5.8.0 or later is required, but that comes with
an older Getopt::Long (2.32) that does not support the 'no-'
prefix. Support for that was added in Getopt::Long version 2.33.
Since the help only mentions the 'no-' prefix and not the 'no'
prefix, add explicit support for the 'no-' prefix to support
older GetOptions versions.
Reported-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The RFC says that they are to be concatenated after decoding (i.e. the
intervening whitespace is ignored).
Signed-off-by: Роман Донченко <dpb@corrigendum.ru>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Two general shell script codingstyles around here-text.
- Quote the <<\END_OF_HERE_TEXT string when there is no parameter
substitution going on to reduce cognitive load of the reader.
- Indent the text with <<-\END_OF_HERE_TEXT when able to make it
easier to spot boundaries of the tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Two general shell script codingstyles.
- No SP between redirection operator and its target
- One SP on both sides of () in "name () {" that begins a shell function
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use write_script. The resulting patch makes it a lot easier
to understand what the written script is doing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392
details problems when applying patches with "git am" in a repository with
CRLF line endings. In the example in the thread, the repository originated
from "git-svn" so it is not possible to use core.eol and friends on it.
Right now, the best option is to use "git am --keep-cr". However, when
a patch create new files, the patch application process will reject the
new file because it finds a "/dev/null\r" string instead of "/dev/null".
The problem is that SMTP transport is CRLF-unsafe. Sending a patch by
email is the same as passing it through "dos2unix | unix2dos". The newly
introduced CRLFs are normally transparent because git-am strips them. The
keepcr=true setting preserves them, but it is mostly working by chance
and it would be very problematic to have a "git am" workflow in a
repository with mixed LF and CRLF line endings.
The MIME solution to this is the quoted-printable transfer enconding.
This is not something that we want to enable by default, since it makes
received emails horrible to look at. However, it is a very good match
for projects that store CRLF line endings in the repository.
The only disadvantage of quoted-printable is that quoted-printable
patches fail to apply if the maintainer uses "git am --keep-cr". This
is because the decoded patch will have two carriage returns at the end
of the line. Therefore, add support for base64 transfer encoding too,
which makes received emails downright impossible to look at outside
a MUA, but really just works.
The patch covers all bases, including users that still live in the late
80s, by also providing a 7bit content transfer encoding that refuses
to send emails with non-ASCII character in them. And finally, "8bit"
will add a Content-Transfer-Encoding header but otherwise do nothing.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t9001 used a '\n' in a sed expression to split one line into two
lines, but the usage of '\n' in the "replacement string" is not
portable.
The '\n' can be used to match a newline in the "pattern space",
but otherwise the meaning of '\n' is unspecified in POSIX.
- Gnu versions of sed will treat '\n' as a newline character.
- Other versions of sed (like /usr/bin/sed under Mac OS X)
simply ignore the '\' before the 'n', treating '\n' as 'n'.
For reference see:
pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
http://www.gnu.org/software/sed/manual/sed.html
As the test already requires perl as a prerequisite, use perl
instead of sed.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a bourne shell script, "VAR=VAL command" is sufficient to run
'command' with environment variable VAR set to value VAL without
affecting the environment of the shell itself; there is no need
to say "env VAR=VAL command".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sender is now sanitized, but we didn't sanitize author when checking
whether From: line is needed in the message body.
As a result git started writing duplicate From: lines when author
matched sender and has utf8 characters.
Reported-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Verify that author name is not duplicated if it matches sender, even
if it is in utf8 (the test expects a failure that will be fixed in
the next patch).
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Users can sanitize from address manually.
Verify that these are suppressed properly.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
add test where sender address needs to be quoted.
Make sure --suppress-cc=self works well in this case.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check that suppress-cc=self works when applied
to output of cccmd.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds a basic test for --suppress-cc=self
option of git send-email.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Three years and a half is probably more than enough time to give users
the opportunity to configure Git to do what they want. If they haven't
changed the configuration by now, this warning message is not going to
do anything for them anyway.
This effectively reverts commit 528fb08 (prepare send-email for smoother
change of --chain-reply-to default).
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of these were found using Lucas De Marchi's codespell tool.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We allow send-email to use an implicitly-defined identity
for the sender (because there is still a confirmation step),
but we abort when we cannot generate such an identity. Let's
make sure that we test this.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently we keep getting questions even when the user has properly
configured his full name and password:
Who should the emails appear to be from?
[Felipe Contreras <felipe.contreras@gmail.com>]
And once a question pops up, other questions are turned on. This is
annoying.
The reason it's safe to avoid this question is because currently the
script fails completely when the author (or committer) is not correct,
so we won't even be reaching this point in the code.
The scenarios, and the current situation:
1) No information at all, no fully qualified domain name
fatal: empty ident name (for <felipec@nysa.(none)>) not allowed
2) Only full name
fatal: unable to auto-detect email address (got 'felipec@nysa.(none)')
3) Full name + fqdm
Who should the emails appear to be from?
[Felipe Contreras <felipec@nysa.felipec.org>]
4) Full name + EMAIL
Who should the emails appear to be from?
[Felipe Contreras <felipe.contreras@gmail.com>]
5) User configured
6) GIT_COMMITTER
7) GIT_AUTHOR
All these are the same as 4)
After this patch:
1) 2) won't change: git send-email would still die
4) 5) 6) 7) will change: git send-email won't ask the user
This is good, that's what we would expect, because the identity is
explicit.
3) will change: git send-email won't ask the user
This is bad, because we will try with an address such as
'felipec@nysa.felipec.org', which is most likely not what the user
wants, but the user will get warned by default (confirm=auto), and if
not, most likely the sending won't work, which the user would readily
note and fix.
The worst possible scenario is that such mail address does work, and the
user sends an email from that address unintentionally, when in fact the
user expected to correct that address in the prompt. This is a very,
very, very unlikely scenario, with many dependencies:
1) No configured user.name/user.email
2) No specified $EMAIL
3) No configured sendemail.from
4) No specified --from argument
5) A fully qualified domain name
6) A full name in the geckos field
7) A sendmail configuration that allows sending from this domain name
8) confirm=never, or
8.1) confirm configuration not hitting, or
8.2) Getting the error, not being aware of it
9) The user expecting to correct this address in the prompt
In a more likely scenario where 7) is not the case (can't send from
nysa.felipec.org), the user will simply see the mail was not sent
properly, and fix the problem.
The much more likely scenario though, is where 5) is not the case
(nysa.(none)), and git send-email will fail right away like it does now.
So the likelihood of this affecting anybody seriously is very very slim,
and the chances of this affecting somebody slightly are still very
small. The vast majority, if not all, of git users won't be affected
negatively, and a lot will benefit from this.
Tests-by: Jeff King <peff@peff.net>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
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>
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>
t/README recommends chaining test assertions.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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:
907a0b1e0484eeb687de3fee1fe871
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Jeff King