| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
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.
|
