mhagger@alum.mit.edu writes:
From: Michael Haggerty <redacted>
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.
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.
Thanks.
On 07/15/2012 09:11 AM, Junio C Hamano wrote:
mhagger@alum.mit.edu writes:
quoted
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