From: "Junio C Hamano" <gits...@pobox.com>
Junio C Hamano <gits...@pobox.com> writes:
I was trying to use, essentially, 'cat list.txt' as the command,...
One thing that needs to be made clear is that I do not think we want
to encourage `cat list.txt #` abuse in the first place.
OK [1]
It is an
unacceptable hack for us to encourage in the longer term. It may
happen to work with the current implementation, but it does so
merely by depending on the implementation too much.
If it is so common to want to spray all your patches to exactly the
same list of recipients that is unconditionally determined, having
It wasn't 'unconditional spraying' ;-), rather I'd carefully select who
to send to for each series, previously with multiple cc=".." on the
command line.
multiple sendemail.cc configuration variables, which are cumulative,
is already one way to do so, and you do not have to type such a long
option "--cc-cmd='cat $filename'" every time.
And if you do not want configuration for some reason, and having a
list of addresses in a flat file is so common, we could have a new
option "--cc-list=$filename" to support that use case. I however
doubt anything that starts with "First you make a list of addresses
in a flat file, and then do this" is a good solution.
For a longer series, a list will still need collating by the OP somehow,
but I don't think that alone would justify a new option.
I would think that it would probably be the best way to address "I
often want to cc these recipients, but not always" is to keep a list
of aliases, each entry of which expands to the recipients, and say
"--cc=group" from the command line to have it expanded to the set of
recipients.
[1] You mentioned in the previous email the script command argv[] array,
which I hadn't heard of (for a script), having been used the $1, $2,
method.
Given that new understanding, IIUC the proposal is that the garantee is
the "--cc-cmd" should be a single command/script name, with the
patchfilename passed as $1, and that a 'string string' for
interpretation would now be deprecated.
I'll see about a shorter doc patch that restricts itself to just the
base aspects, if that would be acceptable?
--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
