Gregory Anders wrote:
> >> +--sendmail-cmd=<command>::
> >
> >Oh no no no. Don't do shortcuts.
> >
> >If you think --sendmail-command is too long, then address that problem
> >head on, don't try to hide it.
> >
> >I do think it's too long, which is why I suggested --command (especially
> >since it's obvious which command we are talking about), but I wouldn't
> >suggest --sdm-command, or something of that sort. We have to own our
> >decisions.
> >
> > 1. --command
> > 2. --sendmail
> > 3. --sendmail-command
> >
> >We have to pick one. I suggest #1.
> >
> >To try to make #3 shorter is just shoving the problem under the rug.
>
> The intention behind `--sendmail-cmd` was consistency with `--to-cmd`
> and `--cc-cmd`. Though both of those options also use the condensed
> 'cmd' form in their configuration options as well, so I suppose I should
> also change this one to 'sendemail.sendmailcmd'.
I see. In that case that might make sense. I still prefer #1.
> >> --- a/t/t9001-send-email.sh
> >> +++ b/t/t9001-send-email.sh
> >> @@ -57,7 +57,7 @@ test_no_confirm () {
> >> git send-email \
> >> --from="Example <from@xxxxxxxxxxx>" \
> >> --to=nobody@xxxxxxxxxxx \
> >> - --smtp-server="$(pwd)/fake.sendmail" \
> >> + --sendmail-cmd="\"$(pwd)/fake.sendmail\"" \
> >
> >People are already using --smpt-server=$cmd, we need to keep testing
> >that.
> >
> >Yes, eventually we would want them to move to --sendmail-cmd (or
> >--command, or whatever), but that won't happen tomorrow. Therefore our
> >primary tests need to be focused on --smtp-server.
> >
> >We need new *additional* tests for --sendmail-cmd, but those should not
> >override the current tests. At least not right now.
>
> I will add a test case for the absolute path form of --smtp-server;
> however, if we are introducing an option for specifying a sendmail-like
> command, surely that is the one to use when using "fake.sendmail", no?
>
> If we leave the test cases as-is for now, we introduce a split that
> someone will eventually need to come back and update anyway. Instead of
> kicking that can down the road, I thought it best to go ahead and do it
> now.
The sole purpose of software is that it's useful to users. Software that
works today but not tomorrow is bad software.
The primary purpose of the testing framework is to ensure that doesn't
happen; that git keeps working in the same way today than it did
yesterday.
That's why it's more important that tests excercise the options people
were using yesterday.
In addition we also want to be testing new functionality, but that's *in
addition*.
Maybe at some point in the future more people will be using
--sendmail-cmd, but right now that's not the case. Right now we need to
be testing the option people are using *today*.
Cheers.
--
Felipe Contreras
