On Jul 12, 2013, at 9:40 AM, Geert Janssens <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
