+ New docEdit page with links from docPage and docList
+ Bespoke menu system with full screen edit mode
+ npm required for building client side scripts
+ Ant script added for BuildUI which performs npm commands
+ Update font-awesome to 4.5.0
+ Factor out to JGitUtils common code in BranchTicketService for EditFilePage
	+ getTreeEntries
	+ commitIndex
+ Merge capability for document editing

+ GitLFS client support
+ FilestoreModel now parses meta file
+ Read meta heading from cache if available
+ Authentication based on accept headers for browser view filestore login
+ PathModel & PathChangeModel now understands filestore items
+ Zip & Rar downloads contain include filestore items
+ Filestore servlet returns LFS JSON error only if accepted by client
+ DiffStat now knows repository to allow identification of filestore items
+ Filestore items identified and returned via view, raw & blob links on
blame, commitDiff, commit and Tree pages

+ Metadata maintained in append-only JSON file providing complete audit
history.
+ Filestore menu item
	+ Lists filestore items
	+ Current size and availability
	+ Link to GitBlit Filestore help page (top right)
+ Hooks into existing repository permissions
+ Uses default repository path for out-of-box operation with Git-LFS
client
+ accessRestrictionFilter now has access to http method and auth header
+ Testing for servlet and manager

The projects page was showing the project listing directly under the navbar
with no spacing. This adds spacing to have the elements offset.

The table is showing using the common "repositories" class, however it can't
be changed directly since several other table displays use the same class, and
have adequate top margin spacing. We create a new class for the one-off use
on the projects page.

Pixel difference uses CSS mix-blend-mode, which is supported currently
only on Firefox >= 32 and on Safari >= 7.1. Implementation is behind a
Javascript feature test.

For other browsers, there's a blink comparator.

Code changes:

* ImageDiffHandler now takes the page it's used on as argument. We need
  that to get labels. DOM generated is a
  little bit different (new controls).
  
* Diff pages adapted to new constructor of ImageDiffHandler.

* CSS and Javascript changes implementing the new controls, making use
  of two new static image resources. Since I felt that the new controls
  deserved tooltips, I also gave the opacity slider a tooltip: changed
  to <a>, and slider handle changed from <div> to <span>. CSS ensures
  everything still displays the same (basically display:inline-block).
  
* Supplied messages for English, French, and German for the new
  tooltips.

Tested on IE8, Safari 6.1.6 & 7.1, Chrome 38, FF 33.1 & FF 3.6.13

Since the new imgdiff UI heavily used gradients, this leaves IE9 and
IE8 users with a complete disfunctional UI.

Replaced all gradients by simpler means:

* Vertical handle: instead of 2px wide gradient, use a 1px background
  and a white border-right
  
* Opacity slider: No gradient but a simple border and background-color

* All radial-gradients replaced by small pre-computed PNGs

* Checkerboard background done with a small repeated PNG

With these changes, the imgdiff UI is fully functional even in IE 8.
Visual changes in other browsers are barely discernible.

This works better for small images. The previous CSS-resize based
attempt worked reasonably well, but had two problems on WebKit
(Safari):

1. For very small images the red resize handle would overlap the image
   itself. In that case, the image became un-draggable as soon as the
   opacity was reduced below 1.0.
   
2. Safari apparently doesn't send mousemove events during a CSS
   resize, so the opacity was changed only on mouseup.
   
Both observed on Safari 6.1.6 and 7.1. FF 33.1 had no problems.

Therefore I've switched to a Javascript slider. Since I didn't find
any that was simple, did not require HTML 5, appeared to be well
maintained, had a bug tracker and not too many outstanding bug reports,
didn't pull in umpteen other dependencies, didn't suffer from feature
bloat, was compatible with jQuery 1.7.1, and was freely licensed, I
ended up writing my own.

imgdiff.js contains a small Javascript slider (only horizontal) that is
styled completely in CSS. It reports ratios in the range [0..1] and
fires nice jQuery events 'slider:pos' on value changes. Base element
is a plain div that is positioned. It's not a general-purpose do-it-all
slider, but it's small, simple, and works for what we need it.

(imgdiff.js also sets up the ese sliders on the diff pages.)

Using the browser's built-in slider doesn't work if the browser hides
scrollbars (like Firefox on Mac). So,construct our own slider with
three divs and some CSS. Event-handling Javascript changed to match
this new implementation.

* ImageDiffHandler adds the slider; styled in gitblit.css
* imgdiff.js is a little bottom-loaded Javascript that adjusts the
  opacity on sliders' scroll events.
* The three diff pages add this bottom script to the page if needed
* GitBlitDiffFormatter: center image diffs.

Ticket 88: https://dev.gitblit.com/tickets/gitblit.git/88

Based on Lea Verou's pure CSS slider:
http://lea.verou.me/2014/07/image-comparison-slider-with-pure-css/

* Add a callback interface, pass it through DiffUtils to the
  GitBlitDiffFormatter. Is needed because the rendering needs access
  to the repositoryName and other things that are known only at higher
  levels.
  
* New class ImageDiffHandler responsible for rendering an image diff.
  Called for all binary diffs, doesn't do anything if it's not an
  image. HTML is generated via JSoup: no worries about forgetting to
  close a tag, not about HTML escaping, nor about XSS.
  
* The 3 diff pages set up such an ImageDIffHandler and pass it along.

* CSS changes: from Lea Verou, with some minor improvements.

