v3git-multimail: a replacement for post-receive-email

This is the third iteration of submitting git-multimail to Git. The first pass [1] was a modest trial balloon, proposing to add a new script to live alongside post-receive-email. Following feedback [2] from the mailing list, I decided to make the script a full replacement for post-receive-email (and renamed it from post-receive-multimail.py to git-multimail). The second pass [3] was an RFC that generated a lot of useful feedback, some requests for better support of old features (mostly implemented), and some contributions by other members of the community (especially Matthieu Moy). The overall reaction to git-multimail as a replacement for post-receive-email has been quite positive.

Now I believe that git-multimail is ripe for inclusion in contrib. Its features are documented in the README file and its advantages over post-receive-email are documented in the file README.migrate-from-post-receive-email.

This series consists of a single patch that adds a directory contrib/hooks/git-multimail/ containing five files, described in the patch's commit message. It does *not* deprecate post-receive-email, let alone remove it, though I hope that both of those steps will be warranted in time.

If there is consensus that git-multimail should be integrated into the Git project, there are some logistical issues that need to be discussed:

* Code drop versus merge?

  * The first 170 commits to git-multimerge took place in a private
    repository, commingled with other material.  All of these commits
    were by me.  I don't have time to sanitize these commits into a
    publishable history, so I'm afraid that part of the history will
    never become public.

  * The subsequent 200 commits of the history have been published to
    GitHub [4].  (The version that I am submitting corresponds to the
    git-multimail subtree of revision
    c06a1af5d3a9dfbac7eb704dc8e15a2aee60a334 of that repository.)
    These commits are reasonably clean, though definitely not up to
    the usual Git project standards.  The first of these commits
    consists of a code drop from the private repository just
    mentioned.  The recent part of this history includes commits by
    other authors.

  Would it be preferable to merge the last 200 commits of the
  git-multimail history into the Git project (presumably via subtree
  merge), or just to incorporate it as a single, squashed patch?

* What to include?  The GitHub repo contains some infrastructure
  outside of the git-multimail directory, which is not included in
  this patch series:

      .gitignore, COPYING -- redundant with the Git project's
          top-level files.

      MANIFEST.in, setup.py -- infrastructure for Python's setuptools
          (to allow git-multimail to be packaged as a Python module,
          probably irrelevant in the context of the Git project.

      README -- a symlink to git-multimail/README.

      t/ -- some crude scripts and data that I have been using for
          testing.  The tests are largely manual, so it is not clear
          whether they would be helpful within the Git project.

      notes.txt -- TODO list etc.

* How to organize future development?  Directly in the Git repo, using
  the git mailing list, etc?  As a fork of the Git project that
  occasionally issues patches and/or pull requests to the main
  project?  Or as a separate project that does not include the whole
  Git tree, which is occasionally merged back to the Git project using
  subtree merge?

[1] http://article.gmane.org/gmane.comp.version-control.git/201433 [2] http://article.gmane.org/gmane.comp.version-control.git/201471 [3] http://article.gmane.org/gmane.comp.version-control.git/214686 [4] https://github.com/mhagger/git-multimail

Michael Haggerty (1):
  git-multimail: a replacement for post-receive-email

 contrib/hooks/git-multimail/README                 |  410 ++++
 .../README.migrate-from-post-receive-email         |  146 ++
 contrib/hooks/git-multimail/git_multimail.py       | 2126 ++++++++++++++++++++
 .../hooks/git-multimail/migrate-mailhook-config    |  270 +++
 contrib/hooks/git-multimail/post-receive           |   66 +
 5 files changed, 3018 insertions(+)
 create mode 100644 contrib/hooks/git-multimail/README
 create mode 100644 contrib/hooks/git-multimail/README.migrate-from-post-receive-email
 create mode 100755 contrib/hooks/git-multimail/git_multimail.py
 create mode 100755 contrib/hooks/git-multimail/migrate-mailhook-config
 create mode 100755 contrib/hooks/git-multimail/post-receive

Hi,

Michael Haggerty wrote:

Yay!  I look forward to seeing it.

[...]

That could be a reason to do a subtree merge if you want. A code drop with a commit message that acknowledges the contributors would also presumably be fine.

[...]

My personal preference is that patches come on the git list, are reviewed here, and then go to your fork of the Git project that Junio can periodically pull from at your request (like git-svn). But of course this is up to you, too.

Thanks, Jonathan

Jonathan Nieder <jrnieder@gmail.com> writes:

And also me ;-)

Yes, I very much prefer the way how git-svn is managed.

On 04/21/2013 08:44 PM, Junio C Hamano wrote:

Let me see if I understand what that means:

* I maintain my own Git clone

* Patches to git-multimail would go to the Git mailing list like patches
to other patches to the Git project, but I would be the one to git-am
them, monitor discussion, help with review, etc.  I would presumably
apply the patches near your master (or near maint when necessary).

* When I think a batch of patches is ready, I merge them to my master
and publish my master somewhere.  (Or is it better I publish the feature
branch and leave it to you to merge directly to your master?)  Then I
send a merge request to you and the Git mailing list with the URL and
SHA-1 of the branch that I would like you to merge.

That seems very workable.

What is your preference regarding the history to date?

Michael

Michael Haggerty <mhagger@alum.mit.edu> writes:

That is pretty much it.

The only thing I deeply care about is that initial and subsequent "git pull" I'll do from you [*1*] will pull in commits that touch only the "multimail" part in the contrib/ area and not mixed with unrelated changes to other areas.

If the history you have so far would later help others learn the motivation, design, constraints etc. while developing it, which cannot be easily read from the resulting code, i.e. help maintaining it in general, it's a good idea to keep it. In such a case, however, people may want to review that history as well.

If it is the "oops, it didn't work, let's try another" kind of "record as we build" type of history that may not help the future maintainace that much, you may instead want to start with a single code-dump "here is the first public version" (which is reviewed in this thread, I think) without the history behind it.

Your choice, in other words ;-)

[Footnote]

*1* This does not even have to be a stable URL I would place in remote.multimail.url configuration; it does not even have to be a non-rewinding tree.

Michael Haggerty <mhagger@alum.mit.edu> writes:

I think I missed this part, but in the case of git-svn, what we do is the former. The branch Eric makes me pull may be called 'master' in his repository, but it does not contain anything unrelated to git-svn, so from _my_ viewpoint, it is a single "topic to improve git-svn".

But from Eric's point of view, it is an aggregation of different topics from many people on top of my tree, and each topic may tackle its own theme. I think most of the pulls from him so far were single strand of pearls without merges, but if two or more long topics were cooking in his tree, it would have been perfectly reasonable for him to resolve such inter-topic conflicts before telling me to pull the result.

After all, that is what the sub-maintainer of an area is. One who knows the area the best coordinates possibly conflicting changes brought in different topics to the area.

Ths same can go for multimail, or any contrib/ material for that matter.

Michael Haggerty wrote:

Very nice.

For what it's worth, I'd be happy to see this in contrib/. It is good to see an actively maintained analog to post-receive-email, and the one-mail-per-commit functionality looks fun and useful.

Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/137426