Notification mails for git repos

[Geert Janssens]

On 31-01-13 04:45, John Ralls wrote:
> On Jan 30, 2013, at 8:13 AM, Geert Janssens <janssens-geert at telenet.be> wrote:
>
>> Here is a first practical limitation of the new script: the old scripts had some logic built in that would add an AUDIT tag in front of the mail subject if the commit message had a line containing solely "BP".
>>
>> This gets more complicated with the new scripts. One mail can hold the commit messages of multiple commits. What to do if only some of these commits are supposed to be backported and have BP in their commit message ?
>>
> What design decision drove you away from one mail per commit?
>
> Regards,
> John Ralls
>
>
The simple fact that the example script was written for one mail per 
push, to be used in the post-receive hook. Github's mail hook also works 
that way, so I was under the impression that in git setups this is the 
preferred way to send notifications.

Changing to a one mail per commit configuration means either finding a 
trigger that fires for each commit, or writing a mail script that sends 
individual mails for each commit in the push.

I have first looked for a trigger that fires on each commit, but didn't 
find one we could use. In theory there is the update hook, but this one 
is reserved by gitolite. And according to my experiments the post-commit 
hook is not triggered in the receiving repo of a push operation.

So post-receive is the only hook we  can use by my knowledge.

Which leaves us with finding or writing another mail script. My search 
on the web always turns up the same script we currently use (already 
slightly adapted). I haven't come across a script that sends seperate 
mails per commit.

I personally don't feel like writing another script from scratch, as I 
wonder how much we'd gain from it.

Granted, our BP->AUDIT feature wouldn't work anymore, but I like to 
discuss if it is really worth keeping around or not.

To put it differently: I'm interested in learning about new best 
practices and solutions offered by git, which claims to have much better 
branch and merge facilities. That's partly why I started this mail thread.

In that sense I more or less like Yawar's daggy bugfixing suggestion: 
using merge instead of cherry-pick nicely preserves history in the repo. 
The drawback of needing manual intervention from time to time is valid 
for both merging and cherry-picking.

It also eliminates the need for a BP->AUDIT scheme. By the name of the 
branch, we know which commits are meant for backporting and the git 
history could easily show which commits weren't backported yet.

Daggy fixing is probably not the only useful scheme though. I could also 
imagine something like this to work:
- all bugfixes and only bugfixes happen on the 2.4 branch
- the 2.4 branch regularly gets merged into the development branch, so 
all bugfixes also will end up in future releases
This concept is no longer back-porting, but forward-porting. Advantage: 
all bugfixes eventually end up in the active trees and git branches show 
the history, no need for BP->AUDIT

Note that neither daggy fixing nor forward porting are possible as long 
as we're tied to svn. So this discussion is on future process, not 
practical next steps yet.

How can we in the future improve our process to something in which the 
history clearly reflects what actually happened, in which no work is 
lost (by forgetting to backport) and without too much overhead.

Geert