From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Chris Hiestand" <chrishiestand@gmail.com>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"Marc Branchaud" <mbranchaud@xiplink.com>,
"Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>,
"Michiel Holtkamp" <git@elfstone.nl>,
"Stefan Näwe" <stefan.naewe@gmail.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Michael Haggerty" <mhagger@alum.mit.edu>
Subject: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email
Date: Sun, 21 Apr 2013 12:49:39 +0200 [thread overview]
Message-ID: <1366541380-10786-1-git-send-email-mhagger@alum.mit.edu> (raw)
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
--
1.8.2.1
next reply other threads:[~2013-04-21 10:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-21 10:49 Michael Haggerty [this message]
2013-04-21 10:56 ` [PATCH v3 0/1] git-multimail: a replacement for post-receive-email Jonathan Nieder
2013-04-21 18:44 ` Junio C Hamano
2013-04-21 20:02 ` Michael Haggerty
2013-04-21 22:12 ` Junio C Hamano
2013-04-21 22:28 ` Junio C Hamano
[not found] ` <1366541380-10786-2-git-send-email-mhagger@alum.mit.edu>
2013-04-21 11:07 ` [PATCH v3 1/1] " Jonathan Nieder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1366541380-10786-1-git-send-email-mhagger@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=avarab@gmail.com \
--cc=chrishiestand@gmail.com \
--cc=git@elfstone.nl \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=mbranchaud@xiplink.com \
--cc=stefan.naewe@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).