Re: [RFC v2] git-multimail: a replacement for post-receive-email
On 02/25/2013 11:50 AM, Michael Haggerty wrote: On 02/25/2013 10:54 AM, Matthieu Moy wrote: [...] Works for me. One minor knit: you've included 10-characters sha1s (this comes from self.short = read_output(['git', 'rev-parse', '--short=10', sha1]) ), I'd find it better with shorter sha1s. In the case of branch update, if the branch name is a bit long, it could be nice to save a few characters. Why not just say git rev-parse --short, without argument? This way, the default is used, ie. AFAICT it uses 7 characters by default, but will use more if needed to keep the unicity. [...] I guess I will change the code to use $(git rev-parse --short) (i.e., shorter SHA1s) but reserving 10 columns in tables for them (which can be done via Python string formatting in the templates). That should give the best of both worlds. I implemented this change (allow git to choose the SHA1 abbreviation length) and just pushed it to github. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
Matthieu Moy matthieu@grenoble-inp.fr writes: A few more random thoughts (not on my personal todo-list): One more: When sending commit emails, it may help to ensure that the dates are strictly monotonic, so that the thread is seen in the right order. IIRC, git send-email does this by tweaking the Date: field to make sure there is at least one second between two emails (although they may be actually sent at the same second). It would be cool to have the same for git multimail. -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
Michael Haggerty mhag...@alum.mit.edu writes: On 02/20/2013 01:28 PM, Matthieu Moy wrote: Michael Haggerty mhag...@alum.mit.edu writes: A while ago, I submitted an RFC for adding a new email notification script to contrib [...] We've discussed offline with Michael, a few patches have been merged, and there are still a few pending pull requests. I liked the script already, but it's getting even cooler ;-). A few more random thoughts (not on my personal todo-list): * It may make sense to add the short sha1 of the new reference in email titles (branch foo updated - branch foo updated to $sha1), so that gmail users do not get a single huge thread branch foo updated. (Yes, I do know about the Reference field, but gmail uses Subject: for threading). [...] I just implemented this in branch sha1s-in-subject [1]. Please let me know if this works for you then I'll merge it to master. (It depends on the header-handling branch, which also includes your patch for non-ASCII header fields.) Works for me. One minor knit: you've included 10-characters sha1s (this comes from self.short = read_output(['git', 'rev-parse', '--short=10', sha1]) ), I'd find it better with shorter sha1s. In the case of branch update, if the branch name is a bit long, it could be nice to save a few characters. Why not just say git rev-parse --short, without argument? This way, the default is used, ie. AFAICT it uses 7 characters by default, but will use more if needed to keep the unicity. -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
Michael Haggerty mhag...@alum.mit.edu writes: I wonder whether it would be to far off the beaten path to allow glob patterns in the branch specification; e.g., [multimailhook refs/heads/release-*] mailingList = q...@example.com Yes, that would be even better. For the case of multiple glob patterns matching a branch name, there would probably have to be a notion of best match, but that doesn't seem too difficult. I'd rather have a simple rule here like last one wins or so. Saying that foo-bar-* is a better match than foo-* may be easy, but you can hardly avoid having corner-cases like foo-*-boz vs foo-bar-* when matching foo-bar-boz. This feature could also be used to get the functionality of your proposal for skipRefs and onlyRefs [1] in a more general way: [multimailhook] mailingList = s...@example.com [multimailhook refs/heads/user/$USER/*] mailingList = Yes, I thougth about that, but it is not only more general, but also less conveinient: [multimailhook] mailingList = s...@example.com refchangelist = ot...@example.com [multimailhook refs/heads/user/$USER/*] mailingList = # Oops, forgot to override refchangelist, the mail will still # be sent. So skipRefs and onlyRefs would still make sense IMHO. -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
On 02/25/2013 10:54 AM, Matthieu Moy wrote: Michael Haggerty mhag...@alum.mit.edu writes: On 02/20/2013 01:28 PM, Matthieu Moy wrote: Michael Haggerty mhag...@alum.mit.edu writes: A while ago, I submitted an RFC for adding a new email notification script to contrib [...] We've discussed offline with Michael, a few patches have been merged, and there are still a few pending pull requests. I liked the script already, but it's getting even cooler ;-). A few more random thoughts (not on my personal todo-list): * It may make sense to add the short sha1 of the new reference in email titles (branch foo updated - branch foo updated to $sha1), so that gmail users do not get a single huge thread branch foo updated. (Yes, I do know about the Reference field, but gmail uses Subject: for threading). [...] I just implemented this in branch sha1s-in-subject [1]. Please let me know if this works for you then I'll merge it to master. (It depends on the header-handling branch, which also includes your patch for non-ASCII header fields.) Works for me. One minor knit: you've included 10-characters sha1s (this comes from self.short = read_output(['git', 'rev-parse', '--short=10', sha1]) ), I'd find it better with shorter sha1s. In the case of branch update, if the branch name is a bit long, it could be nice to save a few characters. Why not just say git rev-parse --short, without argument? This way, the default is used, ie. AFAICT it uses 7 characters by default, but will use more if needed to keep the unicity. I did this intentionally because the SHA1s appear in columns within the refchange emails, and having varying-length SHA1s would cause subsequent columns to be misaligned. I figured that a length of 10, aside from being a number that I can still count on my fingers, would be long enough that it would rarely have to be extended. I guess I will change the code to use $(git rev-parse --short) (i.e., shorter SHA1s) but reserving 10 columns in tables for them (which can be done via Python string formatting in the templates). That should give the best of both worlds. Thanks for the feedback! Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
On 02/20/2013 01:28 PM, Matthieu Moy wrote: Michael Haggerty mhag...@alum.mit.edu writes: A while ago, I submitted an RFC for adding a new email notification script to contrib [...] We've discussed offline with Michael, a few patches have been merged, and there are still a few pending pull requests. I liked the script already, but it's getting even cooler ;-). A few more random thoughts (not on my personal todo-list): * It may make sense to add the short sha1 of the new reference in email titles (branch foo updated - branch foo updated to $sha1), so that gmail users do not get a single huge thread branch foo updated. (Yes, I do know about the Reference field, but gmail uses Subject: for threading). [...] I just implemented this in branch sha1s-in-subject [1]. Please let me know if this works for you then I'll merge it to master. (It depends on the header-handling branch, which also includes your patch for non-ASCII header fields.) Michael [1] https://github.com/mhagger/git-multimail/tree/sha1s-in-subject -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
On 02/20/2013 01:28 PM, Matthieu Moy wrote: Michael Haggerty mhag...@alum.mit.edu writes: A while ago, I submitted an RFC for adding a new email notification script to contrib [...] We've discussed offline with Michael, a few patches have been merged, and there are still a few pending pull requests. I liked the script already, but it's getting even cooler ;-). A few more random thoughts (not on my personal todo-list): [...] * Perhaps we should allow a per-branch configuration, like [multimailhook] mailingList = s...@list.com [multimailhook refs/heads/my-branch] mailingList = some-ot...@list.com whateverOtherConfig = whateverOtherValue Branch specific would override value for Config.get(), and Config.get_all() should probably list both the branch-specific and the other keys. I wonder whether it would be to far off the beaten path to allow glob patterns in the branch specification; e.g., [multimailhook refs/heads/release-*] mailingList = q...@example.com For the case of multiple glob patterns matching a branch name, there would probably have to be a notion of best match, but that doesn't seem too difficult. The matching would have to take place when looking up individual options to avoid having to replicate the full configuration for each pattern. This feature could also be used to get the functionality of your proposal for skipRefs and onlyRefs [1] in a more general way: [multimailhook] mailingList = s...@example.com [multimailhook refs/heads/user/$USER/*] mailingList = Michael [1] Proposed feature to allow certain references to be ignored for the purpose of notification emails; see https://github.com/mhagger/git-multimail/pull/15 -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
Michael Haggerty mhag...@alum.mit.edu writes: A while ago, I submitted an RFC for adding a new email notification script to contrib [1]. We've discussed offline with Michael, a few patches have been merged, and there are still a few pending pull requests. I liked the script already, but it's getting even cooler ;-). A few more random thoughts (not on my personal todo-list): * It may make sense to add the short sha1 of the new reference in email titles (branch foo updated - branch foo updated to $sha1), so that gmail users do not get a single huge thread branch foo updated. (Yes, I do know about the Reference field, but gmail uses Subject: for threading). * Perhaps we should allow a per-branch configuration, like [multimailhook] mailingList = s...@list.com [multimailhook refs/heads/my-branch] mailingList = some-ot...@list.com whateverOtherConfig = whateverOtherValue Branch specific would override value for Config.get(), and Config.get_all() should probably list both the branch-specific and the other keys. -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
Michael Haggerty mhag...@alum.mit.edu writes: On 02/13/2013 03:56 PM, Matthieu Moy wrote: 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. What version of Python was it that caused problems? Python 2.4.3, installed with RHEL 5.9. I just discovered that the script wouldn't have worked with Python 2.4, where email.utils used to be called email.Utils. Indeed, import email.Utils works with this Python. But I pushed a fix to GitHub: ddb1796660 Accommodate older versions of Python's email module. Not sufficient, but I added a pull request that works for me with 2.4. @@ -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 Thanks for the patch. I like the idea, but I think the implementation is incorrect. Your code will not only list new commits but will also list commits that were already in the repository on another branch (e.g., if an existing feature branch is merged into master, all of the commits on the feature branch will be listed). (Or was that your intention?) I did not think very carefully about this case, but the behavior of my code seems sensible (although not uncontroversial): it's just showing the detailed log for the same commits as the summary at the top of the email. I have no personnal preferences. But even worse, it will fail to list commits that were added at the same time that a branch was created (e.g., if I create a feature branch with a number of commits on it and then push it for the first time). Right. Probably the Push object has to negotiate with its constituent ReferenceChange objects to figure out which one is responsible for summarizing each of the commits newly added by the push (i.e., the ones returned by push.get_new_commits(None)). I updated the pull request with a version that works for new branches, and takes the list of commits to display from the call to get_new_commits (which were already there for other purpose). Then, it essentially calls git log --no-walk $list_of_sha1s. This should be better. -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
On 02/14/2013 01:55 PM, Matthieu Moy wrote: Michael Haggerty mhag...@alum.mit.edu writes: On 02/13/2013 03:56 PM, Matthieu Moy wrote: 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. What version of Python was it that caused problems? Python 2.4.3, installed with RHEL 5.9. I just discovered that the script wouldn't have worked with Python 2.4, where email.utils used to be called email.Utils. Indeed, import email.Utils works with this Python. But I pushed a fix to GitHub: ddb1796660 Accommodate older versions of Python's email module. Not sufficient, but I added a pull request that works for me with 2.4. @@ -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 Thanks for the patch. I like the idea, but I think the implementation is incorrect. Your code will not only list new commits but will also list commits that were already in the repository on another branch (e.g., if an existing feature branch is merged into master, all of the commits on the feature branch will be listed). (Or was that your intention?) I did not think very carefully about this case, but the behavior of my code seems sensible (although not uncontroversial): it's just showing the detailed log for the same commits as the summary at the top of the email. I have no personnal preferences. I guess it depends a lot on what logopts are used. If the user configures logopts to emit full patches, then the repeated reporting of the same commits would cause a big increase in the bulk of notification emails. But if the logopts are set to just emit a brief summary (e.g., author and log message), then a bit of repetition might be acceptable. But since I wouldn't use this feature, I don't personally have a preference. But even worse, it will fail to list commits that were added at the same time that a branch was created (e.g., if I create a feature branch with a number of commits on it and then push it for the first time). Right. Probably the Push object has to negotiate with its constituent ReferenceChange objects to figure out which one is responsible for summarizing each of the commits newly added by the push (i.e., the ones returned by push.get_new_commits(None)). I updated the pull request with a version that works for new branches, and takes the list of commits to display from the call to get_new_commits (which were already there for other purpose). Then, it essentially calls git log --no-walk $list_of_sha1s. This should be better. I will check it out. Thanks! Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
On Wednesday 13 February 2013 14:56:25 Matthieu Moy wrote: Michael Haggerty mhag...@alum.mit.edu writes: 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 ;-). For my 2p worth, I don't like seeing hooks called like this. Particular those that come as part of the standard installation. I call mine by installing little scripts like this (on Debian): #!/bin/sh # stored as $GIT_WORK_DIR/.git/hooks/post-receive-email exec /bin/sh /usr/share/git-core/contrib/hooks/post-receive-email This means I don't have to make the sample script executable, it gets upgraded automatically as git gets upgraded, and the interpreter is easily changed by changing a file in my work directory, rather than altering a packaged file. I'd prefer to see the /usr/share/git-core/templates/hooks/ using a similar technique, as to my mind, installing a full copy of the sample script in every new repository is wasteful and leaves you with potentially out-of-date scripts when you update git. Andy -- Dr Andy Parkins andypark...@gmail.com -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
Andy Parkins andypark...@gmail.com writes: On Wednesday 13 February 2013 14:56:25 Matthieu Moy wrote: Michael Haggerty mhag...@alum.mit.edu writes: 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 ;-). For my 2p worth, I don't like seeing hooks called like this. Particular those that come as part of the standard installation. What do you mean by like this ? I call mine by installing little scripts like this (on Debian): #!/bin/sh # stored as $GIT_WORK_DIR/.git/hooks/post-receive-email exec /bin/sh /usr/share/git-core/contrib/hooks/post-receive-email Yes, this is what I was doing (with path/to/python instead of /bin/sh, and git_multimail.py, or more precisely path/to/git_multimail.py, instead of post-receive-email). -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
On 02/13/2013 03:56 PM, Matthieu Moy wrote: 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 :-). Thanks very much for your feedback and patches. 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. What version of Python was it that caused problems? I just discovered that the script wouldn't have worked with Python 2.4, where email.utils used to be called email.Utils. But I pushed a fix to GitHub: ddb1796660 Accommodate older versions of Python's email module. With this change, I think that git-multimail will work with any version of Python 2.4 = x 3.0. So if your original problem was with Python 2.4, maybe you could try the new version and see if it works with that interpreter. 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). Yes, I'm working on a Requirements section with that information and more. I'd like to list a minimum git version too, but it would be quite a bit of work to figure out when each command and each option was added. It would be helpful if anybody who has used the script with an old version of git lets me know whether they were successful or not. Making the script portable with python 2 and 3 would be awesome ;-). Agreed, but I doubt I will be able to get to it very soon. 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 Thanks for the patch. I like the idea, but I think the implementation is incorrect. Your code will not only list new commits but will also list commits that were already in the repository on another branch (e.g., if an existing feature branch is merged into master, all of the commits on the feature branch will be listed). (Or was that your intention?) But even worse, it will fail to list commits that were added at the same time that a branch was created (e.g., if I create a feature branch with a number of commits on it and then push it for the first time). Probably the Push object has to negotiate with its constituent ReferenceChange objects to figure out which one is responsible for summarizing each of the commits newly added by the push (i.e., the ones returned by push.get_new_commits(None)).
Re: [RFC v2] git-multimail: a replacement for post-receive-email
On Sun, Jan 27, 2013 at 9:37 AM, Michael Haggerty mhag...@alum.mit.edu wrote: 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 just want to say since I think this thread hasn't been getting the attention it deserves: I'm all for this. I've used git-multimail and it's a joy to configure and extend compared to the existing hacky shellscript. I'm not running it at $work yet because I still need to write some extensions for to port some of of our local hacks to the old shellscript over. I fully support replacing the existing mailing script with git-multimail, it's better in every way, and unlike the current script has an active maintainer. -- 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
Re: [RFC v2] git-multimail: a replacement for post-receive-email
On Jan 29, 2013, at 7:25 AM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: On Sun, Jan 27, 2013 at 9:37 AM, Michael Haggerty mhag...@alum.mit.edu wrote: 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 just want to say since I think this thread hasn't been getting the attention it deserves: I'm all for this. I've used git-multimail and it's a joy to configure and extend compared to the existing hacky shellscript. This seems good to me as long as it's okay for git contrib to depend on python. I've started testing git-multimail in my environment. smime.p7s Description: S/MIME cryptographic signature
[RFC v2] git-multimail: a replacement for post-receive-email
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've been working on this on and off since then and I think it is time for another iteration. I think I have addressed most of the points raised earlier, including a migration script and specific migration instructions. Review of main advantages of git-multimail over post-receive-email: * Can (optionally) send a separate email for each new commit (in addition to the emails for each reference change). * More flexible configuration, including out-of-the-box support for running under gitolite. * Fixed algorithm for detecting new commits. * More information in emails (e.g., commit log subject lines, telling when a push discards old commits)j. * Written in Python rather than shell. Easier to extend. Summary of improvements since the first version: * Rename the project from the cumbersome post-receive-multimail.py to git-multimail. * Push the project into a subdirectory and break it into multiple files (script, docs, etc). * Vastly improve the documentation and separate it out of the script into a README file. * Add a migration script, migrate-mailhook-config, that converts a post-receive-email configuration into a git-multimail configuration. Document the migration procedure and differences between the two scripts in README.migrate-from-post-receive-email. * Store the configuration options in namespace multimailhook.* rather than hooks.*. (The post-receive-email script's use of a too-generic top-level name was IMHO a bad idea, so fix it now.) * Allow the feature of sending a separate email for each individual commit to be turned off via a configuration option (to better support post-receive-email migrants). * Re-implement the feature of showing a short log of commits in announcement emails, configurable via an option. * Make it possible to import the main code as a Python module to allow most customization to be done via Python code without the need to edit the original file. (Note for existing users: the Environment API has changed since the original RFC, but I will try to keep it stable from now on.) * Allow the config settings that define recipient lists to be multivalued. * Added some testing infrastructure (though the tests are still very limited). * Add Auto-Submitted headers to emails (as implemented for post-receive-email by Chris Hiestand). * Add option to truncate email lines to a specified length (suggested by Matthieu Moy). By default, this option is *on* and set to 500 characters. * Add option to force the main part of the email body to be valid UTF-8, with invalid characters turned into the Unicode replacement character, U+FFFD. By default, this option is *on* (arguments for turning it off by default are welcome). The code is in its own GitHub repository: https://github.com/mhagger/git-multimail The script should work with any Python 2.x starting with 2.4, though I haven't actually tested older Python versions. It does not yet support Python 3.x. If it is accepted for the git project, then I would prepare a patch that drops the git-multimail project's git-multimail subdirectory into the git project as contrib/hooks/git-multimail and optionally deletes the old post-receive-email script. I am flexible about whether future development should occur directly in the git project's repository or in the git-multimail repo with occasional code drops to the git project. I am also flexible about whether the rough little test scripts should be included in the git project or kept separate. It would be very helpful if people would test this script in their own environments and give me feedback/bug reports. It is rather awkward to simulate all of the possible environment scenarios myself. Michael [1] http://thread.gmane.org/gmane.comp.version-control.git/201433 -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
