[E-devel] One mail/commit (was: RE: [EGIT] [core/efl] branch master updated. 04e660c5c76fa9168be08de1f979a1684c464154)

[Peter K. <pet...@ax...>]

> -----Original Message-----
> From: Tom Hacohen [mailto:to...@st...]
> Sent: 16 February 2013 17:43
> To: e
> Subject: Re: [E-devel] [EGIT] [core/efl] branch master updated.
> 04e660c5c76fa9168be08de1f979a1684c464154
> 
> At the moment it's one mail per changeset, that  can be changed if
> decided upon.
> 
> On 16 Feb 2013 10:41, "David Seikel" <on...@gm...> wrote:
> 
> > On Sat, 16 Feb 2013 02:25:53 -0800 Enlightenment Git <no-...@en...> wrote:
> >
> > > The branch, master has been updated
> > >
> > > This change consists of the following commits:
> > > 04e660c Paulo C. A. Cavalcanti Jr: evas: Introduce pixel_alpha_get()
> > >
> > > b6c8972 Cedric BAIL: evas: forgotten update to ChangeLog.
> > >
> > > 1e916e4 Cedric BAIL: eina: improve Eina_Clist support for 64bits
> > > system.
> >
> > Two unrelated commits from two authors in one email?  And in an
> > apparently random time order as well.

I would like to +1 the idea of sending one mail per commit. 
Multiple, maybe even unrelated, commits in one mail makes it 
hard to see what is happening.

Having written such a hook to send these kinds of mails for 
my company I have a few suggestions:

* Make it so that it only sends mails for commits that were 
  previously not accessible. I.e., if some (or all) of the 
  commits were previously reachable via another reference, 
  you do not need to send another mail. Otherwise, if someone 
  branches master and pushes it, you will get new commit mails 
  for all those old commits on master again... 
* Use a subject like: [<repository>] [<branch or tag>] <first line of commit message>
  * Whether to also include the first line of the commit 
    message in the body of the mail again can be debated. 
    Personally I prefer to do it as sometimes I only read the 
    subject lines, but sometimes I am rather reading the mail 
    bodies, and then having to look for that first line in 
    the subject is distracting.
  * Preferably, all references (branches and tags) where the 
    commit is reachable after pushing should be listed in 
    the subject. This, however, is a bit messy to determine...

//Peter