{"thread":{"id":"32740","subject":"[RFC v2] git-multimail: a replacement for post-receive-email","startedAt":"2013-01-27T08:37:12Z","lastAt":"2013-03-09T05:32:32Z","messageCount":17,"participants":["Michael Haggerty","Ævar Arnfjörð Bjarmason","Chris Hiestand","Matthieu Moy","Andy Parkins"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"207940","messageId":"5104E738.602@alum.mit.edu","threadId":"32740","inReplyTo":null,"subject":"[RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-01-27T08:37:12Z","receivedAt":"2013-01-27T08:37:12Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"A while ago, I submitted an RFC for adding a new email notification\nscript to \"contrib\" [1]. The reaction seemed favorable and it was\nsuggested that the new script should replace post-receive-email rather\nthan be added separately, ideally with some kind of migration support.\n\nI've been working on this on and off since then and I think it is time\nfor another iteration. I think I have addressed most of the points\nraised earlier, including a migration script and specific migration\ninstructions.\n\nReview of main advantages of git-multimail over post-receive-email:\n\n* Can (optionally) send a separate email for each new commit (in\naddition to the emails for each reference change).\n\n* More flexible configuration, including out-of-the-box support for\nrunning under gitolite.\n\n* Fixed algorithm for detecting \"new\" commits.\n\n* More information in emails (e.g., commit log subject lines, telling\nwhen a push discards old commits)j.\n\n* Written in Python rather than shell. Easier to extend.\n\nSummary of improvements since the first version:\n\n* Rename the project from the cumbersome \"post-receive-multimail.py\" to\n\"git-multimail\".\n\n* Push the project into a subdirectory and break it into multiple files\n(script, docs, etc).\n\n* Vastly improve the documentation and separate it out of the script\ninto a README file.\n\n* Add a migration script, migrate-mailhook-config, that converts a\npost-receive-email configuration into a git-multimail configuration.\nDocument the migration procedure and differences between the two scripts\nin README.migrate-from-post-receive-email.\n\n* Store the configuration options in namespace \"multimailhook.*\" rather\nthan \"hooks.*\". (The post-receive-email script's use of a too-generic\ntop-level name was IMHO a bad idea, so fix it now.)\n\n* Allow the feature of sending a separate email for each individual\ncommit to be turned off via a configuration option (to better support\npost-receive-email migrants).\n\n* Re-implement the feature of showing a short log of commits in\nannouncement emails, configurable via an option.\n\n* Make it possible to import the main code as a Python module to allow\nmost customization to be done via Python code without the need to edit\nthe original file. (Note for existing users: the Environment API has\nchanged since the original RFC, but I will try to keep it stable from\nnow on.)\n\n* Allow the config settings that define recipient lists to be multivalued.\n\n* Added some testing infrastructure (though the tests are still very\nlimited).\n\n* Add \"Auto-Submitted\" headers to emails (as implemented for\npost-receive-email by Chris Hiestand).\n\n* Add option to truncate email lines to a specified length (suggested by\nMatthieu Moy). By default, this option is *on* and set to 500 characters.\n\n* Add option to force the main part of the email body to be valid UTF-8,\nwith invalid characters turned into the Unicode replacement character,\nU+FFFD. By default, this option is *on* (arguments for turning it off\nby default are welcome).\n\nThe code is in its own GitHub repository:\n\n https://github.com/mhagger/git-multimail\n\nThe script should work with any Python 2.x starting with 2.4, though I\nhaven't actually tested older Python versions. It does not yet support\nPython 3.x.\n\nIf it is accepted for the git project, then I would prepare a patch that\ndrops the git-multimail project's \"git-multimail\" subdirectory into the\ngit project as contrib/hooks/git-multimail and optionally deletes the\nold post-receive-email script. I am flexible about whether future\ndevelopment should occur directly in the git project's repository or in\nthe git-multimail repo with occasional code drops to the git project. I\nam also flexible about whether the rough little test scripts should be\nincluded in the git project or kept separate.\n\nIt would be very helpful if people would test this script in their own\nenvironments and give me feedback/bug reports. It is rather awkward to\nsimulate all of the possible environment scenarios myself.\n\nMichael\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/201433\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"208190","messageId":"CACBZZX7RA7dLcFhaHmmK97Kxfa9zLmozfdx5s9C=29DJOceq-A@mail.gmail.com","threadId":"32740","inReplyTo":"5104E738.602@alum.mit.edu","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2013-01-29T15:25:49Z","receivedAt":"2013-01-29T15:25:49Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Jan 27, 2013 at 9:37 AM, Michael Haggerty wrote:\n> A while ago, I submitted an RFC for adding a new email notification\n> script to \"contrib\" [1]. The reaction seemed favorable and it was\n> suggested that the new script should replace post-receive-email rather\n> than be added separately, ideally with some kind of migration support.\n\nI just want to say since I think this thread hasn't been getting the\nattention it deserves: I'm all for this. I've used git-multimail and\nit's a joy to configure and extend compared to the existing hacky\nshellscript.\n\nI'm not running it at $work yet because I still need to write some\nextensions for to port some of of our local hacks to the old\nshellscript over.\n\nI fully support replacing the existing mailing script with\ngit-multimail, it's better in every way, and unlike the current script\nhas an active maintainer.\n"},{"id":"208236","messageId":"4D9815B7-983E-4963-875D-DB0059FFD811@salk.edu","threadId":"32740","inReplyTo":"CACBZZX7RA7dLcFhaHmmK97Kxfa9zLmozfdx5s9C=29DJOceq-A@mail.gmail.com","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Chris Hiestand","fromEmail":"chiestand@salk.edu","sentAt":"2013-01-30T02:27:17Z","receivedAt":"2013-01-30T02:27:17Z","isPatch":false,"sender":{"key":"chiestand@salk.edu","avatar":"https://avatars.githubusercontent.com/u/100825?v=4"},"body":"On Jan 29, 2013, at 7:25 AM, Ævar Arnfjörð Bjarmason wrote:\n\n> On Sun, Jan 27, 2013 at 9:37 AM, Michael Haggerty wrote:\n>> A while ago, I submitted an RFC for adding a new email notification\n>> script to \"contrib\" [1]. The reaction seemed favorable and it was\n>> suggested that the new script should replace post-receive-email rather\n>> than be added separately, ideally with some kind of migration support.\n> \n> I just want to say since I think this thread hasn't been getting the\n> attention it deserves: I'm all for this. I've used git-multimail and\n> it's a joy to configure and extend compared to the existing hacky\n> shellscript.\n\n\nThis seems good to me as long as it's okay for git contrib to depend on python.\nI've started testing git-multimail in my environment.\n\n"},{"id":"209470","messageId":"vpqtxpgb6ue.fsf@grenoble-inp.fr","threadId":"32740","inReplyTo":"5104E738.602@alum.mit.edu","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-13T14:56:25Z","receivedAt":"2013-02-13T14:56:25Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Michael Haggerty writes:\n\n> A while ago, I submitted an RFC for adding a new email notification\n> script to \"contrib\" [1]. The reaction seemed favorable and it was\n> suggested that the new script should replace post-receive-email rather\n> than be added separately, ideally with some kind of migration support.\n\nI think replacing the old post-receive-email is a sane goal in the long\nrun, but a good first step would be to have git-multimail merged in\ncontrib, and start considering the old script as deprecated (keeping the\nold script doesn't harm IMHO, it's a one-file, 3 commits/year script,\nnot really a maintainance burden).\n\nI started playing with git-multimail. In short, I do like it but had to\nfight a bit with python to get it to work, and couldn't get it to do\nexactly what I expect. Pull request attached :-).\n\n\nInstallation troubles:\n\nI had an old python installation (Red Hat package, and I'm not root),\nthat did not include the email.utils package, so I couldn't use my\nsystem's python. I found no indication about python version in README,\nso I installed the latest python by hand, just to find out that\ngit-multimail wasn't compatible with Python 3.x. 2to3 can fix\nautomatically a number of 3.x compatibility issues, but not all of them\nso I gave up and installed Python 2.7.\n\nI think adding a short \"dependencies\" section in the README (or in an\nINSTALL file) saying which Python version works could save new users the\ntrouble (I see the sheebang inside the scripts says python2 but since I\ncouldn't use my system's python and called\n\"path/to/python git_multimail.py\", this didn't help). Making the script\nportable with python 2 and 3 would be awesome ;-).\n\n\nMissing feature:\n\ngit-multimail can send a summary for each push, with the \"git log --oneline\"\nof the new revisions, and then 1 mail per patch with the complete log\nand the patch.\n\nI'd like to have the intermediate: allow the summary email to include\nthe complete log (not just --oneline). My colleagues already think they\nreceive too many emails so I don't think they'd like the \"one email per\ncommit\" way, but the 1 line summary is really short OTOH.\n\nI wrote a quick and hopefully not-too-dirty implementation of it,\nthere's a pull request here:\n\nhttps://github.com/mhagger/git-multimail/pull/6\n\nessentially, it boils down to:\n\n@@ -835,6 +837,17 @@ class ReferenceChange(Change):\n for line in self.expand_lines(NO_NEW_REVISIONS_TEMPLATE):\n yield line\n \n+ if adds and self.showlog:\n+ yield '\\n'\n+ yield 'Detailed log of added commits:\\n\\n'\n+ for line in read_lines(\n+ ['git', 'log']\n+ + self.logopts\n+ + ['%s..%s' % (self.old.commit, self.new.commit,)],\n+ keepends=True,\n+ ):\n+ yield line\n+\n # The diffstat is shown from the old revision to the new\n # revision. This is to show the truth of what happened in\n # this change. There's no point showing the stat from the\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"209471","messageId":"201302131526.57342.andyparkins@gmail.com","threadId":"32740","inReplyTo":"vpqtxpgb6ue.fsf@grenoble-inp.fr","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2013-02-13T15:26:57Z","receivedAt":"2013-02-13T15:26:57Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 13 February 2013 14:56:25 Matthieu Moy wrote:\n> Michael Haggerty writes:\n\n> I think adding a short \"dependencies\" section in the README (or in an\n> INSTALL file) saying which Python version works could save new users the\n> trouble (I see the sheebang inside the scripts says python2 but since I\n> couldn't use my system's python and called\n> \"path/to/python git_multimail.py\", this didn't help). Making the script\n> portable with python 2 and 3 would be awesome ;-).\n\nFor my 2p worth, I don't like seeing hooks called like this. Particular those \nthat come as part of the standard installation.\n\nI call mine by installing little scripts like this (on Debian):\n\n #!/bin/sh\n # stored as $GIT_WORK_DIR/.git/hooks/post-receive-email\n exec /bin/sh /usr/share/git-core/contrib/hooks/post-receive-email\n\nThis means I don't have to make the sample script executable, it gets upgraded \nautomatically as git gets upgraded, and the interpreter is easily changed by \nchanging a file in my work directory, rather than altering a packaged file.\n\nI'd prefer to see the /usr/share/git-core/templates/hooks/ using a similar \ntechnique, as to my mind, installing a full copy of the sample script in every \nnew repository is wasteful and leaves you with potentially out-of-date scripts \nwhen you update git.\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins@gmail.com\n"},{"id":"209477","messageId":"vpqbobo5h2e.fsf@grenoble-inp.fr","threadId":"32740","inReplyTo":"201302131526.57342.andyparkins@gmail.com","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-13T16:12:09Z","receivedAt":"2013-02-13T16:12:09Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Andy Parkins writes:\n\n> On Wednesday 13 February 2013 14:56:25 Matthieu Moy wrote:\n>> Michael Haggerty writes:\n>\n>> I think adding a short \"dependencies\" section in the README (or in an\n>> INSTALL file) saying which Python version works could save new users the\n>> trouble (I see the sheebang inside the scripts says python2 but since I\n>> couldn't use my system's python and called\n>> \"path/to/python git_multimail.py\", this didn't help). Making the script\n>> portable with python 2 and 3 would be awesome ;-).\n>\n> For my 2p worth, I don't like seeing hooks called like this. Particular those \n> that come as part of the standard installation.\n\nWhat do you mean by \"like this\" ?\n\n> I call mine by installing little scripts like this (on Debian):\n>\n> #!/bin/sh\n> # stored as $GIT_WORK_DIR/.git/hooks/post-receive-email\n> exec /bin/sh /usr/share/git-core/contrib/hooks/post-receive-email\n\nYes, this is what I was doing (with path/to/python instead of /bin/sh,\nand git_multimail.py, or more precisely path/to/git_multimail.py,\ninstead of post-receive-email).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"209499","messageId":"511C08AF.7090502@alum.mit.edu","threadId":"32740","inReplyTo":"vpqtxpgb6ue.fsf@grenoble-inp.fr","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-02-13T21:42:07Z","receivedAt":"2013-02-13T21:42:07Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/13/2013 03:56 PM, Matthieu Moy wrote:\n> Michael Haggerty writes:\n> \n>> A while ago, I submitted an RFC for adding a new email notification\n>> script to \"contrib\" [1]. The reaction seemed favorable and it was\n>> suggested that the new script should replace post-receive-email rather\n>> than be added separately, ideally with some kind of migration support.\n> \n> I think replacing the old post-receive-email is a sane goal in the long\n> run, but a good first step would be to have git-multimail merged in\n> contrib, and start considering the old script as deprecated (keeping the\n> old script doesn't harm IMHO, it's a one-file, 3 commits/year script,\n> not really a maintainance burden).\n> \n> I started playing with git-multimail. In short, I do like it but had to\n> fight a bit with python to get it to work, and couldn't get it to do\n> exactly what I expect. Pull request attached :-).\n\nThanks very much for your feedback and patches.\n\n> Installation troubles:\n> \n> I had an old python installation (Red Hat package, and I'm not root),\n> that did not include the email.utils package, so I couldn't use my\n> system's python. I found no indication about python version in README,\n> so I installed the latest python by hand, just to find out that\n> git-multimail wasn't compatible with Python 3.x. 2to3 can fix\n> automatically a number of 3.x compatibility issues, but not all of them\n> so I gave up and installed Python 2.7.\n\nWhat version of Python was it that caused problems? I just discovered\nthat the script wouldn't have worked with Python 2.4, where\n\"email.utils\" used to be called \"email.Utils\". But I pushed a fix to\nGitHub:\n\n ddb1796660 Accommodate older versions of Python's email module.\n\nWith this change, I think that git-multimail will work with any version\nof Python 2.4 <= x < 3.0. So if your original problem was with Python\n2.4, maybe you could try the new version and see if it works with that\ninterpreter.\n\n> I think adding a short \"dependencies\" section in the README (or in an\n> INSTALL file) saying which Python version works could save new users the\n> trouble (I see the sheebang inside the scripts says python2 but since I\n> couldn't use my system's python and called\n> \"path/to/python git_multimail.py\", this didn't help).\n\nYes, I'm working on a \"Requirements\" section with that information and\nmore. I'd like to list a minimum git version too, but it would be quite\na bit of work to figure out when each command and each option was added.\n It would be helpful if anybody who has used the script with an old\nversion of git lets me know whether they were successful or not.\n\n> Making the script\n> portable with python 2 and 3 would be awesome ;-).\n\nAgreed, but I doubt I will be able to get to it very soon.\n\n> Missing feature:\n> \n> git-multimail can send a summary for each push, with the \"git log --oneline\"\n> of the new revisions, and then 1 mail per patch with the complete log\n> and the patch.\n> \n> I'd like to have the intermediate: allow the summary email to include\n> the complete log (not just --oneline). My colleagues already think they\n> receive too many emails so I don't think they'd like the \"one email per\n> commit\" way, but the 1 line summary is really short OTOH.\n> \n> I wrote a quick and hopefully not-too-dirty implementation of it,\n> there's a pull request here:\n> \n> https://github.com/mhagger/git-multimail/pull/6\n> \n> essentially, it boils down to:\n> \n> @@ -835,6 +837,17 @@ class ReferenceChange(Change):\n> for line in self.expand_lines(NO_NEW_REVISIONS_TEMPLATE):\n> yield line\n> \n> + if adds and self.showlog:\n> + yield '\\n'\n> + yield 'Detailed log of added commits:\\n\\n'\n> + for line in read_lines(\n> + ['git', 'log']\n> + + self.logopts\n> + + ['%s..%s' % (self.old.commit, self.new.commit,)],\n> + keepends=True,\n> + ):\n> + yield line\n> +\n> # The diffstat is shown from the old revision to the new\n> # revision. This is to show the truth of what happened in\n> # this change. There's no point showing the stat from the\n> \n\nThanks for the patch. I like the idea, but I think the implementation\nis incorrect. Your code will not only list new commits but will also\nlist commits that were already in the repository on another branch\n(e.g., if an existing feature branch is merged into master, all of the\ncommits on the feature branch will be listed). (Or was that your\nintention?) But even worse, it will fail to list commits that were\nadded at the same time that a branch was created (e.g., if I create a\nfeature branch with a number of commits on it and then push it for the\nfirst time).\n\nProbably the Push object has to negotiate with its constituent\nReferenceChange objects to figure out which one is responsible for\nsummarizing each of the commits newly added by the push (i.e., the ones\nreturned by push.get_new_commits(None)).\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"209514","messageId":"vpq7gmbdpi2.fsf@grenoble-inp.fr","threadId":"32740","inReplyTo":"511C08AF.7090502@alum.mit.edu","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-14T12:55:01Z","receivedAt":"2013-02-14T12:55:01Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Michael Haggerty writes:\n\n> On 02/13/2013 03:56 PM, Matthieu Moy wrote:\n>\n>> Installation troubles:\n>> \n>> I had an old python installation (Red Hat package, and I'm not root),\n>> that did not include the email.utils package, so I couldn't use my\n>> system's python. I found no indication about python version in README,\n>> so I installed the latest python by hand, just to find out that\n>> git-multimail wasn't compatible with Python 3.x. 2to3 can fix\n>> automatically a number of 3.x compatibility issues, but not all of them\n>> so I gave up and installed Python 2.7.\n>\n> What version of Python was it that caused problems?\n\nPython 2.4.3, installed with RHEL 5.9.\n\n> I just discovered that the script wouldn't have worked with Python\n> 2.4, where \"email.utils\" used to be called \"email.Utils\".\n\nIndeed, \"import email.Utils\" works with this Python.\n\n> But I pushed a fix to GitHub:\n>\n> ddb1796660 Accommodate older versions of Python's email module.\n\nNot sufficient, but I added a pull request that works for me with 2.4.\n\n>> @@ -835,6 +837,17 @@ class ReferenceChange(Change):\n>> for line in self.expand_lines(NO_NEW_REVISIONS_TEMPLATE):\n>> yield line\n>> \n>> + if adds and self.showlog:\n>> + yield '\\n'\n>> + yield 'Detailed log of added commits:\\n\\n'\n>> + for line in read_lines(\n>> + ['git', 'log']\n>> + + self.logopts\n>> + + ['%s..%s' % (self.old.commit, self.new.commit,)],\n>> + keepends=True,\n>> + ):\n>> + yield line\n>> +\n>> # The diffstat is shown from the old revision to the new\n>> # revision. This is to show the truth of what happened in\n>> # this change. There's no point showing the stat from the\n>> \n>\n> Thanks for the patch. I like the idea, but I think the implementation\n> is incorrect. Your code will not only list new commits but will also\n> list commits that were already in the repository on another branch\n> (e.g., if an existing feature branch is merged into master, all of the\n> commits on the feature branch will be listed). (Or was that your\n> intention?)\n\nI did not think very carefully about this case, but the behavior of my\ncode seems sensible (although not uncontroversial): it's just showing\nthe detailed log for the same commits as the summary at the top of the\nemail. I have no personnal preferences.\n\n> But even worse, it will fail to list commits that were\n> added at the same time that a branch was created (e.g., if I create a\n> feature branch with a number of commits on it and then push it for the\n> first time).\n\nRight.\n\n> Probably the Push object has to negotiate with its constituent\n> ReferenceChange objects to figure out which one is responsible for\n> summarizing each of the commits newly added by the push (i.e., the ones\n> returned by push.get_new_commits(None)).\n\nI updated the pull request with a version that works for new branches,\nand takes the list of commits to display from the call to\nget_new_commits (which were already there for other purpose). Then, it\nessentially calls \"git log --no-walk $list_of_sha1s\".\n\nThis should be better.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"209547","messageId":"511DC28C.1080104@alum.mit.edu","threadId":"32740","inReplyTo":"vpq7gmbdpi2.fsf@grenoble-inp.fr","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-02-15T05:07:24Z","receivedAt":"2013-02-15T05:07:24Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/14/2013 01:55 PM, Matthieu Moy wrote:\n> Michael Haggerty writes:\n> \n>> On 02/13/2013 03:56 PM, Matthieu Moy wrote:\n>>\n>>> Installation troubles:\n>>>\n>>> I had an old python installation (Red Hat package, and I'm not root),\n>>> that did not include the email.utils package, so I couldn't use my\n>>> system's python. I found no indication about python version in README,\n>>> so I installed the latest python by hand, just to find out that\n>>> git-multimail wasn't compatible with Python 3.x. 2to3 can fix\n>>> automatically a number of 3.x compatibility issues, but not all of them\n>>> so I gave up and installed Python 2.7.\n>>\n>> What version of Python was it that caused problems?\n> \n> Python 2.4.3, installed with RHEL 5.9.\n> \n>> I just discovered that the script wouldn't have worked with Python\n>> 2.4, where \"email.utils\" used to be called \"email.Utils\".\n> \n> Indeed, \"import email.Utils\" works with this Python.\n> \n>> But I pushed a fix to GitHub:\n>>\n>> ddb1796660 Accommodate older versions of Python's email module.\n> \n> Not sufficient, but I added a pull request that works for me with 2.4.\n> \n>>> @@ -835,6 +837,17 @@ class ReferenceChange(Change):\n>>> for line in self.expand_lines(NO_NEW_REVISIONS_TEMPLATE):\n>>> yield line\n>>> \n>>> + if adds and self.showlog:\n>>> + yield '\\n'\n>>> + yield 'Detailed log of added commits:\\n\\n'\n>>> + for line in read_lines(\n>>> + ['git', 'log']\n>>> + + self.logopts\n>>> + + ['%s..%s' % (self.old.commit, self.new.commit,)],\n>>> + keepends=True,\n>>> + ):\n>>> + yield line\n>>> +\n>>> # The diffstat is shown from the old revision to the new\n>>> # revision. This is to show the truth of what happened in\n>>> # this change. There's no point showing the stat from the\n>>>\n>>\n>> Thanks for the patch. I like the idea, but I think the implementation\n>> is incorrect. Your code will not only list new commits but will also\n>> list commits that were already in the repository on another branch\n>> (e.g., if an existing feature branch is merged into master, all of the\n>> commits on the feature branch will be listed). (Or was that your\n>> intention?)\n> \n> I did not think very carefully about this case, but the behavior of my\n> code seems sensible (although not uncontroversial): it's just showing\n> the detailed log for the same commits as the summary at the top of the\n> email. I have no personnal preferences.\n\nI guess it depends a lot on what logopts are used. If the user\nconfigures logopts to emit full patches, then the repeated reporting of\nthe same commits would cause a big increase in the bulk of notification\nemails. But if the logopts are set to just emit a brief summary (e.g.,\nauthor and log message), then a bit of repetition might be acceptable.\nBut since I wouldn't use this feature, I don't personally have a preference.\n\n>> But even worse, it will fail to list commits that were\n>> added at the same time that a branch was created (e.g., if I create a\n>> feature branch with a number of commits on it and then push it for the\n>> first time).\n> \n> Right.\n> \n>> Probably the Push object has to negotiate with its constituent\n>> ReferenceChange objects to figure out which one is responsible for\n>> summarizing each of the commits newly added by the push (i.e., the ones\n>> returned by push.get_new_commits(None)).\n> \n> I updated the pull request with a version that works for new branches,\n> and takes the list of commits to display from the call to\n> get_new_commits (which were already there for other purpose). Then, it\n> essentially calls \"git log --no-walk $list_of_sha1s\".\n> \n> This should be better.\n\nI will check it out.\n\nThanks!\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"209909","messageId":"vpqfw0rb25c.fsf@grenoble-inp.fr","threadId":"32740","inReplyTo":"5104E738.602@alum.mit.edu","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-20T12:28:15Z","receivedAt":"2013-02-20T12:28:15Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Michael Haggerty writes:\n\n> A while ago, I submitted an RFC for adding a new email notification\n> script to \"contrib\" [1]. \n\nWe've discussed offline with Michael, a few patches have been merged,\nand there are still a few pending pull requests. I liked the script\nalready, but it's getting even cooler ;-).\n\nA few more random thoughts (not on my personal todo-list):\n\n* It may make sense to add the short sha1 of the new reference in email\n titles (branch foo updated -> branch foo updated to $sha1), so that\n gmail users do not get a single huge thread \"branch foo updated\".\n\n (Yes, I do know about the Reference field, but gmail uses Subject: for\n threading).\n\n* Perhaps we should allow a per-branch configuration, like\n\n [multimailhook]\n\tmailingList = some@list.com\n [multimailhook \"refs/heads/my-branch\"]\n mailingList = some-other@list.com\n = \n\n Branch specific would override value for Config.get(), and\n Config.get_all() should probably list both the branch-specific and the\n other keys.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"210167","messageId":"5129A5B3.7020807@alum.mit.edu","threadId":"32740","inReplyTo":"vpqfw0rb25c.fsf@grenoble-inp.fr","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-02-24T05:31:31Z","receivedAt":"2013-02-24T05:31:31Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/20/2013 01:28 PM, Matthieu Moy wrote:\n> Michael Haggerty writes:\n>> A while ago, I submitted an RFC for adding a new email notification\n>> script to \"contrib\" [...]\n> \n> We've discussed offline with Michael, a few patches have been merged,\n> and there are still a few pending pull requests. I liked the script\n> already, but it's getting even cooler ;-).\n> \n> A few more random thoughts (not on my personal todo-list):\n> \n> * It may make sense to add the short sha1 of the new reference in email\n> titles (branch foo updated -> branch foo updated to $sha1), so that\n> gmail users do not get a single huge thread \"branch foo updated\".\n> \n> (Yes, I do know about the Reference field, but gmail uses Subject: for\n> threading).\n> [...]\n\nI just implemented this in branch sha1s-in-subject [1]. Please let me\nknow if this works for you then I'll merge it to master. (It depends on\nthe header-handling branch, which also includes your patch for non-ASCII\nheader fields.)\n\nMichael\n\n[1] https://github.com/mhagger/git-multimail/tree/sha1s-in-subject\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"210168","messageId":"5129AAEB.5080007@alum.mit.edu","threadId":"32740","inReplyTo":"vpqfw0rb25c.fsf@grenoble-inp.fr","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-02-24T05:53:47Z","receivedAt":"2013-02-24T05:53:47Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/20/2013 01:28 PM, Matthieu Moy wrote:\n> Michael Haggerty writes:\n>> A while ago, I submitted an RFC for adding a new email notification\n>> script to \"contrib\" [...]\n> \n> We've discussed offline with Michael, a few patches have been merged,\n> and there are still a few pending pull requests. I liked the script\n> already, but it's getting even cooler ;-).\n> \n> A few more random thoughts (not on my personal todo-list):\n> \n> [...]\n> \n> * Perhaps we should allow a per-branch configuration, like\n> \n> [multimailhook]\n> \tmailingList = some@list.com\n> [multimailhook \"refs/heads/my-branch\"]\n> mailingList = some-other@list.com\n> = \n> \n> Branch specific would override value for Config.get(), and\n> Config.get_all() should probably list both the branch-specific and the\n> other keys.\n\nI wonder whether it would be to far off the beaten path to allow glob\npatterns in the branch specification; e.g.,\n\n [multimailhook \"refs/heads/release-*\"]\n mailingList = qa@example.com\n\nFor the case of multiple glob patterns matching a branch name, there\nwould probably have to be a notion of \"best match\", but that doesn't\nseem too difficult. The matching would have to take place when looking\nup individual options to avoid having to replicate the full\nconfiguration for each pattern.\n\nThis feature could also be used to get the functionality of your\nproposal for skipRefs and onlyRefs [1] in a more general way:\n\n [multimailhook]\n mailingList = some@example.com\n [multimailhook \"refs/heads/user/$USER/*\"]\n mailingList = \"\"\n\nMichael\n\n[1] Proposed feature to allow certain references to be ignored for the\npurpose of notification emails; see\n\n https://github.com/mhagger/git-multimail/pull/15\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"210241","messageId":"vpqd2vok9bv.fsf@grenoble-inp.fr","threadId":"32740","inReplyTo":"5129A5B3.7020807@alum.mit.edu","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-25T09:54:12Z","receivedAt":"2013-02-25T09:54:12Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Michael Haggerty writes:\n\n> On 02/20/2013 01:28 PM, Matthieu Moy wrote:\n>> Michael Haggerty writes:\n>>> A while ago, I submitted an RFC for adding a new email notification\n>>> script to \"contrib\" [...]\n>> \n>> We've discussed offline with Michael, a few patches have been merged,\n>> and there are still a few pending pull requests. I liked the script\n>> already, but it's getting even cooler ;-).\n>> \n>> A few more random thoughts (not on my personal todo-list):\n>> \n>> * It may make sense to add the short sha1 of the new reference in email\n>> titles (branch foo updated -> branch foo updated to $sha1), so that\n>> gmail users do not get a single huge thread \"branch foo updated\".\n>> \n>> (Yes, I do know about the Reference field, but gmail uses Subject: for\n>> threading).\n>> [...]\n>\n> I just implemented this in branch sha1s-in-subject [1]. Please let me\n> know if this works for you then I'll merge it to master. (It depends on\n> the header-handling branch, which also includes your patch for non-ASCII\n> header fields.)\n\nWorks for me. One minor knit: you've included 10-characters sha1s (this\ncomes from\n\n self.short = read_output(['git', 'rev-parse', '--short=10', sha1])\n\n), I'd find it better with shorter sha1s. In the case of branch update,\nif the branch name is a bit long, it could be nice to save a few\ncharacters.\n\nWhy not just say \"git rev-parse --short\", without argument? This way,\nthe default is used, ie. AFAICT it uses 7 characters by default, but\nwill use more if needed to keep the unicity.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"210242","messageId":"vpqzjysiufm.fsf@grenoble-inp.fr","threadId":"32740","inReplyTo":"5129AAEB.5080007@alum.mit.edu","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-02-25T10:01:17Z","receivedAt":"2013-02-25T10:01:17Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Michael Haggerty writes:\n\n> I wonder whether it would be to far off the beaten path to allow glob\n> patterns in the branch specification; e.g.,\n>\n> [multimailhook \"refs/heads/release-*\"]\n> mailingList = qa@example.com\n\nYes, that would be even better.\n\n> For the case of multiple glob patterns matching a branch name, there\n> would probably have to be a notion of \"best match\", but that doesn't\n> seem too difficult.\n\nI'd rather have a simple rule here like \"last one wins\" or so. Saying\nthat foo-bar-* is a better match than foo-* may be easy, but you can\nhardly avoid having corner-cases like foo-*-boz vs foo-bar-* when\nmatching foo-bar-boz.\n\n> This feature could also be used to get the functionality of your\n> proposal for skipRefs and onlyRefs [1] in a more general way:\n>\n> [multimailhook]\n> mailingList = some@example.com\n> [multimailhook \"refs/heads/user/$USER/*\"]\n> mailingList = \"\"\n\nYes, I thougth about that, but it is not only \"more general\", but also\n\"less conveinient\":\n\n [multimailhook]\n mailingList = some@example.com\n refchangelist = other@example.com\n [multimailhook \"refs/heads/user/$USER/*\"]\n mailingList = \"\"\n # Oops, forgot to override refchangelist, the mail will still\n # be sent.\n\nSo skipRefs and onlyRefs would still make sense IMHO.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"210244","messageId":"512B4203.3090802@alum.mit.edu","threadId":"32740","inReplyTo":"vpqd2vok9bv.fsf@grenoble-inp.fr","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-02-25T10:50:43Z","receivedAt":"2013-02-25T10:50:43Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/25/2013 10:54 AM, Matthieu Moy wrote:\n> Michael Haggerty writes:\n> \n>> On 02/20/2013 01:28 PM, Matthieu Moy wrote:\n>>> Michael Haggerty writes:\n>>>> A while ago, I submitted an RFC for adding a new email notification\n>>>> script to \"contrib\" [...]\n>>>\n>>> We've discussed offline with Michael, a few patches have been merged,\n>>> and there are still a few pending pull requests. I liked the script\n>>> already, but it's getting even cooler ;-).\n>>>\n>>> A few more random thoughts (not on my personal todo-list):\n>>>\n>>> * It may make sense to add the short sha1 of the new reference in email\n>>> titles (branch foo updated -> branch foo updated to $sha1), so that\n>>> gmail users do not get a single huge thread \"branch foo updated\".\n>>>\n>>> (Yes, I do know about the Reference field, but gmail uses Subject: for\n>>> threading).\n>>> [...]\n>>\n>> I just implemented this in branch sha1s-in-subject [1]. Please let me\n>> know if this works for you then I'll merge it to master. (It depends on\n>> the header-handling branch, which also includes your patch for non-ASCII\n>> header fields.)\n> \n> Works for me. One minor knit: you've included 10-characters sha1s (this\n> comes from\n> \n> self.short = read_output(['git', 'rev-parse', '--short=10', sha1])\n> \n> ), I'd find it better with shorter sha1s. In the case of branch update,\n> if the branch name is a bit long, it could be nice to save a few\n> characters.\n> \n> Why not just say \"git rev-parse --short\", without argument? This way,\n> the default is used, ie. AFAICT it uses 7 characters by default, but\n> will use more if needed to keep the unicity.\n\nI did this intentionally because the SHA1s appear in columns within the\nrefchange emails, and having varying-length SHA1s would cause subsequent\ncolumns to be misaligned. I figured that a length of 10, aside from\nbeing a number that I can still count on my fingers, would be long\nenough that it would rarely have to be extended.\n\nI guess I will change the code to use $(git rev-parse --short) (i.e.,\nshorter SHA1s) but reserving 10 columns in tables for them (which can be\ndone via Python string formatting in the templates). That should give\nthe best of both worlds.\n\nThanks for the feedback!\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"210572","messageId":"vpqhakrtuf9.fsf@grenoble-inp.fr","threadId":"32740","inReplyTo":"vpqfw0rb25c.fsf@grenoble-inp.fr","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-03-04T08:56:26Z","receivedAt":"2013-03-04T08:56:26Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Matthieu Moy writes:\n\n> A few more random thoughts (not on my personal todo-list):\n\nOne more:\n\nWhen sending commit emails, it may help to ensure that the dates are\nstrictly monotonic, so that the thread is seen in the right order.\n\nIIRC, \"git send-email\" does this by tweaking the Date: field to make\nsure there is at least one second between two emails (although they may\nbe actually sent at the same second). It would be cool to have the same\nfor git multimail.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"210872","messageId":"513AC970.6030502@alum.mit.edu","threadId":"32740","inReplyTo":"512B4203.3090802@alum.mit.edu","subject":"Re: [RFC v2] git-multimail: a replacement for post-receive-email","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-03-09T05:32:32Z","receivedAt":"2013-03-09T05:32:32Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/25/2013 11:50 AM, Michael Haggerty wrote:\n> On 02/25/2013 10:54 AM, Matthieu Moy wrote:\n>> [...] Works for me. One minor knit: you've included 10-characters sha1s (this\n>> comes from\n>>\n>> self.short = read_output(['git', 'rev-parse', '--short=10', sha1])\n>>\n>> ), I'd find it better with shorter sha1s. In the case of branch update,\n>> if the branch name is a bit long, it could be nice to save a few\n>> characters.\n>>\n>> Why not just say \"git rev-parse --short\", without argument? This way,\n>> the default is used, ie. AFAICT it uses 7 characters by default, but\n>> will use more if needed to keep the unicity.\n> \n> [...] I guess I will change the code to use $(git rev-parse --short) (i.e.,\n> shorter SHA1s) but reserving 10 columns in tables for them (which can be\n> done via Python string formatting in the templates). That should give\n> the best of both worlds.\n\nI implemented this change (allow git to choose the SHA1 abbreviation\nlength) and just pushed it to github.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"}]}