I think in the long run there'll be no way around rewriting the
HTML diff formatter from scratch, not using the standard JGit
DiffFormatter at all.

To ensure the line number columns never get squashed.

- As discussed:
  - gutter a little lighter, context lines nearly but not quite
    white.
  - 2px left (and right) padding in the code column.
- I also noticed that somehow all lines were spaced vertically a little
  wider than on dev.gitblit. Added cellpadding='0' to get the old line
  height again.

- Add the new settings to gitblit.properties
- Highlight trailing whitespace

* Optimize CSS: simplify selectors. That alone cuts rendering time in
  half!
* Adapt HTML generation accordingly.
* Change line number generation so that one can select only code lines.
  Also move the +/- out of the code column; it also gets in the way
  when selecting.
* Omit long diffs altogether.
* Omit diff lines for deleted files, they're not particularly
  interesting.
* Introduce a global limit on the maximum number of diff lines to show.
* Supply translations for the languages I speak for the new messages.

https://code.google.com/p/gitblit/issues/detail?id=450 was about a diff
with nearly 300k changed lines (with more then 3000 files deleted). But
one doesn't have to have such a monster commit to run into problems. My
FF 32 become unresponsive for the 30+ seconds it takes it to render a
commitdiff with some 30000 changed lines. (90% of which are in two
generated files; the whole commit has just 20 files.) GitHub has no
problems showing a commitdiff for this commit, but omits the two large
generated files, which makes sense.

This change implements a similar thing. Files with too many diff lines
get omitted from the output, only the header and a message that the
diff is too large remains. Additionally, there's a global limit on
the length of a commitdiff; if we exceed that, the whole diff is
truncated and the files not shown are listed.

The CSS change improves performance by not using descendant selectors
for all these table cells. Instead, we assign them precise classes and
just use that in the CSS.

The line number generation thing using data attributes and a :before
selector in the CSS, which enables text selections only in the code
column, is not strictly XHTML 1.0. (Data attributes are a feature of
HTML 5.) However, reasonably modern browsers also handle this correctly
if the page claims to be XHTML 1.0. Besides, the commitdiff page isn't
XHTML compliant anyway; I don't think a pre-element may contain divs
or even tables.

(Note that this technique could be used on other diff pages, too. For
instance on the blame page.)

- Severity: more severe are ROY, less severe are GB
- Replaced first-letter of severity with S# and show # dots
- Priority: higher priorityare RO, lower priority is B

I really like the 'C, 'CA' idea but that will definitely lead to translation questions. The S# approach will still generate the same complaints, but at least it is more generic.

+ Severity indicated via new character indicator and color of ticket icon on ticket list
+ Priority indicated via new priority icon and color on ticket list
+ Indexed as integers to provide sorting and maintain language neutral
index
+ Colours and indicator text controlled through CSS classes priority-<x> & severity-<x>
+ UITicketTest created to generate tickets of all types to ease debugging

Added links to Repositories containing the tickets.

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

Imported the reference implementation contributed by syntevo which
is used in their SmartGit product.  You may create a bugtraq config
section inf your .git/config file OR you may add a .gitbugtraq file
to the root of your repository.

Example:

    [bugtraq "issues"]
        url = http://code.google.com/p/gitblit/issues/detail?id=%BUGID%
        logRegex = "[Ii]ssue[-#:\\s]{1}\\d+"
        logRegex1 = "\\d+"
    [bugtraq "[pullrequests"]
        url = "https://github.com/gitblit/gitblit/pull/%BUGID%"
        logRegex = "(?:pull request|pull|pr)\\s*[-#]?([0-9]+)"

Change-Id: Iaba305bf4280d08cc4d1abf533c2f1365470a43f

Blame output is now colored according to Commit (default), Author or
Age. Both Commit and Author output uses random colors whereas Age uses a
single color with varying tints applied to indicate the age.  White
indicates the eldest commit with the tint darkening as the commits get
younger.

Change-Id: I045458329af4765e91d5829ce3e8d28e21eeb66e

Change-Id: I6935fa45598da847936748b474a3da47e94efaac

Change-Id: I0eb217064abc4f4b0f6bfbbc21302c470cc2f9c6

Change-Id: I717e13d1f852a4adf50b547f4769dd62da2384ce

Change-Id: Ie81e94546868a4a16c302ed0b283ac86d3491276

All WikiLinks must be specified relative to the root of the repository.
The displayed link text is stripped to just the document name. Spaces in
the document name are replaced with '-' characters; this is consistent with
wiki syntax and Github.

Change-Id: Id3fb1b5441352d9bacc4993a5b85882db113693b

Change-Id: I0f6551bb7ca2f9b8908e95359b375c23daeab380

Change-Id: I8f26746a611e9ab955efe8b2597cc81db48fb085

The graph is generated server-side and therefore requires that the
commit table row height be fixed and match the row height of the
servlet.  There will be layout misalignment if remotes refs are
displayed.  Perhaps this can be improved in the future.

Change-Id: I39d0ffc7b1c3679976ce8c198c772ff86238f1a5

Renamed pushlog to reflog to better match it's current and future purpose.
Split PushesPanel into ReflogPanel and DigestsPanel.
Overhauled project pages and gave them a coherent purpose from the dashboard.

* Properly support timezone-based date groupings
* Polish css for the major browsers on Win & Linux
* Use Gitblit constants for refs instead of JGit constants

This is a work-in-progress and is mostly working like I want, but will require
some refactoring to make it even more useful and less complex.