Robin Rosenberg <robin.rosenberg.lists@xxxxxxxxxx> wrote: > Slow it is. It is somewhat usable though, especially the quickdiff. I worked > the whole day with help from quickdiff today. The diff is computed against > HEAD^ (i.e. I get to see the changes that my topmost StGit patch introduces). That's good to hear! > The project contains 20000+ files and six years of history. Reading the whole > history is out of the question with the current performance so I restrict > reading to 500 entries which is just about bearable. That's enough for > practical use with quickdiff and compare though. Improving jgit's speed 50 > times will probably be enough to make jgit shine. Yes. I have a plan on how to rewrite the pack reading code which should help somewhat here. There's some fundamental limitations of Java though that are going to keep us from performing as well as core-Git does (due to the object memory overheads) but I would like to get close. :-) jgit also has a few quirks still. For example it assumes everything is encoded as UTF-8 but this isn't true. The encoding is project specific and can be set by any user, which isn't that portable. This is a problem for jgit and I need to go back and refactor the parsing code... I'd like to get back to jgit sometime in mid-Decemeber. I'm trying to push through git-gui first. :-) > Activating the Git connection seems to be a problem with the egit projects, > i.e. it works sometimes, but not with my much bigger repo. The only problem > is that the first time is dog slow. The structure is different though, as my > repo has .project at the top, not one level down. Hmm. That's a bug. Sounds like a thread timing issue if it works sometimes, as the logic should be completely deterministic. -- 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