A git implementation in pure JavaScript

by nephics • 15 years ago

118 36 15 years ago

dropkick• 15 years ago

FYI, 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.

lucraft4• 15 years ago

Yeah. I've thought of a few things to do about that. For instance, we could optimize a repo to have pack files that work well for the browser. [edit] also there's a load of optimization that can be done on the binary parsing. I haven't even started that yet.

lucraft4• 15 years ago

Did the "rake demo" work fine? Any problems figuring out what to do?

lurbina2• 15 years ago

why?

qF• 15 years ago

Because you can. I've made far more useless stuff simply because I felt it would be interesting or a challenge to make. Which in turn are usually the projects I learn the most from.

lurbina2• 15 years ago

I meant why not in Scheme?

hvs2• 15 years ago

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?

ineedtosleep• 15 years ago

I've actually been slowly getting accustomed to this. Before, I used to just drink my hateorade when it came to things like this, but ever since I've started to visit HN more frequently, my tolerance has expanded.

rjh29• 15 years ago

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.

tzs2• 15 years ago

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.

mullr• 15 years ago

Because git is the distributed object database of our time, and JavaScript the ubiquitous execution environment. Useful, no?

tectonic• 15 years ago

Awesome, when this can do writing (presumably with an in-memory store for now), I think there will be some really interesting in-browser version control uses.

mmahemoff• 15 years ago

Pure client-side wiki with version control, for one.

dnewcome• 15 years ago

I thought about doing an in-browser git implementation for enabling offline mode in a webapp. Doing things with git would make some really interesting sync scenarios possible. Looking at what was involved though, I think I'm glad I didn't go down this particular rabbit-hole.

cdcarter• 15 years ago

Another cool tool in this world is CouchDB. A local instance can replicate back and forth with a master when available, and you can serve an entire app right out of the DB.

lucraft4• 15 years ago

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 :)

isntitvacant2• 15 years ago

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!

lucraft4• 15 years ago

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.

azakai• 15 years ago

Cool project!

Did you consider just compiling the C implementation into JavaScript? If so, I'm curious why you didn't go that route.

Nitramp3• 15 years ago

The 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.

justincormack2• 15 years ago

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.

Nitramp3• 15 years ago

Surely if that bit of history says anything then this will be successful?

Not sure. Lots of people reimplemented lots of stuff for Java, but it turns out Java was only successful in the sweet spot for it (networked server side language); it never replaced C/C++ in any meaningful way.

I expect the same with JavaScript, it will flourish in its niche (in particular as it has a monopoly as the in-browser-language), but it won't replace established languages on their respective home turf.

deskamess• 15 years ago

Such efforts may not 'succeed' on the whole.

However there is great benefit to this young language when a popular utility can be implemented to highlight the weakness of a particular runtime implementation, or even the underlying language.

Git/Hg clients touch network io, file io, and rudimentary hashing in the normal execution path. So it makes for a good subject.

jrockway• 15 years ago

Feel free to use Gitteh, then: https://github.com/libgit2/node-gitteh.

There's more than one way to do it.

ltw• 15 years ago

Yet more evidence of Atwood's Law:

Any application that can be written in JavaScript, will eventually be written in JavaScript.

http://www.codinghorror.com/blog/2007/07/the-principle-of-le...

ConstantineXVI• 15 years ago

One could consider this[1] as a full realization of Atwood's Law.

[1] http://bellard.org/jslinux/

nvictor• 15 years ago

what javascript testing library is it using?

A git implementation in pure JavaScript

Related Stories