Bug#935136: gitg: noisy assertion to stderr: "g_date_time_difference: assertion 'begin != NULL' failed"

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gitg/issues/73
Control: tags -1 + patch

On Mon, 19 Aug 2019 at 18:53:12 -0400, Daniel Kahn Gillmor wrote:
> try this (without any gitg instance already running):
> 
>     $ git clone https://github.com/libreswan/libreswan
>     $ cd libreswan
>     $ gitg

For a more GNOME-adjacent reproducer, the git repository for libostree
has the same issue.

> The result is a bunch of lines like the following to stderr:
> 
> (gitg:27936): GLib-CRITICAL **: 18:50:32.798: g_date_time_difference: assertion 'begin != NULL' failed
> (gitg:27944): GLib-CRITICAL **: 18:50:36.949: g_date_time_difference: assertion 'end != NULL' failed

gitg's GitgHistory.RefRow.compare_to, when sorting by last activity,
appears to be wrongly assuming that a GgitSignature object's get_time()
always returns non-NULL. The method return is annotated as (nullable) in
libgit2-glib, which I would have expected would cause the Vala compiler
to at least issue warnings here, but perhaps I'm overestimating valac's
ability to understand GObject-Introspection annotations.

(I don't know whether a GitgSignature represents a signed tag or some
more abstract concept like a commit, but either way, I could believe
that git repositories with a long history will have some tags or commits
where the date/time cannot be parsed.)

I don't really know Vala, but the attached seems to work.

    smcv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GitgHistory.RefRow-Don-t-assume-that-every-GgitSignature-.patch
Type: text/x-diff
Size: 1017 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20190820/06c2fb33/attachment.patch>