On Mon, Oct 4, 2010 at 07:05, Stephen Boyd <bebarino@xxxxxxxxx> wrote:
> If the first patch in a series has a To: header in the file and the
> second patch in the series doesn't the address from the first patch will
> be part of the To: addresses in the second patch. Fix this by treating the
> to list like the cc list. Have an initial to list come from the command
> line, user input and config options. Then build up a to list from each
> patch and concatenate the two together before sending the patch. Finally,
> reset the list after sending each patch so the To: headers from a patch
> don't get used for the next one.
Couldn't this whole thing be done by:
> Â# Variables we fill in automatically, or via prompting:
> -my (@to,$no_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
> +my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
Changing this to an "our" variable instead of a "my".
> Â Â Â Âmy $body_encoding;
> + Â Â Â @to = ();
Then doing:
local @to = @to;
> + Â Â Â @to = (@initial_to, @to);
> Â Â Â Â@cc = (@initial_cc, @cc);
And keeping this as it is, and should the @cc addresses by accumulated
across patches, but not the @to addresses?
> +test_expect_success $PREREQ 'To headers from files reset each patch' '
> + Â Â Â patch1=`git format-patch -1 --to="bodies@xxxxxxxxxxx"` &&
> + Â Â Â patch2=`git format-patch -1 --to="other@xxxxxxxxxxx" HEAD~` &&
> + Â Â Â test_when_finished "rm $patch1 && rm $patch2" &&
> + Â Â Â git send-email \
> + Â Â Â Â Â Â Â --dry-run \
> + Â Â Â Â Â Â Â --from="Example <nobody@xxxxxxxxxxx>" \
> + Â Â Â Â Â Â Â --to="nobody@xxxxxxxxxxx" \
> + Â Â Â Â Â Â Â --smtp-server relay.example.com \
> + Â Â Â Â Â Â Â $patch1 $patch2 >stdout &&
> + Â Â Â test $(grep -c "RCPT TO:<bodies@xxxxxxxxxxx>" stdout) = 1 &&
> + Â Â Â test $(grep -c "RCPT TO:<nobody@xxxxxxxxxxx>" stdout) = 2 &&
> + Â Â Â test $(grep -c "RCPT TO:<other@xxxxxxxxxxx>" stdout) = 1
> +'
> +
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html