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.

Ideas for the future

====================

Ideas are tracked on

https://github.com/git-multimail/git-multimail/issues

Below is an old, but hopefully still up to date list of ideas.

* 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.

* 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.