Hey guys,
right now, we use the stock email commit hook from Github and let it send commit mails to the geany-commits mailing list.
However, compared to the old Subversion commit mails, they are quite different:
First, they are not really commit mails but rather "push" mails, that is all commits which are transmitted within one push are combined into one mail instead of one mail per commit as it was previously.
Secondly, the commit mails only include the commit message and a link to the commit diff at Github. I personally would prefer to have the diff included (also as before).
So, I'm tempted to use something else for sending out commit mails.
For example, the Xfce guys have a simple Shell script to do the job and it does it as I would wish: http://git.xfce.org/admin/xfce-git-hooks/tree/hooks/update-03-send-commit-ma...
An example mail: http://mail.xfce.org/pipermail/xfce4-commits/2011-October/023580.html
What do you think?
Regards, Enrico
Le 18/10/2011 19:52, Enrico Tröger a écrit :
Hey guys,
right now, we use the stock email commit hook from Github and let it send commit mails to the geany-commits mailing list.
However, compared to the old Subversion commit mails, they are quite different:
First, they are not really commit mails but rather "push" mails, that is all commits which are transmitted within one push are combined into one mail instead of one mail per commit as it was previously.
Secondly, the commit mails only include the commit message and a link to the commit diff at Github. I personally would prefer to have the diff included (also as before).
So, I'm tempted to use something else for sending out commit mails.
For example, the Xfce guys have a simple Shell script to do the job and it does it as I would wish: http://git.xfce.org/admin/xfce-git-hooks/tree/hooks/update-03-send-commit-ma...
An example mail: http://mail.xfce.org/pipermail/xfce4-commits/2011-October/023580.html
What do you think?
Nothing but a big "+1" ;)
The resulting email looks good to me -- quite like a `git show` :) --, just maybe it could include the GitHub link too if of any interest.
Cheers, Colomban
On Tue, 18 Oct 2011 20:03:09 +0200, Colomban wrote:
Le 18/10/2011 19:52, Enrico Tröger a écrit :
Hey guys,
right now, we use the stock email commit hook from Github and let it send commit mails to the geany-commits mailing list.
However, compared to the old Subversion commit mails, they are quite different:
First, they are not really commit mails but rather "push" mails, that is all commits which are transmitted within one push are combined into one mail instead of one mail per commit as it was previously.
Secondly, the commit mails only include the commit message and a link to the commit diff at Github. I personally would prefer to have the diff included (also as before).
So, I'm tempted to use something else for sending out commit mails.
For example, the Xfce guys have a simple Shell script to do the job and it does it as I would wish: http://git.xfce.org/admin/xfce-git-hooks/tree/hooks/update-03-send-commit-ma...
An example mail: http://mail.xfce.org/pipermail/xfce4-commits/2011-October/023580.html
What do you think?
Nothing but a big "+1" ;)
The resulting email looks good to me -- quite like a `git show` :) --, just maybe it could include the GitHub link too if of any interest.
Yup, that'd be easy and useful.
Regards, Enrico
On Tue, 18 Oct 2011 20:03:09 +0200, Colomban wrote:
Le 18/10/2011 19:52, Enrico Tröger a écrit :
Hey guys,
right now, we use the stock email commit hook from Github and let it send commit mails to the geany-commits mailing list.
However, compared to the old Subversion commit mails, they are quite different:
First, they are not really commit mails but rather "push" mails, that is all commits which are transmitted within one push are combined into one mail instead of one mail per commit as it was previously.
Secondly, the commit mails only include the commit message and a link to the commit diff at Github. I personally would prefer to have the diff included (also as before).
So, I'm tempted to use something else for sending out commit mails.
For example, the Xfce guys have a simple Shell script to do the job and it does it as I would wish: http://git.xfce.org/admin/xfce-git-hooks/tree/hooks/update-03-send-commit-ma...
An example mail: http://mail.xfce.org/pipermail/xfce4-commits/2011-October/023580.html
What do you think?
Nothing but a big "+1" ;)
Nobody else with an opinion?
(-1 is allowed is as well as answer though not preferred...:D)
(j/k)
Regards, Enrico
Am Montag, den 24.10.2011, 23:45 +0200 schrieb Enrico Tröger:
Nothing but a big "+1" ;)
+1
On 10/24/2011 02:45 PM, Enrico Tröger wrote:
On Tue, 18 Oct 2011 20:03:09 +0200, Colomban wrote:
Le 18/10/2011 19:52, Enrico Tröger a écrit :
Hey guys,
right now, we use the stock email commit hook from Github and let it send commit mails to the geany-commits mailing list.
However, compared to the old Subversion commit mails, they are quite different:
First, they are not really commit mails but rather "push" mails, that is all commits which are transmitted within one push are combined into one mail instead of one mail per commit as it was previously.
Secondly, the commit mails only include the commit message and a link to the commit diff at Github. I personally would prefer to have the diff included (also as before).
So, I'm tempted to use something else for sending out commit mails.
For example, the Xfce guys have a simple Shell script to do the job and it does it as I would wish: http://git.xfce.org/admin/xfce-git-hooks/tree/hooks/update-03-send-commit-ma...
An example mail: http://mail.xfce.org/pipermail/xfce4-commits/2011-October/023580.html
What do you think?
Nothing but a big "+1" ;)
Nobody else with an opinion?
(-1 is allowed is as well as answer though not preferred...:D)
0
I have mixed feelings about this. After the 800 commit mails in a short period of time on the xfce-commits list the other day, I think the "combined" commit mails like we have now are nice. I'm also not sure it's worth the bandwidth of sending massive diffs for things like rebuilding documentation or other really huge ones. I guess for some people bandwidth is super cheap and others not so much. I do like having the diffs in the mails normally, but I also don't much mind clicking a hyperlink to see a well coloured and laid out diff.
If we go back to individual commit mails with diffs, is there anyway to limit how many individual messages get sent out at once and how many lines can be in a diff? Ex. if we merge the gtkbuilder branch at some point, is there anyway to prevent from flooding the list with all those commit mails but to send individual ones for regular 2 or 3 commits in a row?
But really, I don't care too much either way :)
Cheers, Matthew Brush
[...]
If we go back to individual commit mails with diffs, is there anyway to limit how many individual messages get sent out at once and how many lines can be in a diff? Ex. if we merge the gtkbuilder branch at some point, is there anyway to prevent from flooding the list with all those commit mails but to send individual ones for regular 2 or 3 commits in a row?
But really, I don't care too much either way :)
And the flooding each time geany.html gets updated is a pain.
Personally I don't mind the links and combined emails so I guess I'm -0.5.
Cheers Lex
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 25/10/2011 00:33, Lex Trotman wrote:
[...]
If we go back to individual commit mails with diffs, is there anyway to limit how many individual messages get sent out at once and how many lines can be in a diff? Ex. if we merge the gtkbuilder branch at some point, is there anyway to prevent from flooding the list with all those commit mails but to send individual ones for regular 2 or 3 commits in a row?
I'm not sure we would see a flood on a merge, probably only one commit saying 'merged gtkbuilder branch'? The gtkbuilder commits should appear as they are committed, not on merge.
But really, I don't care too much either way :)
And the flooding each time geany.html gets updated is a pain.
This may have been because I had an older version of python/docutils. When I regenerated the html 3 weeks ago with a recent docutils the diff was small.
Personally I don't mind the links and combined emails so I guess I'm -0.5.
I'm +1, assuming we have diff size limiting like we used to with SVN. I find it very useful to look at small changes from my mail reader without having to click and wait for the github diff page to load - this discourages me from bothering.
On 11-10-31 05:00 AM, Nick Treleaven wrote:
On 25/10/2011 00:33, Lex Trotman wrote:
[...]
If we go back to individual commit mails with diffs, is there anyway to limit how many individual messages get sent out at once and how many lines can be in a diff? Ex. if we merge the gtkbuilder branch at some point, is there anyway to prevent from flooding the list with all those commit mails but to send individual ones for regular 2 or 3 commits in a row?
I'm not sure we would see a flood on a merge, probably only one commit saying 'merged gtkbuilder branch'? The gtkbuilder commits should appear as they are committed, not on merge.
I think when you merge it makes all the commits onto the branch that was merged into also. At least this is what happened on the xfce-commits list when one of the devs merged several branches with a total of 800+ commits in them, each triggering a commit mail :)
Cheers, Matthew Brush
On Mon, 31 Oct 2011 06:29:36 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
On 11-10-31 05:00 AM, Nick Treleaven wrote:
On 25/10/2011 00:33, Lex Trotman wrote:
[...]
If we go back to individual commit mails with diffs, is there anyway to limit how many individual messages get sent out at once and how many lines can be in a diff? Ex. if we merge the gtkbuilder branch at some point, is there anyway to prevent from flooding the list with all those commit mails but to send individual ones for regular 2 or 3 commits in a row?
I'm not sure we would see a flood on a merge, probably only one commit saying 'merged gtkbuilder branch'? The gtkbuilder commits should appear as they are committed, not on merge.
I think when you merge it makes all the commits onto the branch that was merged into also. At least this is what happened on the xfce-commits list when one of the devs merged several branches with a total of 800+ commits in them, each triggering a commit mail :)
Isn't --no-ff or --squash not able to prevent this?
Cheers, Frank
On 10/31/2011 06:45 AM, Frank Lanitz wrote:
On Mon, 31 Oct 2011 06:29:36 -0700 Matthew Brushmbrush@codebrainz.ca wrote:
On 11-10-31 05:00 AM, Nick Treleaven wrote:
On 25/10/2011 00:33, Lex Trotman wrote:
[...]
If we go back to individual commit mails with diffs, is there anyway to limit how many individual messages get sent out at once and how many lines can be in a diff? Ex. if we merge the gtkbuilder branch at some point, is there anyway to prevent from flooding the list with all those commit mails but to send individual ones for regular 2 or 3 commits in a row?
I'm not sure we would see a flood on a merge, probably only one commit saying 'merged gtkbuilder branch'? The gtkbuilder commits should appear as they are committed, not on merge.
I think when you merge it makes all the commits onto the branch that was merged into also. At least this is what happened on the xfce-commits list when one of the devs merged several branches with a total of 800+ commits in them, each triggering a commit mail :)
Isn't --no-ff or --squash not able to prevent this?
IMO, it's not good to mess with the history just to avoid triggering commit mails.
Cheers, Matthew Brush
On 31/10/2011 13:57, Matthew Brush wrote:
I'm not sure we would see a flood on a merge, probably only one commit saying 'merged gtkbuilder branch'? The gtkbuilder commits should appear as they are committed, not on merge.
I think when you merge it makes all the commits onto the branch that was merged into also. At least this is what happened on the xfce-commits list when one of the devs merged several branches with a total of 800+ commits in them, each triggering a commit mail :)
Ok, but ideally it would do as I described, like the github commit list for the scintilla-update merge:
https://github.com/geany/geany/commits
Isn't --no-ff or --squash not able to prevent this?
IMO, it's not good to mess with the history just to avoid triggering commit mails.
Agreed. Besides I would forget to pass those options ;-)
On 31/10/2011 15:07, Nick Treleaven wrote:
On 31/10/2011 13:57, Matthew Brush wrote:
I'm not sure we would see a flood on a merge, probably only one commit saying 'merged gtkbuilder branch'? The gtkbuilder commits should appear as they are committed, not on merge.
I think when you merge it makes all the commits onto the branch that was merged into also. At least this is what happened on the xfce-commits list when one of the devs merged several branches with a total of 800+ commits in them, each triggering a commit mail :)
Ok, but ideally it would do as I described, like the github commit list for the scintilla-update merge:
Anyway I think the problem of only showing the first commit of the push in the subject makes the commit mails harmful because changes can easily be missed. This problem seems more important than the potential flooding issue. In practice our branch merges likely wouldn't have 800 commits.
On Mon, 31 Oct 2011 16:44:52 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 31/10/2011 15:07, Nick Treleaven wrote:
On 31/10/2011 13:57, Matthew Brush wrote:
I'm not sure we would see a flood on a merge, probably only one commit saying 'merged gtkbuilder branch'? The gtkbuilder commits should appear as they are committed, not on merge.
I think when you merge it makes all the commits onto the branch that was merged into also. At least this is what happened on the xfce-commits list when one of the devs merged several branches with a total of 800+ commits in them, each triggering a commit mail :)
Ok, but ideally it would do as I described, like the github commit list for the scintilla-update merge:
Anyway I think the problem of only showing the first commit of the push in the subject makes the commit mails harmful because changes can easily be missed. This problem seems more important than the potential flooding issue. In practice our branch merges likely wouldn't have 800 commits.
Agreed.
Cheers, Frank
On 10/31/2011 09:44 AM, Nick Treleaven wrote:
On 31/10/2011 15:07, Nick Treleaven wrote:
On 31/10/2011 13:57, Matthew Brush wrote:
I'm not sure we would see a flood on a merge, probably only one commit saying 'merged gtkbuilder branch'? The gtkbuilder commits should appear as they are committed, not on merge.
I think when you merge it makes all the commits onto the branch that was merged into also. At least this is what happened on the xfce-commits list when one of the devs merged several branches with a total of 800+ commits in them, each triggering a commit mail :)
Ok, but ideally it would do as I described, like the github commit list for the scintilla-update merge:
Anyway I think the problem of only showing the first commit of the push in the subject makes the commit mails harmful because changes can easily be missed. This problem seems more important than the potential flooding issue. In practice our branch merges likely wouldn't have 800 commits.
+1
And if we do have a case where a massive amount of commits will happen at once, we could just temporarily disable the commit mails or ask Enrico to do it. IIRC it would just be a matter of turning of the webhook through Github admin settings and turning it back on afterwards.
Cheers, Matthew Brush
On Mon, 31 Oct 2011 15:29:08 -0700, Matthew wrote:
On 10/31/2011 09:44 AM, Nick Treleaven wrote:
On 31/10/2011 15:07, Nick Treleaven wrote:
On 31/10/2011 13:57, Matthew Brush wrote:
> I'm not sure we would see a flood on a merge, probably only one > commit saying 'merged gtkbuilder branch'? The gtkbuilder commits > should appear as they are committed, not on merge. >
I think when you merge it makes all the commits onto the branch that was merged into also. At least this is what happened on the xfce-commits list when one of the devs merged several branches with a total of 800+ commits in them, each triggering a commit mail :)
Ok, but ideally it would do as I described, like the github commit list for the scintilla-update merge:
Anyway I think the problem of only showing the first commit of the push in the subject makes the commit mails harmful because changes can easily be missed. This problem seems more important than the potential flooding issue. In practice our branch merges likely wouldn't have 800 commits.
+1
And if we do have a case where a massive amount of commits will happen at once, we could just temporarily disable the commit mails or ask Enrico to do it. IIRC it would just be a matter of turning of the webhook through Github admin settings and turning it back on afterwards.
Yes.
So I take this as a 'yes, turn it into something more similar to the old SVN commit mails with diff, size-limited and a link to the web repo'. Will do this soon and announce it before and after.
Regards, Enrico
Le 02/11/2011 18:18, Enrico Tröger a écrit :
On Mon, 31 Oct 2011 15:29:08 -0700, Matthew wrote:
On 10/31/2011 09:44 AM, Nick Treleaven wrote:
On 31/10/2011 15:07, Nick Treleaven wrote:
On 31/10/2011 13:57, Matthew Brush wrote:
>> I'm not sure we would see a flood on a merge, probably only one >> commit saying 'merged gtkbuilder branch'? The gtkbuilder commits >> should appear as they are committed, not on merge. >> > > I think when you merge it makes all the commits onto the branch > that was merged into also. At least this is what happened on the > xfce-commits list when one of the devs merged several branches > with a total of 800+ commits in them, each triggering a commit > mail :)
Ok, but ideally it would do as I described, like the github commit list for the scintilla-update merge:
Anyway I think the problem of only showing the first commit of the push in the subject makes the commit mails harmful because changes can easily be missed. This problem seems more important than the potential flooding issue. In practice our branch merges likely wouldn't have 800 commits.
+1
And if we do have a case where a massive amount of commits will happen at once, we could just temporarily disable the commit mails or ask Enrico to do it. IIRC it would just be a matter of turning of the webhook through Github admin settings and turning it back on afterwards.
Yes.
So I take this as a 'yes, turn it into something more similar to the old SVN commit mails with diff, size-limited and a link to the web repo'. Will do this soon and announce it before and after.
Just wanted to say: looking forward to it :)
Thanks!
Colomban
On Wed, 02 Nov 2011 19:20:57 +0100, Colomban wrote:
So I take this as a 'yes, turn it into something more similar to the old SVN commit mails with diff, size-limited and a link to the web repo'. Will do this soon and announce it before and after.
Just wanted to say: looking forward to it :)
Sorry for the big delay but finally good news: see attachment.
Last week I worked on the topic and failed to get any post-* commit hook ro be executed in the mirror repositories. I guess the hooks aren't run when the repo is updated using 'git remote update'. But I found another solution which I actually like better as we do not need to rely on the mirror repos to get commit mails from the main repo:
We already have setup the post-receive commit hook in Github which updates the mirror repos. When this script gets called we already get a list of commits the corresponding push contained. And then I wrote a script which takes a commit hash and then asks the Github API for more details about this commit. The script then generates a commit mail like the one in the attachment. Basically the mail is formatted like the old SF SVN commit mails but it's just a template.
What do you think?
If we agree to change the commit mails to this format, I'd deploy the script soon.
And in a further step, I'd like to conserve the post-receive commit script and the new script to generate the mail in a GIT repo so it's more obvious what happens and why. Any objections on creating a repository like geany/infrastructure or something like this?
Regards, Enrico
[...]
What do you think?
If we agree to change the commit mails to this format, I'd deploy the script soon.
Hi Enrico,
Actually I've become used to the standard github commit emails and clicking on the link for the diff.
Especially for large changes like geany.html or geany.glade (despite Matthew and Colomban "promising" the diffs will get smaller with 3.8.1) not being blasted by large diffs is good. I can choose what I want to see, and don't get the two line diff of geany.txt cut off because the huge geany.html diff exceeds the size limit.
I don't suppose that you could let registration for the commit ML allow a choice of which we want?
Cheers Lex
[...]
On 01/15/2012 12:03 PM, Lex Trotman wrote:
[...]
What do you think?
If we agree to change the commit mails to this format, I'd deploy the script soon.
Hi Enrico,
Actually I've become used to the standard github commit emails and clicking on the link for the diff.
Especially for large changes like geany.html or geany.glade (despite Matthew and Colomban "promising" the diffs will get smaller with 3.8.1) not being blasted by large diffs is good. I can choose what I want to see, and don't get the two line diff of geany.txt cut off because the huge geany.html diff exceeds the size limit.
I don't suppose that you could let registration for the commit ML allow a choice of which we want?
Or make it so no diff is shown for autogenerated files like geany.html and geany.glade ?
It'd be the best of both worlds then, IMO.
Cheers, Matthew Brush
On Sun, 15 Jan 2012 13:35:35 -0800, Matthew wrote:
On 01/15/2012 12:03 PM, Lex Trotman wrote:
[...]
What do you think?
If we agree to change the commit mails to this format, I'd deploy the script soon.
Hi Enrico,
Actually I've become used to the standard github commit emails and clicking on the link for the diff.
Especially for large changes like geany.html or geany.glade (despite Matthew and Colomban "promising" the diffs will get smaller with 3.8.1) not being blasted by large diffs is good. I can choose what I want to see, and don't get the two line diff of geany.txt cut off because the huge geany.html diff exceeds the size limit.
I don't suppose that you could let registration for the commit ML allow a choice of which we want?
Nope. The only option would be two separate mailing lists.
Though the general idea about the diffs was to limit the diff size to something like 100kb (as it was before in the SF SVN commit mails) or any other value which we consider reasonable.
Or make it so no diff is shown for autogenerated files like geany.html and geany.glade ?
It'd be the best of both worlds then, IMO.
Yeah, a little hackish but would solve the problem probably well enough together with a general max commit diff size limit.
Regards, Enrico
Le 15/01/2012 23:53, Enrico Tröger a écrit :
On Sun, 15 Jan 2012 13:35:35 -0800, Matthew wrote:
On 01/15/2012 12:03 PM, Lex Trotman wrote:
[...]
What do you think?
If we agree to change the commit mails to this format, I'd deploy the script soon.
I'd very much like it, and I'm fine with the format :)
Hi Enrico,
Actually I've become used to the standard github commit emails and clicking on the link for the diff.
Especially for large changes like geany.html or geany.glade (despite Matthew and Colomban "promising" the diffs will get smaller with 3.8.1) not being blasted by large diffs is good. I can choose what I want to see, and don't get the two line diff of geany.txt cut off because the huge geany.html diff exceeds the size limit.
I don't suppose that you could let registration for the commit ML allow a choice of which we want?
Nope. The only option would be two separate mailing lists.
Though the general idea about the diffs was to limit the diff size to something like 100kb (as it was before in the SF SVN commit mails) or any other value which we consider reasonable.
Or make it so no diff is shown for autogenerated files like geany.html and geany.glade ?
It'd be the best of both worlds then, IMO.
Yeah, a little hackish but would solve the problem probably well enough together with a general max commit diff size limit.
Why not, until we finally understand how the $@!% Glade choose to output in one order or another. But please keep the info the file got modified, don't drop it entirely :)
Cheers, Colomban
On Fri, 20 Jan 2012 19:54:17 +0100, Colomban wrote:
Le 15/01/2012 23:53, Enrico Tröger a écrit :
On Sun, 15 Jan 2012 13:35:35 -0800, Matthew wrote:
On 01/15/2012 12:03 PM, Lex Trotman wrote:
[...]
What do you think?
If we agree to change the commit mails to this format, I'd deploy the script soon.
I'd very much like it, and I'm fine with the format :)
Ok, so I'll change the hook at Github soon and we get some kind of live test :).
Or make it so no diff is shown for autogenerated files like geany.html and geany.glade ?
It'd be the best of both worlds then, IMO.
Yeah, a little hackish but would solve the problem probably well enough together with a general max commit diff size limit.
Why not, until we finally understand how the $@!% Glade choose to output in one order or another. But please keep the info the file got modified, don't drop it entirely :)
The information about the change is kept of course, only the actual diff is skipped. However, I recently noticed Github doesn't even the diff for big changes via their API. I don't know yet what's the exact limit but for the commit 75ff98a2b6ed8deadbcf71a47e5f03e4b43c014f there is no diff included in the API response while it is for other commits. Maybe that's already enough.
For the curious, try:
curl https://api.github.com/repos/geany/geany/commits/75ff98a2b6ed8deadbcf71a47e5...
vs.
curl https://api.github.com/repos/geany/geany/commits/21cd7bb2139fd67644e5777bb8e...
and compare files[x]['patch'] in the response.
Regards, Enrico
On 21/01/12 11:38, Enrico Tröger wrote:
On Fri, 20 Jan 2012 19:54:17 +0100, Colomban wrote:
Le 15/01/2012 23:53, Enrico Tröger a écrit :
On Sun, 15 Jan 2012 13:35:35 -0800, Matthew wrote:
On 01/15/2012 12:03 PM, Lex Trotman wrote:
[...]
What do you think?
If we agree to change the commit mails to this format, I'd deploy the script soon.
I'd very much like it, and I'm fine with the format :)
Ok, so I'll change the hook at Github soon and we get some kind of live test :).
Done. Any new commit mails will be sent from the script (which I will publish in some repository).
Regards, Enrico
On 22/01/2012 15:50, Enrico Tröger wrote:
Ok, so I'll change the hook at Github soon and we get some kind of live test:).
Done. Any new commit mails will be sent from the script (which I will publish in some repository).
Just pushed two commits - they got split into two mails and include the diffs - thanks :-)
Nick
On Wed, 25 Jan 2012 16:09:53 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 22/01/2012 15:50, Enrico Tröger wrote:
Ok, so I'll change the hook at Github soon and we get some kind of live test:).
Done. Any new commit mails will be sent from the script (which I will publish in some repository).
Just pushed two commits - they got split into two mails and include the diffs - thanks :-)
Yepp. Liked that too.
Cheers, Frank
Am 25.10.2011 01:23, schrieb Matthew Brush:
I do like having the diffs in the mails normally, but I also don't much mind clicking a hyperlink to see a well coloured and laid out diff.
I'd actually prefer clicking+colored over in-mail.
OTOH I couldn't care less because I'm not subscribed to the (or any) commit mailing list so my opionion doesn't count :)
Best regards.
On Tue, 18 Oct 2011 20:03:09 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
For example, the Xfce guys have a simple Shell script to do the job and it does it as I would wish: http://git.xfce.org/admin/xfce-git-hooks/tree/hooks/update-03-send-commit-ma...
An example mail: http://mail.xfce.org/pipermail/xfce4-commits/2011-October/023580.html
What do you think?
+1