monitoring-plugins/tools/git-notify, branch hw/http-connect

git-notify: Be careful with "--no-merge"

2010-07-02T13:28:35Z

The "-X" option (which asks git-notify to not report merge commits) was implemented by setting the "--no-merge" option on each invocation of git-rev-list(1). However, we do not only use git-rev-list(1) to get the list of new commits, but also to check whether the old branch head (or tag) is a parent of the new branch head (or tag). For this latter check, the "--no-merge" option should not be set; otherwise, git-notify would be fooled to believe that the branch has been rewritten if the old head was a merge commit.

git-notify: Fix the ordering of commits

2010-04-14T14:22:21Z

If notifications for multiple commits are created, sort them chronologically instead of in reverse chronological order.

git-notify: Pipe e-mails directly to sendmail(8)

2009-12-07T00:58:21Z

Use sendmail(8) instead of mail(1) in order to be able to set the "Content-Type" header field on systems where the available mail(1) command doesn't allow for setting it. This makes the "-H" flag (cf. commit 71350c5a) unnecessary.

Enable CIA's commit notifications

2009-12-06T00:23:41Z

We now use CIA's service to send commit notifications to IRC. They are currently sent to the #Nagios-Devel channel on Freenode. See: http://cia.vc/stats/project/nagiosplug/ http://cia.vc/account/bots/15699/

git-notify: Support SourceForge repositories

2009-11-07T09:40:22Z

The Gitweb URLs for repositories hosted by SourceForge are slightly different than other Gitweb URLs. The correct URL cannot be specified via "-u" if we append "/$repos_name.git/?" to that URL as we usually do. If the new "-S" flag is specified or "notify.sourceforge" is set, we'll append "/$repos_name;" instead, which makes the "-u" option usable for SourceForge repositories.

git-notify: Optionally call mail(1) without "-a"

2009-11-07T09:40:22Z

Not all mail(1) implementations support specifying additional header fields via "-a": with some, this flag is used for attaching files, others don't provide an "-a" flag at all (this is true for the /bin/mail utility currently installed on the SourceForge servers, for example). We now provide the "-H" flag and the "notify.legacyMail" configuration key for these cases.

git-notify: Polish up the "tag notifications"

2009-11-07T09:40:22Z

Use better labels for the tag ref and the SHA1 name of the tag object.

git-notify: Distinguish between tag types

2009-11-07T09:40:22Z

Distinguish between annotated tags and lightweight tags. In the former case, send an annotated "tag notification", in the latter case, send a "ref change notification" (as we did in both cases before).

git-notify: Fix "global" notifications

2009-11-07T09:40:00Z

If the number of commits included with a single push exceeds the maximum specified via "-n", a single notification will be generated instead of individual e-mails. For listing the commits within such a notification, git-rev-list(1)'s "--pretty" option is used. This yields output which the git_rev_list() subroutine didn't accept. That's now fixed.

git-notify: Optionally [tag] the subject

2009-11-07T01:23:32Z

If the new "-T" option is specified or "notify.emitRepository" is set, the subject of e-mail notifications will be prefixed with [], where is the name of the updated repository.