faster egit history page and a pure java "gitk"

["Shawn O. Pearce" <spearce@spearce.org>]

OK, so I decided a few weeks back that the history page was not fast
enough.  I think I've spent the past 3 weeks writing true revision
machinary for jgit, and now connecting it up to a UI visualizer.

  git://repo.or.cz/egit/spearce.git plotter

The history page has been completely replaced.  I saw Roger has
some patches against the current history page.  :-|

There are huge benefits to this infrastructure:

 * Fast as snot.  We are literally just 10-20 ms slower than C Git
   on the same hardware, same repository, for the same tree.  That
   is pretty damn good, given that we are in Java.

 * Faster than gitk.  Yes, really.  My plot algorithm is not nearly
   as good as Paulus' work, but I think its better than what we
   have right now.

 * Nearly instant results without path limiter(s).  If the graph
   doesn't require parent rewrites we are able to show results
   almost immediately, and fill in the rest incrementally from
   the background job.

 * Lower memory usage.  By massive amounts.  I can't even begin to
   tell you how much different it is.  Histories that we could not
   show before can now be shown in <20M.  Our memory usage is much
   lower than that of gitk.

 * Multiple path limiters.  You can select more than one resource
   (or directory!) at once and get the combined history for
   all of them at once.  This is basically the same path limiter
   algorithm that C Git/gitk rely upon for the same sort of query.
   It is still limited to a single-repository, but I think we could
   easily extend it to allow multiple-repository unions.  :-)

 * Parent/child hyperlinks in message viewer.  Like gitk you can
   now click on the parent and child commit SHA-1s to jump up and
   down the graph.

 * Grep options available.  Not implemented in the UI yet, but
   the lower level machinary supports author/committer/log message
   grep functions.

 * Interesting/not-interesting flags available.  Not implemented
   in the UI yet, but the lower level machinary can do things like
   "^foo bar" to show all commits in bar that are not in foo.

 * More modular code.  Its broken apart much better. We don't have
   3000 lines in a single class.

 * Common AWT and SWT drawing.  Most of the UI visualization code
   is implemented in shared code that has no AWT or SWT specifics
   about it.  This makes the renderer completely portable.  I have
   both an AWT and an SWT implementation running (compare from the
   command line "jgit glog HEAD" to the history view in Eclipse).

 * Faster "RevCommit" class.  This class mostly replaces the older
   "Commit" class.  Accessing data out of a RevCommit can be much
   quicker than out of a Commit, plus a RevCommit gets the encoding
   of the author, committer and message correct more of the time.
   The downside is you can only get a RevCommit from a RevWalk,
   or one of its subclasses.

-- 
Shawn.