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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
