Subject: Re: [RFC] Add a new email notification script to "contrib"

From: Michael Haggerty <[email-masked]>
Date: Mon, 16 Jul 2012 00:45:13 +0200

On 07/15/2012 09:11 AM, Junio C Hamano wrote:
> [email-masked] writes:
>> Add a new Python script, contrib/hooks/post-receive-multimail.py, that
>> can be used to send notification emails describing pushes into a git
>> repository.  This script is derived from
>> contrib/hooks/post-receive-mail, but has many differences, including:
>
> The new script (I didn't read it at all) may be useful to some
> people, but I'm fairly negative on adding 47 different "I know there
> is something in contrib/, I looked at it, but I didn't bother
> updating it to fill my needs and wrote a new one instead" at this
> point to my tree.

I understand your concern.

> It is a different matter if the patch was to replace the existing
> one, saying "the users of the old script can use this one, which is
> backward compatible with respect to the external interface such as
> command line, or configuration variables used".  Instead of a total
> backward compatibility, "here is a script to migrate the existing
> set of configuration variables so that users of the old script can
> run it once, and start using this new one" is also perfectly fine.
>
> Such an enhancement, especially if the rewritten result is cleaner
> and easier to enhance going forward than the original, would be very
> much appreciated.

I didn't originally put the new script forward as a replacement for the 
old one mainly because it seems that Python is relatively unwelcome in 
the git project.  But if the use of Python doesn't disqualify it, then 
yes, I think the new script (with a little more work) will be a worthy 
replacement for the old shell script.

The new script is already mostly compatible with the old one:

* It accepts the same command-line arguments and uses most of the same 
configuration variables.

* It is possible to configure the new script to send only the refchange 
summary emails and skip sending the emails for individual commits, 
though I would want to put some work into supporting this mode better.

* I tested the earliest versions of the new script by verifying that its 
output was identical to that of the shell script.  (Of course the output 
is no longer identical; I claim that it is now better :-) .)

So I think it would be quite possible to touch up the new script to make 
it a drop-in replacement for the old one, and I am willing to do so.  If 
I understand correctly that there is a non-negligible chance of this 
happening, then I will continue working towards that goal.

Michael