Re: [PATCH 2/2] send-email: add series-cc-cmd option

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Nov 12, 2012, 23:37 UTC
Message-ID: <CAMP44s2EyMcYHYGvxZnj90qD5ms2YZ5O6gXv_TTES0H72vUm0g@mail.gmail.com>
In-Reply-To: <1352761982.18715.20.camel@joe-AO722>

On Tue, Nov 13, 2012 at 12:13 AM, Joe Perches <joe@perches.com> wrote:

Show 31 quoted lines

> On Tue, 2012-11-13 at 00:03 +0100, Felipe Contreras wrote:
>> On Mon, Nov 12, 2012 at 11:52 PM, Joe Perches <joe@perches.com> wrote:
>> > On Tue, 2012-11-13 at 03:21 +0530, Ramkumar Ramachandra wrote:
>> >> Felipe Contreras wrote:
>> >> > cc-cmd is only per-file, and many times receipients get lost without
>> >> > seing the full patch series.
>> >>
>> >> s/seing/seeing
>> >>
>> >> > [...]
>> >>
>> >> Looks good otherwise.
>> >
>> > s/receipients/recipients/ too
>> >
>> > Practically this is ok but I think it's unnecessary.
>> >
>> > Output from git format-patch is always in a single
>> > directory.
>>
>> A temporary directory.
>>
>> > My work flow is to use a script for --to and --cc
>> > lines that can be set to emit the same addresses for
>> > all files in a patch series or generate different
>> > addresses per patch file.
>>
>> For --to-cmd and --cc-cmd? So basically you check the dirname of the
>> argument passed?
>
> yes. basename and dirname

Well, the basename is irrelevant, because you don't care witch particular patch is being sent, you are going to process all of them every time.

>> While that works, it means you have to run the same command multiple
>> times, one for each mail.
>
> Shrug.  it's not a generally significant cost.

It is when you use 'git blame' and there's a lot of history:

% time git cc-cmd -1 1266686 Peter Krefting <peter@softwolves.pp.se> junio Tran Ngoc Quan <vnwildman@gmail.com> Jiang Xin <worldhello.net@gmail.com> git cc-cmd -1 1266686 0.23s user 0.16s system 1% cpu 19.991 total

> The script could also output the addresses to yet another file.

Which would be even more hacky.

Show 5 quoted lines

>> If the command is using something expensive such as 'git blame' and
>> you have many patches, this is particularly bad. Also, it's not
>> elegant :)
>
> Elegant is a beholder viewpoint.

You think a solution that runs the same instructions multiple times unnecessarily is elegant? All right.

-- 
Felipe Contreras