Michael Haggerty <mhag...@alum.mit.edu> writes: > A while ago, I submitted an RFC for adding a new email notification > script to "contrib" [1]. The reaction seemed favorable and it was > suggested that the new script should replace post-receive-email rather > than be added separately, ideally with some kind of migration support.
I think replacing the old post-receive-email is a sane goal in the long run, but a good first step would be to have git-multimail merged in contrib, and start considering the old script as deprecated (keeping the old script doesn't harm IMHO, it's a one-file, 3 commits/year script, not really a maintainance burden). I started playing with git-multimail. In short, I do like it but had to fight a bit with python to get it to work, and couldn't get it to do exactly what I expect. Pull request attached :-). Installation troubles: I had an old python installation (Red Hat package, and I'm not root), that did not include the email.utils package, so I couldn't use my system's python. I found no indication about python version in README, so I installed the latest python by hand, just to find out that git-multimail wasn't compatible with Python 3.x. 2to3 can fix automatically a number of 3.x compatibility issues, but not all of them so I gave up and installed Python 2.7. I think adding a short "dependencies" section in the README (or in an INSTALL file) saying which Python version works could save new users the trouble (I see the sheebang inside the scripts says python2 but since I couldn't use my system's python and called "path/to/python git_multimail.py", this didn't help). Making the script portable with python 2 and 3 would be awesome ;-). Missing feature: git-multimail can send a summary for each push, with the "git log --oneline" of the new revisions, and then 1 mail per patch with the complete log and the patch. I'd like to have the intermediate: allow the summary email to include the complete log (not just --oneline). My colleagues already think they receive too many emails so I don't think they'd like the "one email per commit" way, but the 1 line summary is really short OTOH. I wrote a quick and hopefully not-too-dirty implementation of it, there's a pull request here: https://github.com/mhagger/git-multimail/pull/6 essentially, it boils down to: @@ -835,6 +837,17 @@ class ReferenceChange(Change): for line in self.expand_lines(NO_NEW_REVISIONS_TEMPLATE): yield line + if adds and self.showlog: + yield '\n' + yield 'Detailed log of added commits:\n\n' + for line in read_lines( + ['git', 'log'] + + self.logopts + + ['%s..%s' % (self.old.commit, self.new.commit,)], + keepends=True, + ): + yield line + # The diffstat is shown from the old revision to the new # revision. This is to show the truth of what happened in # this change. There's no point showing the stat from the -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
