Live data from Hacker News

A pure JavaScript implementation of Git for Node and browsers

github.com

41–50 of 203 posts

Re: A pure JavaScript implementation of Git for Node and browsers

#41

I did something similar a few years ago. https://github.com/ryanackley/git-html5.js . A lot of the links don't work in the README anymore. It was more of a "this would be cool!" project rather than a library I wanted everyone to use for the next 20 years. One of things that scared me is the responsibility that bugs in something like this could be catastrophic to someone's work. As I built my git library I realized a…

To elaborate on that: There's receive.denyNonFastForwards=true on the server which will deny --force no matter what the client says, and major hosting sites like GitHub and GitLab have "protected branches" which allows protecting say "master" against this, while allowing it on topic branches.

What you ran into is that there's nothing in the protocol itself that makes the client say "this is a forced push". The client just says "update this ref from A->B", and it's expected that it's already read the ref advertisement to see what A is, and whether it can move to A to B with --force or not.

Re: A pure JavaScript implementation of Git for Node and browsers

#42

Earlier quoted context omitted.

I can't begin to describe how sad I am that we didn't end up using mercurial everywhere.

It's really strange to me that nowadays source control seems to be, largely, a monoculture. Back in the day I either used, or knew plenty of people using any of CVS, Subversion, Sourcesafe, Sourcegear Vault, Perforce, AccuRev, ClearCase, along with a few others. Whilst distributed version control is a huge leap forward over many of those older systems, it's odd that nowadays it seems to be git or, well, nothing. I'm…

A large part, I believe, is the ease of moving a git repository around. Back in the day, the central repository was a choice that stuck you to it for a long time. You literally had to setup the server, in many cases. Git, though? You just install the client and you can get started on a repository in your current directory that can easily transition to a remote hosted one.

So, in a way, it is not unlike pathogen spread. Low barrier to get started combined with basically frictionless ability to spread out. Even the hiccups people used to have only slowed individual level adoption. (Complaints about the UI and such.) The spread of currently successful repositories was not really slowed by those events.

I'd be highly interested in if anyone has something like this modeled.

I'd also appreciate challenges to my point. Mercurial, I believe, should have had similar strength in spreading. It just didn't have the bootstrapped successful project like git. (The kernel, is what I'm thinking of.)

Re: A pure JavaScript implementation of Git for Node and browsers

#43

Earlier quoted context omitted.

I can't begin to describe how sad I am that we didn't end up using mercurial everywhere.

It's really strange to me that nowadays source control seems to be, largely, a monoculture. Back in the day I either used, or knew plenty of people using any of CVS, Subversion, Sourcesafe, Sourcegear Vault, Perforce, AccuRev, ClearCase, along with a few others. Whilst distributed version control is a huge leap forward over many of those older systems, it's odd that nowadays it seems to be git or, well, nothing. I'm…

Sometimes it's just worth getting everybody on board rather than having the perfect tool.

Maybe in 50 years there will only be one package format for applications across the major operating systems. One can dream.

Re: A pure JavaScript implementation of Git for Node and browsers

#44
post #10

I think it's interesting how there's two phenomena that seem to be related to me that get posted here and seem to get treated with different responses. One the one hand, we have software originally written in C/C++ being rewritten in Rust (not often, sometimes just conceptualized), and there's often a real push back by some people about how it's a waste and not useful. On the other, we have software rewritten in Java…

Two questions/thoughts. First is if this is just confirmation bias on your point.

Second is if this is not so much that there is a smaller group that are pushing back, but a larger group that is excited. (That make sense?)

Re: A pure JavaScript implementation of Git for Node and browsers

#45
post #7
post #4

"Any application that can be written in JavaScript, will eventually be written in JavaScript." -- Atwood's Law

we should just implement js in js and go full circle already.

not full circle enough https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: A pure JavaScript implementation of Git for Node and browsers

#46
post #10

I think it's interesting how there's two phenomena that seem to be related to me that get posted here and seem to get treated with different responses. One the one hand, we have software originally written in C/C++ being rewritten in Rust (not often, sometimes just conceptualized), and there's often a real push back by some people about how it's a waste and not useful. On the other, we have software rewritten in Java…

IMO, this is because there's a general attitude about porting to Rust that porting to Rust, by itself, makes a material improvement in the quality of the software (e.g. reliability, performance, readability), and that these improvements that can't be achieved in C/C++. Entrenched C developers then rise to the debate to defend their language. This debate has happened often enough that any time someone ports something…

[deleted]

Re: A pure JavaScript implementation of Git for Node and browsers

#47

Earlier quoted context omitted.

Understand your frustration. But on positive hand, javascript opens new opportunities like using git in the browser (even though meaningful use case is yet to be shown, but there is chance it will be found). On other hand rust implementation brings "just better security" (using sarcasm here for brevity). Yes, it probably could be ported to js (wasm) too, but until somebody does that...

> ... but there is chance it will be found... Doesn't this completely ignore YAGNI?

It's often true that you're not gonna need fun, but that's not really the relevant metric.

That is, not every bit of software is created for business purposes, or with good software engineering principles, or anything else. Sometimes, you do things just because you can. Some might even call this "the hacker spirit".

Re: A pure JavaScript implementation of Git for Node and browsers

#48
post #10

I think it's interesting how there's two phenomena that seem to be related to me that get posted here and seem to get treated with different responses. One the one hand, we have software originally written in C/C++ being rewritten in Rust (not often, sometimes just conceptualized), and there's often a real push back by some people about how it's a waste and not useful. On the other, we have software rewritten in Java…

I enjoy reading libraries like this because git is seemingly ubiquitous. It’s used more than any project I will ever make. And although I know C and C++, it’s source is kinda hard to approach.

Js on the other hand is not for me so I can get a better sense about how it is that git works. I want to see how these fundamental tools are written so I enjoy these ports (even if they’re not perfect).

Re: A pure JavaScript implementation of Git for Node and browsers

#49
With the craziness of Js build tools and build configurations, I love seeing how different project stuff use it. I like how they use both webpack and rollup and even name the rollup export as “for-future”.

I write a lot of isomorphic libraries for work and it’s not as easy as one might think it is.

Re: A pure JavaScript implementation of Git for Node and browsers

#50
post #10

I think it's interesting how there's two phenomena that seem to be related to me that get posted here and seem to get treated with different responses. One the one hand, we have software originally written in C/C++ being rewritten in Rust (not often, sometimes just conceptualized), and there's often a real push back by some people about how it's a waste and not useful. On the other, we have software rewritten in Java…

It's an odd dichotomy. However my biggest take away from it is this; if you are thinking about wanting to implement something on your platform of choice but think "Ehh, it's already done over there so nobody will be interested in it" reconsider! There will almost certainly be people in that ecosystem that will appreciate the effort :)

I for one am happy about some of this. I've used the javascript ssh2 library(with a nice async/await wrapper you can find if you look for it) heavily for automation from nodejs. It could have been implemented on libssh2 for my needs, but a goal was for browser support soo.. Who am I to argue :D Perhaps web assembly will make it possible to compile something like libssh2 and consume from JS, but that's a long ways off I bet(being viable to adopt, not get working).

Post reply on HN