| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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-clean is much faster and more reliable...
Also add confdefs.h in gitignore, although this file is normally removed
at the end of the configure script.
|
|
If notifications for multiple commits are created, sort them
chronologically instead of in reverse chronological order.
|
|
Signed-off-by: Thomas Guyot-Sionnest <dermoth@aei.ca>
|
|
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.
|
|
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/
|
|
|
|
|
|
sfsnapshotgit:
- Use fetch/reset instead to pull to avoid merges on forced updates
sfsnapshot-upload:
- Fix link deletion walking the entire home dir
- Allow CLEAN_TIME=0 (no retention)
- Re-add per-branch links when CLEAN_TIME > 0
- Add many comments
|
|
Now that we moved our Git repositories to SourceForge, we don't need to
maintain local clones for generating commit notifications anymore, as
SourceForge provides shell access to the repositories. Instead, we now
run git-notify as a post-receive hook on the SourceForge server.
Actually, we use a wrapper which executes git-notify with the desired
options and which makes it easy to add other post-receive hooks in the
future.
|
|
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.
|
|
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.
|
|
Use better labels for the tag ref and the SHA1 name of the tag object.
|
|
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).
|
|
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.
|
|
If the new "-T" option is specified or "notify.emitRepository" is set,
the subject of e-mail notifications will be prefixed with [<tag>], where
<tag> is the name of the updated repository.
|
|
If the new "-A" option is specified (or "notify.omitAuthor" is set), the
author name will be omitted from the subject of e-mail notifications.
|
|
The SHA1 object name part of Gitweb URLs is now only shortened if the
user requested this by specifying the new "-z" option (or by setting
"notify.shortURLs").
While at it, also shorten the additional URL which references a diff in
e-mail notifications which don't include that diff inline because its
size exceeds the maximum number of bytes specified via "-s".
Note that while the abbreviated SHA1 object names will be unique at push
time, this cannot be guaranteed for the future, so the shortened URLs
might break some day.
|
|
Only the author's name and address will now be mentioned in a commit
notification by default. However, if the "-C" option is specified (or
"notify.showCommitter" is set), the committer's name and address will
also be included in the notification if the committer is not the author
of the commit (as we previously did by default).
|
|
Making use of a state file in order to prevent duplicate notifications
is now optional. The user must explicitly specify a file path via the
"-t" option or by setting the git-config(1) variable "notify.statefile"
to activate this functionality.
|
|
As nothing in git-notify depends on the success of the mail(1) call,
don't abort if it fails, just spit out a warning.
|
|
Now that we don't ignore empty commits anymore, there's no need to keep
track of the number of commits actually notified about, as that will
always be equal to the number of commits returned by get_new_commits().
|
|
This reverts commit db63fbfa036f5cd757aedf4547fef9e195a8c285, as it is
no longer needed and we'd like to keep the diff against the git-notify
version maintained by the Wine people as small as possible. The purpose
of db63fbfa was to suppress notifications on empty merge commits, which
can now be requested directly by specifying git-notify's "-X" option.
(Our change was implemented before the "-X" option was available, even
though the Git history suggests otherwise.)
Conflicts:
tools/git-notify
|
|
This reverts commit 5445b9769f254781e482062bacc6603a5cd63059. Alexandre
Julliard pointed out that the code in question was used if git-notify
was explicitly called with the SHA1 name of an annotated tag object. At
the moment, the code in question actually _is_ unused due to later
modifications, but it wasn't at the time 5445b976 was committed, and
we'll add further changes so that the code will be used again in the
future.
Conflicts:
tools/git-notify
|
|
Fix the description of the "-U" option.
|
|
|
|
|
|
For shared repositories, the state file used by git-notify should
usually be group writable, so we now set the umask to 0002 by default.
This can be adjusted by setting the "notify.umask" configuration key or
by using the "-U" option on the command line.
|
|
The gitweb_url() subroutine was an unused and empty hangover.
|
|
The sed(1) command in question was a hangover which had no effect
anymore.
|
|
Properly check the exit status of all processes we execute and abort on
error.
|
|
Make sure that commit messages which use an encoding other than US-ASCII
or UTF-8 are handled correctly. Also, assume that the diff contents use
the same encoding as the commit message. This assumption may well be
wrong, but that's the best we can do.
|
|
Never notify on a given commit more than once, even if it's referenced
via multiple branch heads. We make sure this won't happen simply by
maintaining a list of commits we notified about. The file path used for
saving this list can be specified using the new "-t" option. (The
contrib/hooks/post-receive-email script distributed with Git tries hard
to avoid such a list, but it doesn't get the necessary magic right.)
|
|
Instead of using the full SHA1 values of commit object names within
Gitweb URLs, try to abbreviate them to a shorter unique name.
|
|
In commit notifications, specify the Gitweb URL (if any) at the bottom
of the ASCII "table" which summarizes the commit. That looks better.
|
|
If the first line of a commit message is longer than 50 characters,
truncate it before adding the resulting string to the subject line of a
notification. This makes sure the subject line won't get too long
(unless the commit author name is unusually long, which we don't check).
The Git User's Manual recommends keeping the first line of a commit
message shorter than that, anyway:
| Though not required, it's a good idea to begin the commit message with
| a single short (less than 50 character) line summarizing the change,
| followed by a blank line and then a more thorough description. Tools
| that turn commits into email, for example, use the first line on the
| Subject line and the rest of the commit in the body.
[ http://www.kernel.org/pub/software/scm/git/docs/user-manual.html ]
|
|
Do not only generate notifications on commits, but also if a branch head
or lightweight tag was created, removed, or modified. Notifications on
branch head updates are omitted if one or more commit notification have
been generated and the branch head now references a descendant of the
originally referenced commit (which should be the usual case).
|
|
Add a subroutine which abstracts away executing git-rev-list(1) and
checking the result in order to avoid code duplication.
|
|
If the committer is not the author of the commit, mention the committer
in addition to the author.
|
|
Most notifications include an ASCII "table" with two columns. The
formatting of these columns is now handled by the new format_table()
subroutine, so that the alignment can easily be changed in the future.
|
|
Omit notifications regarding commits which don't change the tree
whatsoever.
|
|
The code which handles notifications regarding tags was unused, as only
objects listed by git-rev-list(1) are considered, and git-rev-list(1)
never spits out the sha1 of a tag object.
|
|
Adjust the regular expression which catches the commit author name so
that it doesn't include the space character which follows that name.
|
|
Import the (self-written) git-update-mirror script, which updates clones
of Git repositories and then calls git-notify (in just the same way as a
post-receive hook would be called by Git). The git-notify script is
imported from git://source.winehq.org/git/tools.git (commit: 03d66f34)
and generates notifications on repository changes. We'll use these
scripts for generating our commit e-mails.
|
|
|
|
|
|
|
|
|
|
|
|
|
