Re: [EGIT PATCH] Branch bar in resource history.

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

Roger Carneiro Soares <rogersoares@intelinet.com.br> wrote:
> >Another idea would be to allow the user to filter which branches and I 
> >think
> >one could combine this indicator with that functionality through e.g. a 
> >poup menu. 
>   
> This would be really nice :)
> 
> Some time ago I wrote a quick hack to show only the commits in the 
> current branch and it's been very useful for us. It isn't implemented 
> the proper way but I consider it simple and safe and others may find it 
> useful too... I'll review it later and post a patch for you to decide.

Now that we have index v2 support implemented my current project
has been "proper" revision machinary for jgit.  Mostly because I
found the History pane too damn slow to be useful, but also as I
need it for the packer for a push implementation.

I have most of the machinary implemented and am right now working on
the path limiter / history simplification.  I already have features
like "--author" and "--grep" working to filter commits, as well
as the commit set difference like "^A ^C B D".  Its wicked fast;
about the exact same speed as C Git, from the time my test "main"
gets invoked to the time I have the full results.

Not unsurprisingly jgit bottlenecks in about the exact same major
areas that C Git bottlenecks, and in about the exact same ratio.
If I remember what JProbe was telling me correctly its about 30%
in zlib's inflate(), 30% in commit parsing, and 30% in the rest of
the lookup-packed-object code.

Pack v4 was being created to reduce the 60% inflate()+parse costs,
as that is the major impact to C Git.

In short, I'm not sure I can squeeze too much more out of jgit.
Given that I'm really close to C Git I think we're nearing the
point where it just can't get faster.

The above mentioned revision machinary is a completely new set of
code in jgit.  I'm basically abandoning the work Robin has done on
this previously.  I also am moving away from the Commit and Tree
classes in favor of smaller, lighter abstractions that perform
better when faced with 17,000 commits.

Most of this code is in my spearce fork of egit in my sp/revwalk
branch, but a good chunk isn't pushed up there yet.  Its not ready
to be merged, but maybe in another week.

-- 
Shawn.