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

Fri Jul 12 19:08:08 EDT 2013

On Jul 12, 2013, at 12:14 PM, John Ralls <jralls at ceridwen.us> wrote:

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

Confirmed: It doesn't matter. A single commit, even a git tag -a or a git merge, has a subject line. Here's what I've written:
Single commit:

  Subject: gnucash trunk: Update Danish TRanslation, copied from the Translation Project.

Multiple commits:
  Subject: Multiple changes pushed to gnucash master

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

Having looked at the script again, I find that the "from" line is generated only on fast-forward pushes. With multiple commits one gets:

The master branch has been updated
       via  https://github.com/Gnucash/gnucash/commit/f1e77948 (commit)
       via  https://github.com/Gnucash/gnucash/commit/5126d491 (commit)
       via  https://github.com/Gnucash/gnucash/commit/7fd6e8b5 (commit)
       via  https://github.com/Gnucash/gnucash/commit/96d99d73 (commit)
      from  https://github.com/Gnucash/gnucash/commit/32203b08 (commit)

The subject line already says the project and branch, so I don't think we need the lead-in line. If one of the commits is a merge, the parent from the other branch isn't going to be mentioned in that list, but a link to both of them will be present on the github page. For example:

If the commit isn't a fast-forward -- and by the way, even when svn isn't in the loop, force pushing to a public repo is rude and should be avoided -- it prints a rather convoluted message with a diagram.

Here's what a merge commit looks like. I've changed the url bit so that the changes point to live links, and changed the custom_showrev to git log -n 1 --oneline to keep things short:

To: jralls at ceridwen.us
Subject: Multiple changes pushed to gtk+ gtk-2-24
X-Git-Refname: refs/heads/gtk-2-24
X-Git-Reftype: branch
X-Git-Oldrev: https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=1eb0d98d
X-Git-Newrev: https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=f2b74db5

The gtk-2-24 branch has been updated
       via  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=f2b74db5 (commit)
       via  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=6056f185 (commit)
       via  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=f52befa7 (commit)
       via  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=7860500b (commit)
       via  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=a591a153 (commit)
       via  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=ebb2977a (commit)
       via  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=925147af (commit)
      from  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=1eb0d98d (commit)

f2b74db Bug 626499 - GtkClipboard unnotified on change of OS X pasteboard owner
6056f18 Merge branch 'bgo658280-filechooser-recently-used-2-24' into gtk-2-24
f52befa Revert "Add items to the shortcuts bar's popup menu to configure the startup mode"
7860500 Add items to the shortcuts bar's popup menu to configure the startup mode
a591a15 Switch to Recent Files or $CWD at startup
ebb2977 New settings key for the startup mode
925147a New way to show $CWD in the shortcuts

Summary of changes:
 gtk/gtkclipboard-quartz.c    |  63 ++++++++++++++++----------
 gtk/gtkfilechooserdefault.c  | 102 ++++++++++++++++++++++++++++++++++++++++---
 gtk/gtkfilechooserprivate.h  |   8 ++++
 gtk/gtkfilechoosersettings.c |  55 +++++++++++++++++++++++
 gtk/gtkfilechoosersettings.h |   5 +++
 5 files changed, 206 insertions(+), 27 deletions(-)

1eb0d98d is actually one of the parents of the merge commit, 6056f18, the other one being f53befa. There's no way to tell that from this email. I suggest changing that section to look like:

Commits in this push:
  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=f2b74db5 (commit)
  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=6056f185 (commit)
  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=f52befa7 (commit)
  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=7860500b (commit)
  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=a591a153 (commit)
  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=ebb2977a (commit)
  https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=925147af (commit)

The other thing that I notice is that the summary of changes is for the whole push. That's fine if all of the commits are about more or less the same thing, but it might be puzzling if they're a bunch of unrelated bug-fixes. I'm inclined to say that we should remove the summary at the end of the message and incorporate it into the per-change log instead by changing custom_showrev to either "git log -n 1 --stat %s" or "git log -n 1 --patch-with-stat %s" depending upon which list it's going to.

Comments, anyone?

Regards,
John Ralls