Re: [RFC v2] git-multimail: a replacement for post-receive-email

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Haggerty <mhagger@xxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]