Notification mails for git repos

[Geert Janssens]

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 ?

Add AUDIT as soon as one commit in the push asks for backporting ?

Alternatively I played with the idea to just drop the whole BP trickery. 
Instead we could use a backport branch in git. Each dev that commits 
something to trunk/master that should also be backported, could 
cherry-pick this commit to the backport branch. Since this would trigger 
a mail notification that the backport branch was updated, this also 
serves as a heads-up, just like the AUDIT tag would have. This 
alternative may not be possible as long as we are bound to svn. Svn is 
pretty poor in merging, while git's cherry-pick is very easy. Then 
again, as the backporting is currently mostly done by devs that already 
work from git anyway, it may work now already.

Yet another option would be to send mails per commit. That would mean 
though we'd have to start from scratch for our mail script and I'm not 
sure I know enough of git internals to be able to deal with all commit 
types properly. I prefer not to go this route if possible.

Any thoughts, bright ideas, suggestions ?

Geert

P.S. Now is perhaps also a good time to re-evaluate our mail sending 
habits. Do we really still need two different mails ? I know one is only 
a summary while the other hold the complete diff, but do we want to 
generate both types or is one sufficient ? What are the use cases and 
are they still valid ?



On 30-01-13 15:25, Geert Janssens wrote:
> Hi,
>
> I have been working on a script that would allow the git repos to send 
> notification mails whenever changes are pushed. This is the equivalent 
> of the automated notification mails that get sent to gnucash-patches 
> and gnucash-changes whenever a change is committed to svn.
>
> Since git's behaviour doesn't map 1 on 1 to svn's, I have started from 
> an example script that is distributed together with git. Attached you 
> will find two example mails generated by the new script
>
> These were generated in a repo  called "testing", on branch "master" 
> after I had pushed two commits to the git repo. It's worth noting 
> already that the script will only send one mail even though it 
> processes two commits. The script sends one mail per push and per 
> branch. So if one push affects 3 branches, it will send 3 mails. Well, 
> actually 3 sets of 2 mails.
>
> The first mail contains a summary of the commit logs (similar to what 
> is currently sent to gnucash-changes), the second one also contains 
> the commit diffs (similar to what is currently sent to gnucash-patches).
>
> Personally I think the introduction in the mails is way to verbose. 
> I'm open to suggestions to improve this.
>
> Please give your feedback, thanks.
>
> Geert
>
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel