Roger Carneiro Soares <rogersoares@xxxxxxxxxxxxxxxx> 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. -- 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
