We already highlight C/C++ source files with the default configuration,
so we should do this also for header files.

Signed-off-by: Soeren Grunewald <soeren.grunewald@desy.de>

Since perl scripts (.pl) was already supported, add .pm for perl modules

Required for servers that use STARTTLS without SMTPS such as Office 365

Plugins are stored in `${baseFolder}/plugins` and are loaded
during startup by the PluginManager.

A plugin defines it's metadata in META-INF/MANIFEST.MF:

    Plugin-Class: com.gitblit.plugins.cookbook.CookbookPlugin
    Plugin-Dependencies: foo, bar
    Plugin-Id: gitblit-plugin
    Plugin-Provider: John Doe
    Plugin-Version: 1.0

Plugins can define extension points that can be implemented
by other plugins and they can depend on other plugins:

    Plugin-Dependencies: foo, bar

During the load phase, a directed acyclic graph is built and the loading
order of the dependency chain is reversed using a topological sort;
parent followed by children. The parent plugin classloader is the
combined classloader of all parent plugins.

Change-Id: I738821fa2bff02a5dbe339a944cc7e3c4dd8e299

Starting from version 0.9.0 Apache SSHD project added support for NIO2
IoSession. To use the new NIO2 session the `backend` option must be set
to `NIO2`.

By default, `NIO2`.

Change-Id: I06cf92b02e80ecf9e8bfbd9f6d6d623dfe3ccff3

Gitblit would greatly benefit from an integrated SSH server.  This would
complete the transport trifecta.

Change-Id: I6fb95abe65655fa74d47ea71522d8d9a1541450c

Allow to use the LDAP AuthProvider with a LDAP Server
prohibiting anonymous searches but without providing
a manager password : searches are made on behalf of
the authenticated user.

A basic issue tracker styled as a hybrid of GitHub and BitBucket issues.
You may attach commits to an existing ticket or you can push a single
commit to create a *proposal* ticket.

Tickets keep track of patchsets (one or more commits) and allow patchset
rewriting (rebase, amend, squash) by detecing the non-fast-forward
update and assigning a new patchset number to the new commits.

Ticket tracker
--------------

The ticket tracker stores tickets as an append-only journal of changes.
The journals are deserialized and a ticket is built by applying the
journal entries.  Tickets are indexed using Apache Lucene and all
queries and searches are executed against this Lucene index.

There is one trade-off to this persistence design: user attributions are
non-relational.

What does that mean?  Each journal entry stores the username of the
author.  If the username changes in the user service, the journal entry
will not reflect that change because the values are hard-coded.

Here are a few reasons/justifications for this design choice:

1. commit identifications (author, committer, tagger) are non-relational
2. maintains the KISS principle
3. your favorite text editor can still be your administration tool

Persistence Choices
-------------------

**FileTicketService**: stores journals on the filesystem
**BranchTicketService**: stores journals on an orphan branch
**RedisTicketService**: stores journals in a Redis key-value datastore

It should be relatively straight-forward to develop other backends
(MongoDB, etc) as long as the journal design is preserved.

Pushing Commits
---------------

Each push to a ticket is identified as a patchset revision.  A patchset
revision may add commits to the patchset (fast-forward) OR a patchset
revision may rewrite history (rebase, squash, rebase+squash, or amend).
Patchset authors should not be afraid to polish, revise, and rewrite
their code before merging into the proposed branch.

Gitblit will create one ref for each patchset.  These refs are updated
for fast-forward pushes or created for rewrites.  They are formatted as
`refs/tickets/{shard}/{id}/{patchset}`.  The *shard*  is the last two
digits of the id.  If the id < 10, prefix a 0.  The *shard* is always
two digits long.  The shard's purpose is to ensure Gitblit doesn't
exceed any filesystem directory limits for file creation.

**Creating a Proposal Ticket**

You may create a new change proposal ticket just by pushing a **single
commit** to `refs/for/{branch}` where branch is the proposed integration
branch OR `refs/for/new` or `refs/for/default` which both will use the
default repository branch.

    git push origin HEAD:refs/for/new

**Updating a Patchset**

The safe way to update an existing patchset is to push to the patchset
ref.

    git push origin HEAD:refs/heads/ticket/{id}

This ensures you do not accidentally create a new patchset in the event
that the patchset was updated after you last pulled.

The not-so-safe way to update an existing patchset is to push using the
magic ref.

    git push origin HEAD:refs/for/{id}

This push ref will update an exisitng patchset OR create a new patchset
if the update is non-fast-forward.

**Rebasing, Squashing, Amending**

Gitblit makes rebasing, squashing, and amending patchsets easy.

Normally, pushing a non-fast-forward update would require rewind (RW+)
repository permissions.  Gitblit provides a magic ref which will allow
ticket participants to rewrite a ticket patchset as long as the ticket
is open.

    git push origin HEAD:refs/for/{id}

Pushing changes to this ref allows the patchset authors to rebase,
squash, or amend the patchset commits without requiring client-side use
of the *--force* flag on push AND without requiring RW+ permission to
the repository.  Since each patchset is tracked with a ref it is easy to
recover from accidental non-fast-forward updates.

Features
--------

- Ticket tracker with status changes and responsible assignments
- Patchset revision scoring mechanism
- Update/Rewrite patchset handling
- Close-on-push detection
- Server-side Merge button for simple merges
- Comments with Markdown syntax support
- Rich mail notifications
- Voting
- Mentions
- Watch lists
- Querying
- Searches
- Partial miletones support
- Multiple backend options

Change-Id: I3c2281881a74e549aa68c7af46c29422f3ae21bd

Change-Id: I8d33670178284dbfa9e826a931fff693e3a7c5f6

Some environments do not want to automatically allow Windows admin
accounts to be Gitblit admins.  This patch allows disabling/enabling the
relationship between Windows builtin admin accounts and Gitblit accounts.

synchronization is enabled.

sync with ldap

background service. Introduced configuration property to configure the
synchronization period.

Change-Id: I86a1eb61c2351d1cf3f6b3becf00f2a36d5c8ed6

Change-Id: I336e005e02623fc5e11a4f8b4408bea5465a43fd

Change-Id: I421a6b8f8c8eaa5d34b7629858de76fc96458cd3

The mirror executor will fetch ref updates for repository mirrors.  This
feature is disabled by default and can be enabled by setting
git.enableMirroring=true.  The period between update checks is
configurable, but it is global.  An individual rpeository may not set
it's own update schedule.

Requirements:
1. you must manually clone the repository using native git
   git clone --mirror git://somewhere.com/myrepo.git
2. the "origin" remote must be the mirror source
3. the "origin" repository must be accessible without authentication OR
   the credentials must be embedded in the origin url (not recommended)

Notes:
1. "origin" SSH urls are untested and not likely to work
2. mirrors cloned while Gitblit is running are likely to require
   clearing the gitblit cache (link on the repositories page of an
   administrator account)
3. Gitblit will automatically repair any invalid fetch refspecs with a
   "//" sequence.

Change-Id: I4bbe3fb2df106366ae4c2313596d0fab0dfcac46

Change-Id: I82ef161c6b6956c7b83cd4a1c37627beac6ea75b

A new property web.rootLink has been introduced to
customise the link underlying the top-left logo in GitBlit.
When undefined the older behaviour is to link to the
GitBlit home page.

Change-Id: I33966b8292434c10ffd623838d09527aaebaca5f

Change-Id: I74b3f9fedd77294c53648f8eaa730d4a84917555