OK, I was going to implement write support before posting it up here, but glad you guys like it.
There's tons more to do :)
A git implementation in pure JavaScript
11–20 of 38 posts
Re: A git implementation in pure JavaScript
#12Re: A git implementation in pure JavaScript
#13FYI, it only does reading but it's still very impressive. I've tried out the demo and it just works against small repos. It's very slow against larger ones.
Did the "rake demo" work fine? Any problems figuring out what to do?
Re: A git implementation in pure JavaScript
#14why?
I've never understood why this question is asked on Hacker News. Can you really not imagine why someone would try to do this, even as just an intellectual exercise?
Depends if porting code from one procedural language to another is an "intellectual exercise" (it usually isn't). Compare with the x86 emulator written in JS that we saw a few months back.
That said, viewing a git repo in a web browser by querying the repo over HTTP directly is pretty damn cool.
Re: A git implementation in pure JavaScript
#15OK, I was going to implement write support before posting it up here, but glad you guys like it. There's tons more to do :)
this looks really cool. i was actually working along the same lines (https://github.com/chrisdickinson/tempisfugit) to get a pure JS git implementation, though now I'm a little disconcerted since your project looks so fully featured :) One question: I noticed that you got dakongai's js-deflate library working with git -- I had tons of problems with getting it to read deflated git objects (mostly, that it wouldn't deflate them at all), and I had to turn to jxgcompressor (eventually) to get inflate to work. Before I saw this, I was planning on shimming in compression support by including a simple flash-to-js bridge; but if dakongai's library works I'd definitely rather use it. Again, awesome work!
Re: A git implementation in pure JavaScript
#16OK, I was going to implement write support before posting it up here, but glad you guys like it. There's tons more to do :)
this looks really cool. i was actually working along the same lines ( https://github.com/chrisdickinson/tempisfugit ) to get a pure JS git implementation, though now I'm a little disconcerted since your project looks so fully featured :) One question: I noticed that you got dakongai's js-deflate library working with git -- I had tons of problems with getting it to read deflated git objects (mostly, that it wouldn't d…
Nice! Looks like we've done a lot of the same stuff here. Does tempisfugit require filesystem git repos currently?
Yes, there were a few issues with js-deflate, but once I figured out exactly what zlib was and what js-deflate does it fell into place. I also had to patch it to support returning the length of the compressed data read, otherwise there was no way to know how much of the stream it had consumed.
Re: A git implementation in pure JavaScript
#17why?
Because git is the distributed object database of our time, and JavaScript the ubiquitous execution environment. Useful, no?
Re: A git implementation in pure JavaScript
#18why?
I've never understood why this question is asked on Hacker News. Can you really not imagine why someone would try to do this, even as just an intellectual exercise?
Perhaps he has sufficient imagination to come up with two or three possible reasons why someone might do this, and hence is asking so as to find out which is the actual reason.
By asking, he might learn something, especially if the reason turns out to be one he had not thought of.
Re: A git implementation in pure JavaScript
#19The node.js JavaScript surge reminds me a bit of the early days of Java, where everyone went to implement whatever existed in C/C++ for Java. Only that this time people stick a ".js" in the end instead of a "J" in the front.
If history has a lesson, most of this will not be wildly successful, because the js environment is not suitable for the task to be an actual practical solution.
Re: A git implementation in pure JavaScript
#20The node.js JavaScript surge reminds me a bit of the early days of Java, where everyone went to implement whatever existed in C/C++ for Java. Only that this time people stick a ".js" in the end instead of a "J" in the front. If history has a lesson, most of this will not be wildly successful, because the js environment is not suitable for the task to be an actual practical solution.
Surely if that bit of history says anything then this will be successful? There is a big incentive for languages to reimplement natively, for Java it was cross platform consistency and security, for js in the browser it is complete unavailability of a native code API. (for node.js I am not really convinced though).
Sure there are some issues with js, eg binary support in browser is painful, and it is slow, but Java started off slow and lacking features too. It is improving.
Is now a good time to work on things like this? Why not. Especially if they feed into language and API improvements.