notes.txt

Notes
=====

* Copyright notice: I kept the copyright notice of Andy Parkins, since
  the script is ultimately derived from his.  But I added my own
  copyright notice, since the script is mostly rewritten.


git-multimail-v2
================

* Are people happy with the convention of using configuration
  namespace "multimailhook.*", as opposed to something like
  "hook.multimail.*"?

* Document the variables that can be used in the templates.

* Make sure that email texts (i.e., in templates) are appropriate even
  for people who are subscribed to only some of the lists.

* Patch formatting:

  * Make sure that the script does not barf on binary files that are
    improperly marked.

  * Make sure that script does not emit enormous emails for
    apparently-text files that have extremely long lines.

  * Perhaps add a hook to allow patches to be cleaned up more
    generally before being sent.

* More testing.

* Check for and reimplement any changes that have been made in
  post-receive-email since the last import.


Ideas for the future
====================

* Allow branch-specific configuration.

* Add a "Date:" field to emails, and ensure that the dates are
  monotonic (e.g., by incrementing the date by 1s for each email) to
  help mail clients thread the messages in the right order (apparently
  "git send-email" does this).

  Suggested by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>

* Support LDAP, for example by adding an LDAP environment:

  * Use LDAP to convert pusher usernames to email addresses.

  * Allow recipients to be configured via LDAP

  Are LDAP schemas uniform enough that we could do something that
  would be generally useful?

* Make the templating system more flexible and easier to configure.

* Use textwrap to correctly wrap prose output in the notification
  emails.

* Each commit is threaded with one of the ReferenceChanges in the push
  that first introduced the commit.  The algorithm for grouping them
  could be made cleverer:

  * Distinguish between first and subsequent parents of merge commits.

  * Recognize specific git idioms (e.g., merging and deleting a
    feature branch) and describe them in more abstract terms in the
    commit emails.

* Perhaps handle specially the case when multiple new tags point at
  the same commit (e.g., describe them all in a single email rather
  than one email per tag).

* Allow people to subscribe to changes only to particular files.

  Suggested by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

* When a reference is created, show the branch(es) from which it
  appears to sprout.

* Output to stdout the refchange-style summary list of commits as
  feedback for the pusher.  This might help the pusher notice if s/he
  accidentally pushed more commits than intended.

* If the maxcommitemails limit causes revision emails to be
  suppressed, note that fact in the refchange email and/or via a
  special email to the commitList threaded to the refchange email.

* Maybe create GitObjects in more places (but beware of performance
  impact!).  Maybe define a GitCommit class (derived from GitObject)
  that also holds its subject.  Maybe make a GitCommit able to expand
  a template.

* Maybe use a weakref in GitObject to avoid creating a reference loop.

* Use "git cat-file --batch" or "--batch-check" (if it has been in git
  long enough) to reduce the number of times that Git has to be
  executed.