git/git-send-email.perl, branch v1.8.2.2

send-email: use the three-arg form of open in recipients_cmd

2013-04-01T04:30:27Z

Perlcritic does not want to see the trailing pipe in the two-args form of open(), i.e. open my $fh, "$cmd \Q$file\E |"; If $cmd were a single-token command name, it would make a lot more sense to use four-or-more-args form "open FILEHANDLE,MODE,CMD,ARGS" to avoid shell from expanding metacharacters in $file, but we do expect multi-word string in $to_cmd and $cc_cmd to be expanded by the shell, so we cannot rewrite it to open my $fh, "-|", $cmd, $file; for extra safety. At least, by using this in the three-arg form: open my $fh, "-|", "$cmd \Q$file\E"; we can silence Perlcritic, even though we do not gain much safety by doing so. Signed-off-by: Ramkumar Ramachandra Signed-off-by: Junio C Hamano

send-email: drop misleading function prototype

2013-04-01T04:30:27Z

The subroutine check_file_rev_conflict() is called from two places, both of which expects to pass a single scalar variable and see if that can be interpreted as a pathname or a revision name. It is defined with a function prototype ($) to force a scalar context while evaluating the arguments at the calling site but it does not help the current calling sites. The only effect it has is to hurt future calling sites that may want to build an argument list in an array variable and call it as check_file_rev_confict(@args). Drop the misleading prototype, as Perlcritic suggests. While at it, rename the function to avoid new call sites unaware of this change arising and add a comment clarifying what this function is for. Signed-off-by: Ramkumar Ramachandra Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

send-email: use "return;" not "return undef;" on error codepaths

2013-04-01T04:30:09Z

All the callers of "ask", "extract_valid_address", and "validate_patch" subroutines assign the return values from them to a single scalar: $var = subr(...); and "return undef;" in these subroutine can safely be turned into a simpler "return;". Doing so will also future-proof a new caller that mistakenly does this: @foo = ask(...); if (@foo) { ... we got an answer ... } else { ... we did not ... } Note that we leave "return undef;" in validate_address on purpose, even though Perlcritic may complain. The primary "return" site of the function returns whatever is in the scalar variable $address, so it is pointless to change only the other "return undef;" to "return". The caller must be prepared to see an array with a single undef as the return value from this subroutine anyway. Signed-off-by: Ramkumar Ramachandra Signed-off-by: Junio C Hamano

Merge branch 'nz/send-email-headers-are-case-insensitive'

2013-01-14T16:15:36Z

When user spells "cc:" in lowercase in the fake "header" in the trailer part, send-email failed to pick up the addresses from there. As e-mail headers field names are case insensitive, this script should follow suit and treat "cc:" and "Cc:" the same way. * nz/send-email-headers-are-case-insensitive: git-send-email: treat field names as case-insensitively

git-send-email: treat field names as case-insensitively

2013-01-07T07:48:12Z

Field names like To:, Cc:, etc. are case-insensitive; use a case-insensitive regexp to match them as such. Previously, git-send-email would fail to pick-up the addresses when in-body "fake" headers with different cases (e.g. lowercase "cc:") are manually inserted to the messages it was asked to send, even though the text will still show them. Signed-off-by: Nickolai Zeldovich Signed-off-by: Junio C Hamano

Merge branch 'km/send-email-remove-cruft-in-address'

2012-11-29T20:52:49Z

* km/send-email-remove-cruft-in-address: git-send-email: allow edit invalid email address git-send-email: ask what to do with an invalid email address git-send-email: remove invalid addresses earlier git-send-email: fix fallback code in extract_valid_address() git-send-email: remove garbage after email address

git-send-email: allow edit invalid email address

2012-11-26T23:49:12Z

In some cases the user may want to send email with "Cc:" line with email address we cannot extract. Now we allow user to extract such email address for us. Signed-off-by: Krzysztof Mazur Signed-off-by: Junio C Hamano

git-send-email: ask what to do with an invalid email address

2012-11-26T23:49:12Z

We used to warn about invalid emails and just drop them. Such warnings can be unnoticed by user or noticed after sending email when we are not giving the "final sanity check [Y/n]?" Now we quit by default. Signed-off-by: Krzysztof Mazur Suggested-by: Junio C Hamano Signed-off-by: Junio C Hamano

git-send-email: remove invalid addresses earlier

2012-11-26T23:49:05Z

Some addresses are passed twice to unique_email_list() and invalid addresses may be reported twice per send_message. Now we warn about them earlier and we also remove invalid addresses. This also removes using of undefined values for string comparison for invalid addresses in cc list processing. Signed-off-by: Krzysztof Mazur Signed-off-by: Junio C Hamano

send-email: avoid questions when user has an ident

2012-11-26T19:32:24Z

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 ] 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 ) 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 ] 4) Full name + EMAIL Who should the emails appear to be from? [Felipe Contreras ] 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 Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano