Notification mails for git repos - resend

[John Ralls]

On Feb 7, 2013, at 7:25 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

> 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.

Looks fine to me.

>> 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.

Do we want to be sending commit-mail from gitolite while we're still committing to svn? ISTM that's something to turn on after we drop svn. Not that you shouldn't have done the work, of course. It's good to have everything ready, even if it's another year before we release 2.6 and switch to git for everything... just like last week's discussion about branching strategies.

Regards,
John Ralls