{"thread":{"id":"33560","subject":"[PATCH v3 0/1] git-multimail: a replacement for post-receive-email","startedAt":"2013-04-21T10:49:39Z","lastAt":"2013-04-21T22:28:35Z","messageCount":7,"participants":["Michael Haggerty","Jonathan Nieder","Junio C Hamano"],"isPatch":true,"patchVersion":3,"patchTotal":1},"messages":[{"id":"215007","messageId":"1366541380-10786-1-git-send-email-mhagger@alum.mit.edu","threadId":"33560","inReplyTo":null,"subject":"[PATCH v3 0/1] git-multimail: a replacement for post-receive-email","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-04-21T10:49:39Z","receivedAt":"2013-04-21T10:49:39Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"This is the third iteration of submitting git-multimail to Git. The\nfirst pass [1] was a modest trial balloon, proposing to add a new\nscript to live alongside post-receive-email. Following feedback [2]\nfrom the mailing list, I decided to make the script a full replacement\nfor post-receive-email (and renamed it from post-receive-multimail.py\nto git-multimail). The second pass [3] was an RFC that generated a\nlot of useful feedback, some requests for better support of old\nfeatures (mostly implemented), and some contributions by other members\nof the community (especially Matthieu Moy). The overall reaction to\ngit-multimail as a replacement for post-receive-email has been quite\npositive.\n\nNow I believe that git-multimail is ripe for inclusion in contrib.\nIts features are documented in the README file and its advantages over\npost-receive-email are documented in the file\nREADME.migrate-from-post-receive-email.\n\nThis series consists of a single patch that adds a directory\ncontrib/hooks/git-multimail/ containing five files, described in the\npatch's commit message. It does *not* deprecate post-receive-email,\nlet alone remove it, though I hope that both of those steps will be\nwarranted in time.\n\nIf there is consensus that git-multimail should be integrated into the\nGit project, there are some logistical issues that need to be\ndiscussed:\n\n* Code drop versus merge?\n\n * The first 170 commits to git-multimerge took place in a private\n repository, commingled with other material. All of these commits\n were by me. I don't have time to sanitize these commits into a\n publishable history, so I'm afraid that part of the history will\n never become public.\n\n * The subsequent 200 commits of the history have been published to\n GitHub [4]. (The version that I am submitting corresponds to the\n git-multimail subtree of revision\n c06a1af5d3a9dfbac7eb704dc8e15a2aee60a334 of that repository.)\n These commits are reasonably clean, though definitely not up to\n the usual Git project standards. The first of these commits\n consists of a code drop from the private repository just\n mentioned. The recent part of this history includes commits by\n other authors.\n\n Would it be preferable to merge the last 200 commits of the\n git-multimail history into the Git project (presumably via subtree\n merge), or just to incorporate it as a single, squashed patch?\n\n* What to include? The GitHub repo contains some infrastructure\n outside of the git-multimail directory, which is not included in\n this patch series:\n\n .gitignore, COPYING -- redundant with the Git project's\n top-level files.\n\n MANIFEST.in, setup.py -- infrastructure for Python's setuptools\n (to allow git-multimail to be packaged as a Python module,\n probably irrelevant in the context of the Git project.\n\n README -- a symlink to git-multimail/README.\n\n t/ -- some crude scripts and data that I have been using for\n testing. The tests are largely manual, so it is not clear\n whether they would be helpful within the Git project.\n\n notes.txt -- TODO list etc.\n\n* How to organize future development? Directly in the Git repo, using\n the git mailing list, etc? As a fork of the Git project that\n occasionally issues patches and/or pull requests to the main\n project? Or as a separate project that does not include the whole\n Git tree, which is occasionally merged back to the Git project using\n subtree merge?\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/201433\n[2] http://article.gmane.org/gmane.comp.version-control.git/201471\n[3] http://article.gmane.org/gmane.comp.version-control.git/214686\n[4] https://github.com/mhagger/git-multimail\n\nMichael Haggerty (1):\n git-multimail: a replacement for post-receive-email\n\n contrib/hooks/git-multimail/README | 410 ++++\n .../README.migrate-from-post-receive-email | 146 ++\n contrib/hooks/git-multimail/git_multimail.py | 2126 ++++++++++++++++++++\n .../hooks/git-multimail/migrate-mailhook-config | 270 +++\n contrib/hooks/git-multimail/post-receive | 66 +\n 5 files changed, 3018 insertions(+)\n create mode 100644 contrib/hooks/git-multimail/README\n create mode 100644 contrib/hooks/git-multimail/README.migrate-from-post-receive-email\n create mode 100755 contrib/hooks/git-multimail/git_multimail.py\n create mode 100755 contrib/hooks/git-multimail/migrate-mailhook-config\n create mode 100755 contrib/hooks/git-multimail/post-receive\n\n-- \n1.8.2.1\n"},{"id":"215008","messageId":"20130421105612.GA28959@elie.Belkin","threadId":"33560","inReplyTo":"1366541380-10786-1-git-send-email-mhagger@alum.mit.edu","subject":"Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-21T10:56:12Z","receivedAt":"2013-04-21T10:56:12Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nMichael Haggerty wrote:\n\n> This series consists of a single patch that adds a directory\n> contrib/hooks/git-multimail/ containing five files, described in the\n> patch's commit message.\n\nYay! I look forward to seeing it.\n\n[...]\n> The first of these commits\n> consists of a code drop from the private repository just\n> mentioned. The recent part of this history includes commits by\n> other authors.\n\nThat could be a reason to do a subtree merge if you want. A code drop\nwith a commit message that acknowledges the contributors would also\npresumably be fine.\n\n[...]\n> * How to organize future development? Directly in the Git repo, using\n> the git mailing list, etc? As a fork of the Git project that\n> occasionally issues patches and/or pull requests to the main\n> project? Or as a separate project that does not include the whole\n> Git tree, which is occasionally merged back to the Git project using\n> subtree merge?\n\nMy personal preference is that patches come on the git list, are\nreviewed here, and then go to your fork of the Git project that Junio\ncan periodically pull from at your request (like git-svn). But of\ncourse this is up to you, too.\n\nThanks,\nJonathan\n"},{"id":"215009","messageId":"20130421110707.GB28959@elie.Belkin","threadId":"33560","inReplyTo":"1366541380-10786-2-git-send-email-mhagger@alum.mit.edu","subject":"Re: [PATCH v3 1/1] git-multimail: a replacement for post-receive-email","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-21T11:07:07Z","receivedAt":"2013-04-21T11:07:07Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michael Haggerty wrote:\n\n> Add git-multimail, a tool for generating notification emails for\n> pushes to a Git repository. It is largely plug-in compatible with\n> post-receive-email, and is proposed to eventually replace that script.\n> The advantages of git-multimail relative to post-receive-email are\n> described in README.migrate-from-post-receive-email.\n\nVery nice.\n\nFor what it's worth, I'd be happy to see this in contrib/. It is good\nto see an actively maintained analog to post-receive-email, and the\none-mail-per-commit functionality looks fun and useful.\n\nJonathan\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/137426\n"},{"id":"215026","messageId":"7vhaizu3j5.fsf@alter.siamese.dyndns.org","threadId":"33560","inReplyTo":"20130421105612.GA28959@elie.Belkin","subject":"Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-21T18:44:46Z","receivedAt":"2013-04-21T18:44:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> My personal preference is that patches come on the git list, are\n> reviewed here, and then go to your fork of the Git project that Junio\n> can periodically pull from at your request (like git-svn). But of\n> course this is up to you, too.\n\nAnd also me ;-)\n\nYes, I very much prefer the way how git-svn is managed.\n"},{"id":"215031","messageId":"517445E5.3080304@alum.mit.edu","threadId":"33560","inReplyTo":"7vhaizu3j5.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-04-21T20:02:45Z","receivedAt":"2013-04-21T20:02:45Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 04/21/2013 08:44 PM, Junio C Hamano wrote:\n> Jonathan Nieder writes:\n> \n>> My personal preference is that patches come on the git list, are\n>> reviewed here, and then go to your fork of the Git project that Junio\n>> can periodically pull from at your request (like git-svn). But of\n>> course this is up to you, too.\n> \n> And also me ;-)\n> \n> Yes, I very much prefer the way how git-svn is managed.\n\nLet me see if I understand what that means:\n\n* I maintain my own Git clone\n\n* Patches to git-multimail would go to the Git mailing list like patches\nto other patches to the Git project, but I would be the one to git-am\nthem, monitor discussion, help with review, etc. I would presumably\napply the patches near your master (or near maint when necessary).\n\n* When I think a batch of patches is ready, I merge them to my master\nand publish my master somewhere. (Or is it better I publish the feature\nbranch and leave it to you to merge directly to your master?) Then I\nsend a merge request to you and the Git mailing list with the URL and\nSHA-1 of the branch that I would like you to merge.\n\nThat seems very workable.\n\nWhat is your preference regarding the history to date?\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"215043","messageId":"7va9orsfd7.fsf@alter.siamese.dyndns.org","threadId":"33560","inReplyTo":"517445E5.3080304@alum.mit.edu","subject":"Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-21T22:12:04Z","receivedAt":"2013-04-21T22:12:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> That seems very workable.\n\nThat is pretty much it.\n\n> What is your preference regarding the history to date?\n\nThe only thing I deeply care about is that initial and subsequent\n\"git pull\" I'll do from you [*1*] will pull in commits that touch\nonly the \"multimail\" part in the contrib/ area and not mixed with\nunrelated changes to other areas.\n\nIf the history you have so far would later help others learn the\nmotivation, design, constraints etc. while developing it, which\ncannot be easily read from the resulting code, i.e. help maintaining\nit in general, it's a good idea to keep it. In such a case,\nhowever, people may want to review that history as well.\n\nIf it is the \"oops, it didn't work, let's try another\" kind of\n\"record as we build\" type of history that may not help the future\nmaintainace that much, you may instead want to start with a single\ncode-dump \"here is the first public version\" (which is reviewed in\nthis thread, I think) without the history behind it.\n\nYour choice, in other words ;-)\n\n\n[Footnote]\n\n*1* This does not even have to be a stable URL I would place in\nremote.multimail.url configuration; it does not even have to be a\nnon-rewinding tree.\n"},{"id":"215044","messageId":"7v61zfselo.fsf@alter.siamese.dyndns.org","threadId":"33560","inReplyTo":"517445E5.3080304@alum.mit.edu","subject":"Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-21T22:28:35Z","receivedAt":"2013-04-21T22:28:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> * When I think a batch of patches is ready, I merge them to my master\n> and publish my master somewhere. (Or is it better I publish the feature\n> branch and leave it to you to merge directly to your master?)\n\nI think I missed this part, but in the case of git-svn, what we do\nis the former. The branch Eric makes me pull may be called 'master'\nin his repository, but it does not contain anything unrelated to\ngit-svn, so from _my_ viewpoint, it is a single \"topic to improve\ngit-svn\".\n\nBut from Eric's point of view, it is an aggregation of different\ntopics from many people on top of my tree, and each topic may tackle\nits own theme. I think most of the pulls from him so far were single\nstrand of pearls without merges, but if two or more long topics were\ncooking in his tree, it would have been perfectly reasonable for him\nto resolve such inter-topic conflicts before telling me to pull the\nresult.\n\nAfter all, that is what the sub-maintainer of an area is. One who\nknows the area the best coordinates possibly conflicting changes\nbrought in different topics to the area.\n\nThs same can go for multimail, or any contrib/ material for that\nmatter.\n"}]}