no git patchset from .news files? (was Re: gnucash-htdocs branch master updated. svn_last-12-g3580119)

[John Ralls]

On Jul 12, 2013, at 9:40 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

>> On Thu, July 11, 2013 2:37 pm, John Ralls wrote:
>>> I don't think a complete rewrite is necessary, just a tweak to the code
>>> which writes the subject header: If there's only one change it can write
>>> the first line to the subject, otherwise it can say something like "$repo
>>> $branch received multiple commits".
>> I'm fine with this, too.
> Will this still work for other mail sending scenarios ? Things like adding a tag, or merging branches ?

Good question. I haven't looked at that yet, but I think so. 

>>> A couple of other noise-reducing changes to consider:
>>> 
>>> * Lose the "parent" URL. There's a link for it on the commit page.
>> Which is the 'parent' URL?  Is that the 'from' line?
> Personally the parent URL doesn't bother me. I think for fast-forward pushes it is probably redundant, but the script also deals with merges being pushed, where having the parent immediatly available may be handy. I don't know for sure.
> 
> In any way the gnucash-htdocs repo will not really excercise the mail script. We only have two essentially independent branches there, with a very linear progression.
> 
> It may become more complicated once the main gnucash repository becomes pure git.

It may indeed. I have some more interesting repositories that I can test against... Gtk comes to mind.

>> 
>>> * Suppress printing $LOGBEGIN and LOGEND (the lines with all the hyphens)
>>> unless something's going to get printed between them -- or better yet,
>>> just lose them. It's pretty obvious what's log, what's patch, and what's
>>> summary. They don't need delimiting.
>> I am fine with this change.
> Those lines can be completely removed as far as I'm concerned.
>>> * Lose the footer. "hooks/post-recieve" isn't information.
>> Also fine with this.  Not sure why it is in there.
> Same here.

Those were so easy I took care of them after fixing the alias problem along with the comments about which 
mailing list gets the patches.

I'm a bit concerned about hooks.mailinglist[12] and hooks.showrev[12]. That seems too easy to mess up. Maybe
we could rename them hooks.gnucash-patches, hooks.gnucash-changes, hooks.show-patches, and
hooks.show-comments-only. I'd suggest hard-coding the values in post-receive, but I realize that would break 
your monitoring setup and generate a lot of noise until we fully move from svn.

Regards,
John Ralls