send-email: avoid questions when user has an ident

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>

0 files changed, 0 insertions, 0 deletions