When processing config options, we now treat these strings as
'1' and '0' so that they can be used as booleans. (Previously,
'false' would evaluate to true by perl string rules.)

... seems useful enough that we ought to just do it by default.

Works fine on our server because the hostname is set right and the
path works out fine. Might work less well on servers configured
differently.

This commit is intended to makes the license status of Emulab and
ProtoGENI source files more clear.  It replaces license symbols like
"EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
blocks that contain actual license statements.

This change was driven by the fact that today, most people acquire and
track Emulab and ProtoGENI sources via git.

Before the Emulab source code was kept in git, the Flux Research Group
at the University of Utah would roll distributions by making tar
files.  As part of that process, the Flux Group would replace the
license symbols in the source files with actual license statements.

When the Flux Group moved to git, people outside of the group started
to see the source files with the "unexpanded" symbols.  This meant
that people acquired source files without actual license statements in
them.  All the relevant files had Utah *copyright* statements in them,
but without the expanded *license* statements, the licensing status of
the source files was unclear.

This commit is intended to clear up that confusion.

Most Utah-copyrighted files in the Emulab source tree are distributed
under the terms of the Affero GNU General Public License, version 3
(AGPLv3).

Most Utah-copyrighted files related to ProtoGENI are distributed under
the terms of the GENI Public License, which is a BSD-like open-source
license.

Some Utah-copyrighted files in the Emulab source tree are distributed
under the terms of the GNU Lesser General Public License, version 2.1
(LGPL).

Problem before was that I was using 'git log' of the commit and
its parent, which doesn't work as I intended when there's more than
one parent. Instead, use 'git show -s', which is helpfully not
documented in the manpage for git-show, but instead the manpage for
git-shortlog

In testmode, pretends the ref was just created.

Renamed old '-C' option '-c'

Note this only applies to the patch at the bottom. Would be good if
it applied to linecount summary and 'inline' patches, but this was
the quick & trivial one to do.

'git revparse --show-toplevel' is a nice way to get a path to the repo
no matter where you are in it, but unfortunately, older versions don't
have it. So, go back to `pwd`

New 'includepatches' option puts a seperate set of patches after all
commit messages. 'patchstyle' allows you to set 'word' to get word
diffs. 'patchsizelimit' (default 1,000) omits patches with more than
this many lines. 'maxpatches' (default 20) skips patch generation if
there are more than this many commits in the message.

For now, these go into headers (X-Git-Repo-Host and X-Git-Repo-Path)
Might consider moving them to the body of the mail at some point.

Note that I *don't* attempt to figure out the actual 'URL' for the
repo, since that is *not* necessarily automatically derivable: eg.
it might be any of ssh,git, or http protocols, and the path (esp.
for git: and http:) might not match the path in the filesystem. So
this suggests that wat goes into the body of the mail ought to be
set with a config variable.

Show the old and new values of the ref, in a form that is suitable for
passing to 'git log', etc. The idea is to make it easier for the reader
of the mail to go look at more detailed information than is in the mail,
if they so choose.

Use short form of the hashes to make it fit nicely into one line
of text.

Currently supports 'hashes' (like the style supported before), and
'bare', whch omits the hashes (but does do a little indenting)

New option 'commitstyle' currently supports:

   default - default style, includes commig log and summary of changed files
   diff    - include a diff, like 'git show' does by default
   wdiff    - like diff, but word-diff (useful for LaTeX, etc.)

Also a new option 'showcommitargs' that allows you to replace the args to
'git commit' completely. Supercedes the old 'showcommitextra' option,
which we weren't using on any of our repos.

When the new 'summarythreshold' config option is set, gitmail will
produce a summary at the top of the mail. This consists of the
abbreviated commit hash and first line of the log message (truncated
to 72 characters to look nice in mail)

Allow you to specify an arbitrary number of commits (instead of 3)
when using test mode

Per-repository 'keywords' may now be configured by setting the
hooks.gitmail.keyword option.  One X-Git-Repo-Keyword header is added
to commit mails for each keyword specified.

The primary use case for this is to configure related repositories
with the same keyword(s), so that commit mails for those repositories
can be filtered with a single rule rather than one for each
repository.

This header contains the reference name (eg. branch name or tag name)
that was modified by the commits in the mail.

... so that we can specify a different path to git if necessary

'archivemail' works exactly like 'alwaysmail', except that any
addresses it contains get separate copies of the mail. This is
intended to keep cleaner 'To' lines when sending mail to
archive-type lists.

This script now generates its own Message-Id header, so that
if more than one piece of mail is generated, they can easily
be detected by duplicate-suppression features of mailers.

'git config' lets you add mutliple values for the same key - support
this for the alwaysmail config variable.

Also add support for adding in a Reply-To header, so that discussions
can be directed to mailing lists, etc.

Add the short sha1 to the end of the subject line for MUAs that thread by
subject instead of References/In-Reply-To headers.

Use 'git diff-tree --no-commit-id --cc' on merge commits to determine if
there are any differences between the merge commit and its parents.
This is the case if any new files were hand-modified or added as part of
the merge (such as when conflicts were resolved).  If git-diff-tree
produces no output, the merge was trivial.

If the merge was trivial, the commit message is checked for an empty
body.  If empty, the commit is skipped when generating the email.  This
way if the committer documents the merge in some way (list of changes,
reason for the merge, etc.) the email includes that information.

- Improved support for lightweight tags
  - Supports create/update/delete
  - Show only current ref pointed to (or previously
    pointed to)

- Show previous value of ref when deleted
  - Useful for recovering from accidental deletions

- Distinguish between rewind and rebase
  - Show only new branch head on rewind
  - Show all commits on rebase if only commit message(s)
    changed (otherwise we wouldn't know about the commit
    at all)

- Minor cleanup (remove duplicate code, etc.)

Also allow tags to be passed in with the -T option.

Refs can contain slashes.  For example, the short ref for
'refs/heads/foo/bar' is 'foo/bar'.  Previously, we just chopped off
everything up to and including the last slash character, which doesn't
return the correct short ref in this case.

Call git-rev-parse to shorten the ref for us.  In case it doesn't return
anything (which shouldn't happen), fall back to the full ref.

Handle forced updates, including rebases.  git-cherry is used to
determine if the commits pushed are present upstream (with a different
hash) or not.  Ones already present are excluded from the commit mail
since they haven't changed (i.e., they point to the same blobs the old
ones did).  Ones not present are either new commits or modified commits.
It's non-trivial to tell which is which, and we probably don't care
anyway.  Added text to 'forced-update' email messages to state that the
commits shown are only the new/modified ones and not all that were
pushed.

point; it took me a while to figure this out.

Add 'excluderepo' option to filter out commits that may exist in another
repository, such as commits to emulab public repositories that exist in
emulab-devel already.

contents of the error that we got back from eval