Notification mails for git repos - resend

[Geert Janssens]

On 07-02-13 16:00, John Ralls wrote:
> On Feb 7, 2013, at 3:19 AM, Geert Janssens <janssens-geert at telenet.be> wrote:
>
>> On 07-02-13 02:37, John Ralls wrote:
>>> You could use "short" commit numbers both for the subject line and the URLs e.g.,
>>> https://github.com/Gnucash/gnucash-docs/commit/8686314
>>> works just fine, which will make it a bit more readable.
>>>
>>> The preamble is way too long. The subject line says what the mail is about: Repo, branch, short changeset hash. The preamble can just be the changeset URL, again with the short hash. No need for the parent, there's a link to it on the Github change page.
>>> Then the log entry, and for patch-mail, the patch.
>>>
>>> Regards,
>>> John Ralls
>>>
>> Thanks for the feedback.
>>
>> I have updated the mail script is several ways as a result:
>> - use short commit hash in the subject line (and put it up front, just like the svn revision number was)
>> - use short commit hashes in all urls
>> - dropped the preamble text and some intermediary text
>> - there are situations where a more complex push exists (non-fast-forwardable pushes which obscure some commits). In that case some additional explanation is added to the mail on what happened. I did not remove that.
>> - I also haven't removed the parent. It may be helpful in some situations and in my personal opinion doesn't add that much clutter.
>>
>> Attached is a new example. Only one this time, because the only difference between the two mails is the amount of detail in the log section, which I haven't changed.
>>
>> Of note still is that the mail is sent by GIT SVN Migration user (git-svn). This is because the mail generation is triggered by the the svn-git push, which is currently always performed by the user account git-svn. With the scripts as they are now, the sending user will be set to the one actually pushing once svn is out of the loop. So if I push directly to a repo in gitolite, the mail will appear to come from me. I can't work around this in the current situation.
> One more niggling comment: "The branch, trunk has been updated" is poor English. Single commas are for separating dependent clauses. You could write "The branch, trunk, has been updated", but that puts the emphasis on branch and makes trunk a parenthetical. Better would be no comma: "The branch trunk has been updated", but I like "The trunk branch has been updated".
I have used your last proposal (the trunk branch has...). See new 
attachment.
> I don't have a problem with the email being from the committer. All of our mailing lists work that way.
I have no problem with that either. My note was not really clear on the 
issue I had: the svn based mails are sent from the real committer's id 
(if you commit the mail will be from jralls, if I commit it will be from 
gjanssens and so on). My intention was/is to copy this behaviour for the 
mails sent from git. This however doesn't work out currently because all 
commits to git are done by the git-svn user (on behalf of the real 
committer). So all git mails will appear to come from git-svn. I 
mentioned this because it is different from the svn behaviour.

Either way, this is only a transient issue: once svn is out of the loop 
the real committers will be seen in the mail's From field. So I don't 
intend to change anything in that area anymore.
> As for non-fast-forward commits, those need to be discussed here before being pushed. It should be an extremely rare occurrence.
Agreed on all aspects. Since these types of commits are supposed to be 
extremely rare, I don't mind either that the mails generated for such a 
push is more verbose. So I don't think this requires more tweaking of 
the notification mail.
>
> Regards,
> John Ralls
>
Geert
-------------- next part --------------
An embedded message was scrubbed...
From: GIT SVN Migration User <git-svn at code.gnucash.org>
Subject: f76dafd0 - gnucash-docs branch trunk updated.
Date: Thu, 7 Feb 2013 10:14:54 -0500
Size: 4183
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20130207/6f4c7927/attachment.mht>