monitoring-plugins/tools/git-notify, branch sthen_pkg_confMonitoring Plugins
https://www.monitoring-plugins.org/repositories/monitoring-plugins/atom?h=sthen_pkg_conf2014-01-19T19:18:47ZProject rename initial commit.2014-01-19T19:18:47ZMonitoring Plugins Development Teamdevel@monitoring-plugins.org2014-01-18T08:40:24Zurn:sha1:63734f52ab1b4b2c17545b26fc41016d6bbd80bd
This is an initial take at renaming the project to Monitoring Plugins.
It's not expected to be fully complete, and it is expected to break
things (The perl module for instance). More testing will be required
before this goes mainline.
git-notify: Be careful with "--no-merge"2010-07-02T13:28:35ZHolger Weissholger@zedat.fu-berlin.de2010-07-02T13:28:35Zurn:sha1:319e308521e0e460fe0b06ee093248628dda819d
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 commits2010-04-14T14:22:21ZHolger Weissholger@zedat.fu-berlin.de2010-04-14T14:22:21Zurn:sha1:ee06edc646129bd1ab7f2c1ffe1fbfdf2e8290bf
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:21ZHolger Weissholger@zedat.fu-berlin.de2009-12-07T00:58:21Zurn:sha1:45e205f4a6cf38ff0f8ade027a7b6a6c7376a00c
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 notifications2009-12-06T00:23:41ZHolger Weissholger@zedat.fu-berlin.de2009-12-06T00:23:41Zurn:sha1:78fc8f4909750407585990aa10522d9510a69804
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 repositories2009-11-07T09:40:22ZHolger Weissholger@zedat.fu-berlin.de2009-11-07T09:40:22Zurn:sha1:c3e2186b15901579cec17aca22646b9dddf2363f
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:22ZHolger Weissholger@zedat.fu-berlin.de2009-11-07T09:40:22Zurn:sha1:71351c5a4db3a143ca23d7614c23e80b31bdd15c
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:22ZHolger Weissholger@zedat.fu-berlin.de2009-11-07T09:40:22Zurn:sha1:600fecab6a717aa35df2419a6f5205332dae356e
Use better labels for the tag ref and the SHA1 name of the tag object.
git-notify: Distinguish between tag types2009-11-07T09:40:22ZHolger Weissholger@zedat.fu-berlin.de2009-11-07T09:40:22Zurn:sha1:ecdb5aa53f8e6988c1b013e7fc0725edcac17e2b
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" notifications2009-11-07T09:40:00ZHolger Weissholger@zedat.fu-berlin.de2009-11-07T09:40:00Zurn:sha1:73141bfd92b8baec4dfd45bb99275b53512ec2b9
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.