git-multimail/notes.txt at master · devopsgeek94/git-multimail · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
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.