"Michael S. Tsirkin" <m...@redhat.com> writes:
> Allow extracting To/Cc addresses from cover letter.
Please say what you are doing with what you extract, which is the
more important part of the objective. Extracting is merely a step
to achieve that.
s/.$/, to be used as To/Cc addresses of the remainder of the series./
or something.
I think this will be a very handy feature.
If you have a series *and* you bothered to add To/Cc to the cover
letter, it is likely that you want all the messages read by these
people [*1*].
> @@ -1468,6 +1475,15 @@ foreach my $t (@files) {
> @to = (@initial_to, @to);
> @cc = (@initial_cc, @cc);
>
> + if ($message_num == 1) {
> + if (defined $cover_cc and $cover_cc) {
> + @initial_cc = @cc;
> + }
> + if (defined $cover_to and $cover_to) {
> + @initial_to = @to;
> + }
> + }
> +
What is stored away with this code to @initial_cc/to includes:
- what was given to @initial_cc/to before ll.1468-1469
- what was in @cc/to before ll.1468-1469
when we see the first message [*2*]. The former come from the
command line --to/--cc, and the latter comes from the header lines
of the first message. Am I reading the code correctly?
If that is the case, I think the updated code makes sense.
Thanks.
[Footnote]
*1* Allowing this to be disabled is also a good thing this patch
does. A 100 patch series that does a tree-wide clean-up may
have different set of people on To/Cc of individual patches, and
you may want the union of them on To/Cc on the cover letter, so
that a person may get the cover letter and a single patch that
relates to his area of expertise without having to see the
remainder.
*2* The first message may not necessarily be the cover letter. Is
there a reliable way to detect that? The user may want to send
out a series with only a few patches without any cover, and
taking To/Cc from the [PATCH 1/3] and propagating them to the
rest does not match what the documentation and the option name
claim to do.
--
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
