Re: [PATCH v2 1/2] git-send-email: two new options: to-cover, cc-cover

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Apr 03, 2014 at 11:31:51AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" <mst@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.
> 

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