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

Add parsing of elm aliases to git-send-email

2009-04-23T02:10:41Z

elm stores a text file version of the aliases that is = = This adds the parsing of this file to git-send-email Signed-off-by: Bill Pemberton Signed-off-by: Junio C Hamano

send-email: fix nasty bug in ask() function

2009-04-05T05:53:32Z

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 Signed-off-by: Junio C Hamano

send-email: ensure quoted addresses are rfc2047 encoded

2009-04-02T17:46:21Z

sanitize_address assumes that quoted addresses (e.g., "first last" Signed-off-by: Junio C Hamano

send-email: ask_default should apply to all emails, not just the first

2009-04-01T18:11:21Z

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 Signed-off-by: Jay Soffian Signed-off-by: Junio C Hamano

send-email: don't attempt to prompt if tty is closed

2009-04-01T18:10:06Z

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 Signed-off-by: Junio C Hamano

send-email: refactor and ensure prompting doesn't loop forever

2009-03-30T04:41:03Z

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 Signed-off-by: Junio C Hamano

Merge branch 'tr/maint-1.6.0-send-email-irt'

2009-03-18T01:54:46Z

* 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

send-email: add --confirm option and configuration setting

2009-03-03T07:46:53Z

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 Signed-off-by: Junio C Hamano

send-email: respect in-reply-to regardless of threading

2009-03-03T07:15:47Z

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 Signed-off-by: Junio C Hamano

send-email: don't create temporary compose file until it is needed

2009-02-24T06:03:50Z

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 Signed-off-by: Junio C Hamano