On Thu, Mar 6, 2008 at 11:08 AM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> wrote: > > > > You will find support in jgit for this today. Cloning over git and ssh real > > soon. I'm clensing the oopses from the history right now. (bless rebase -i > > and git-gui). > > I'm sort of waiting to see this fetch history soon. :-) > > The reason is I just got index v2 support (runtime read side) completed > and I want to add index v2 generation to IndexPack. I also want to start > building a PackWriter so we can work on native transport push over SSH. > > If we get fetch/push running I think we are heading into the area > where it is of some real use to people. > It is great to hear this news :). > > > There might be some operations that might be harder to do well in Java. For > > those exec'ing might be the solution, I'm thinking repack, but then I haven't > > tried it yet. > > I'm determined to even get "proper" packfile generation in Java. > But it may be time consuming to build. There may be license issues > around doing a direct cribbed port of the delta generation. :-\ > > > > In general jgit is almost as fast as git and probably > > outperforms git on windows as git there doesn't use memory mapped I/O for > > packs (something I'd expect someone or even me to fix soon). For JNI'ed > > operations the complexity is just horrible and even when possible, there is > > a lot of overhead for JNI itselt, conversion from UTF-16 to somehing > > eightbitish and back. On windows there's even yet another layer of > > eight-bitish to UTF-16 and back in the Win32 API. Jgit also uses memory > > mapped I/O on all platforms that support it for pack reading. > > > > If someone *did* make a fully reentrant libgit, I'd be inclined to balance my > > opinions differently. > > Really? If jgit is basically as fast as C git, but doesn't have > the overheads of dropping in and out of JNI or fork/exec then you > can actually get pretty good performance out of a Java application. > > I've never really liked doing JNI. I try to avoid it whenever > I possibly can. JVMs just don't seem to be all that happy about > loading other native code into them, but yet they can do some very > good optimizations when everything is 100% pure Java and the JIT > has free reign to do what it pleases. I personally too avoid JNI whenever possible; the only reason I was even thinking of JNI in the first place is just to keep in touch with the latest developments of jGit. But seeing the enthusiasm of the community to contribute in developing a 100% Pure Java Git, I will also participate in development of jGit; I think if we can get it to do the regular operations we can generate enough interest to get a community to regular keep it in sync with git. > > -- > Shawn. > -- Imran M Yousuf Entrepreneur & Software Engineer Smart IT Engineering Dhaka, Bangladesh Email: imran@xxxxxxxxxxxxxxxxxxxxxx Mobile: +880-1711402557 -- 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
