On Thu, Apr 03, 2014 at 11:31:51AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" <[email protected]> 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.
>
thanks, I did that in the new version.
> 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?
Exactly.
> 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.
Two things that come to mind:
- check that subject has 0000/
Needs some manual parsing, I don't like this much
- check that there's no patch
We could try running git mailinfo but it might give
false negatives if cover letter happens to have
---
diff a/foo b/bar
within it.
Worth worrying about?
For now I simply updated the documentation.
--
MST
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html