
A pure JavaScript implementation of Git for Node and browsers - axiomdata316
https://github.com/isomorphic-git/isomorphic-git
======
kbenson
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 Javascript, which people are
generally very accepting of, even if they don't plan to use it.

I understand the goals of these are often different, and the benefits are also
often different, and they have a different set of use cases, but the reception
seems markedly different (at least in tone).

I'm not necessarily trying to imply that means anything, it's just something
that struck me while noting we now have Git implemented in JS.

~~~
dfabulich
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 to
Rust, even if it's just for fun or for the author to learn more Rust, C/C++
advocates see it as an attack on their language, and bite back.

~~~
zeth___
Javascript runs everywhere where there is a browser.

Rust runs everywhere where there is a c compiler, which is funnily enough the
sample places that C/C++ run.

~~~
bluejekyll
And with wasm, Rust/C/C++ all can run in the browser too...

~~~
erikpukinskis
When people say “The Browser” they mean “that thing which is on literally
every computer where you instantly load that one kind of software”.

People think the web is a technology, or that JavaScript is a language.

They’re not. It’s not. The web is an idea: it’s the idea that every computer
in the world already has the runtime on it that can run your next app.
Whatever that is—whatever that runtime is—that’s “The Browser”.

WASM is not that. Maybe in 10 years.

~~~
nulagrithom
What are you babbling about? The web _is_ technology. JavaScript _is_ a
language. And WASM is shipping in all major browsers already.

You don't have to wait 10 years. You can start using WASM today.

~~~
erikpukinskis
It hurts my feelings that you think I’m babbling. I’m trying to be as
articulate as I can.

I don’t want to write software just for people with 2 year old iPhones. I
write software for everyone, especially people who can’t afford anything but
the hardware they’re stuck with. That’s why I’m not going to target WASM.

That’s my point: to me, “The Web” isn’t just modern browsers on newish
devices. It’s the whole world as an audience. I think that’s why so many
people target the web.

I also think WASM is premature optimization in almost all situations.

That said, I totally support anyone who wants to target it. It’s dope
technology. If you love Rust and you want to write browser apps with it, and
limit your audience a little, knock yourself out. I don’t think you’re
embracing what the web is for, but there’s no law that says you have to.

------
CMCDragonkai
This project started when I, wmhilton and another guy started talking on an
issue on the js-git repository. Because development on js-git stopped. We all
started independent projects to port Git to JS. The third guy did one in type
script, wmhilton started this. I began by trying emscripten first with
libgit2. While it compiled and simple things worked, I needed to overload its
filesystem functionality but it was embedded and complex to do. At any case my
git project stalled as I was stuck solving another related problem (indexing
highly dynamic tree data). In the mean time wmhilton continued and produced a
wonderful project. I talked him earlier on about the fs functionality, since
earlier I developed the js-virtualfs to support a git in js. And later he
changed the codebase to support fs plugins. So if you want to use this
isomorphic-git in the browser or electron, I recommend my js-virtualfs library
as its the most comprehensive port of nodes fs api to an in-memory fs. Thanks
to wmhilton I can probably stop my git project and just build on top of his.

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

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

~~~
EMRZ
Just wait for the Electron browser...

~~~
RandallBrown
Mozilla has used their rendering engine to render their UI for YEARS. Not sure
if they're still using XUL with their latest few updates though.

~~~
yoklov
XUL is still alive but XBL is at least going away now. XUL will probably
eventually go away too.

------
ryanackley
I did something similar a few years ago. [https://github.com/ryanackley/git-
html5.js](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 lot of the network protocol validation exists in the git client.
For example, one bug I introduced caused a force push of a shallow copy of the
tip of master intermittently. The server would happily accept it without any
kind of "are you sure?" or -f flag. That spooked me.

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

~~~
bartread
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 surprised Mercurial hasn't made more headway than it has.

But maybe git is just "good enough" for most people? I suppose that's where I
land on it. It has it's frustrations, like anything else, but I can live with
them.

~~~
taeric
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.)

~~~
pseudalopex
Mercurial had major projects too. Mozilla still uses it. What it didn't have
was GitHub.

~~~
taeric
Good counterpoint! Oddly, in my mind, Mozilla is not nearly as new dev
friendly as the kernel is. I suspect that is just a bias in my thinking,
though.

I feel that git was winning a lot of mindshare even before github. I know I
certainly was using it before github. Big plus for me was the git-svn bridge
that existed. Especially since I was working remotely at the time, it was much
faster for me to do checkouts with a git-svn clone than to deal with raw svn
checkouts. It wasn't even close. Did git beat Mercurial to that?

~~~
pseudalopex
Git was popular in some influential circles before GitHub, but it only became
a monoculture several years later. hgsubversion came out in 2008, after git-
svn but before most people were using any DVCS. Also, SVK was around before
git-svn.

You might be underestimating how much support Mercurial had in the late 2000s.
Mozilla, Sun, Google, and Microsoft all picked Mercurial over Git. Even GitHub
published hg-git so people could use the Mercurial client with Git repos. Some
ecosystems gravitated to Git (Linux, Perl, Ruby) and some gravitated to
Mercurial (Windows, Java, Python).

By 2010, DVCS comparisons consistently cited GitHub's UX and network effects
as significant advantages for Git. Atlassian, Google, and Microsoft all added
Git hosting in 2012. By 2015, Python, Google, and Microsoft moved to GitHub
because everyone else was on GitHub.

I think the landscape would look very different if GitHub hadn't come along
when it did or had added Mercurial support instead of Subversion.

------
AntiRush
There's a pretty full functioning project from several years ago (seems
actively maintained) that has similar goals here:

[https://github.com/creationix/js-git](https://github.com/creationix/js-git)

I think it was initially crowdfunded.

~~~
robertkrahn01
Used it, works great. Also really good to understand what git really "is".

------
fithisux
What I really find interesting is the move to an untyped language for large
project while all people talk about the virtues of type systems, Scala Haskell
SML and so on.

It seems Lisp was not mambo jumbo after all.

------
wheaties
First thing I looked at was "did they implement git diff?" The answer is "no."
That's something you're going to want to see in a port. I use it daily.

------
preordained
JavaScript: Because that's what we know.

~~~
ndesaulniers
Possibly; but as someone who maintains a NodeJS native addon in C++, I
frequently _dread_ new releases of NodeJS that invariably break my bindings. A
shim library called "NaN" has done so much to help with this; I would have
given up sooner.

Having libraries implemented purely in the language from which the library is
implemented solves many many headaches, irregardless of JavaScript or not.

~~~
ndesaulniers
> Having libraries implemented purely in the language from which the library
> is implemented

Err, meant to say:

Having libraries implemented purely in the language from which they are used
...

------
ronjouch
Looking at this rewrite I was wondering, but didn't find an answer in the
project README: would emscripten successfully compile Git to js/wasm?

~~~
mr_toad
Git has its claws deep in the file system. On the browser side, JS and wasm
have very limited access to the file system. You’d need to somehow bridge that
gap. (It looks like isomorphic-git is using indexdb, and not the file system).

There’s probably other dependencies (ssh, http, an editor for commits) that
need to be resolved to get expected functionality.

~~~
jvilk
You're right; when it is running in the browser, isomorphic-git does not have
access to the operating system's file system. Instead, it uses BrowserFS [1],
which emulates a file system abstraction on top of arbitrary storage backends.
It supports IndexedDB, localStorage, and Dropbox, among others. (Disclaimer: I
am the author of BrowserFS.)

[1] [https://github.com/jvilk/BrowserFS](https://github.com/jvilk/BrowserFS)

------
harrisreynolds
I spun up a quick dashboard of this project at Chart.ly [1].

A couple interesting points. Will Hilton is the main guy driving the bus on
this project. And... Sunday and Monday are his most productive days.

Keep up the good work!

[1] [https://chart.ly/github-dashboard/isomorphic-
git/isomorphic-...](https://chart.ly/github-dashboard/isomorphic-
git/isomorphic-git)

------
juancampa
I've been using this library for a few months and want to give props to
wmhilton who's been incredibly responsive with the couple of issues I've
encountered.

The thing I like the most is that the API matches very closely to git's CLI,
so if you know git, you know isomorphic-git.

I gave other libraries a try before settling on this one (spent a whole daying
playing around with the optios). IIRC I decided to use isomorphic-git because
the alternatives were either abandoned or simply broken.

------
chuckdries
A few years back, the company I’m currently at started working on NodeGit
because a pure JavaScript implementation they tried (not this one? Idk I
wasn’t there) was far too slow. Right now, we’re working on a git server in
rust that takes commands and passes data over TCP that ideally could enable
git usage in the browser for like hosted development environments and such.

------
overgard
This is pretty cool! I'm curious if emscripten/webassembly on the canonical
git implementation was considered though? (Or is the environment just too
different?)

------
jgalentine007
Code in the project looks really well done. It just needs semicolons ;) I
don't get the whole no semicolon movement, especially when you probably have
to work with C/C++/C#/Java at some point and it means retraining your brain.
Also semicolons help visually distinguish commands from control. 2 spaces I
can definitely get behind!

~~~
always_good
You're dramatizing the mental overhead needed to not write semicolons. Every
serious project uses a linter that can add or remove them based on some flag.

I don't use semicolons. It's an unnecessary character. Life moves on.

I'd say Rust has worst of both worlds, if you want to compare it to something,
where having or not having a semicolon can mean two different things (return
the value or return void). That's an example of actual mental overhead that
semicolons can create that still bites me after more than a year of Rust. And
it's not something that tooling can necessarily fix for you unlike Javascript
ASI.

Using semicolons in Javascript just to keep my brain trained for semicolons in
other languages is probably the worst reason to use them I've heard yet. And
every time someone finds out I don't use semicolons in IRC, they seem angry
about it. So I wonder how much I avoid semicolons just for the sport of it,
now.

~~~
jgalentine007
Yeah, you're probably right on the mental overhead. I guess it is just best to
use a linter and whatever style guide you prefer (most argue for semicolons.)

Using semicolons to stay in rhythm with similar languages that mandate them
might be the worst reason, but it is a reason none the less (I literally spend
equal amounts of time coding in C++/C#/Java/Javascript, so there is no need to
'think' in my case.)

I too like to do things out of spite.

------
martin_drapeau
With something like this, GitHub will soon become my web app’s database
(pending that PR). So awesome...

------
Boulth
I wonder how it works in practice. I've worked with git.js (old and ugly, but
works) and js-git (looks nice but is quite complex).

git.js even has a repository browsing demo (think gitk) that works in a
browser.

Did anyone use isomorphic git? Does it support smart http protocol?

------
indescions_2018
One possible usage is peer net broker for WebRTC. But really I'd like to setup
my own private AWS C9. Secure access to a dedicated instance. From any
computer / browser. With offline caching. And a rich browser terminal ;)

------
wheresvic1
If anything this is a wonderful example of good engineering. Although on the
server-side would it not have been easier to delegate commands to the native
git binary?

Well done!

~~~
ihsw2
Perhaps but there's an existing SDK that is the backbone of many Git
libraries: [https://libgit2.github.com/](https://libgit2.github.com/)

Of which there is an existing Node package that links to it:
[https://github.com/nodegit/nodegit](https://github.com/nodegit/nodegit)

The caveat is that it stopped being a pure-JS library that boasts in-browser
support.

------
the_duke
Soon, there will be a rewrite of the Linux kernel in Javascript.

Finally, a way to run Linux in your browser!

~~~
stdclass
[https://bellard.org/jslinux/vm.html?url=https://bellard.org/...](https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/buildroot-x86.cfg)

~~~
hathawsh
That's a fun place to type "rm -rf /" ;-)

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

~~~
andrewpmartinez
Definitely. This GIT example reminds me of what some people are doing with the
Web Crypto API (see PKIjs). Things I would never have considered a little as a
few years ago.

------
rashthedude
Why oh why?

~~~
Dirlewanger
"Everything that can be written in JavaScript will eventually be written in
JavaScript"

------
abritinthebay
Very clever! I particularly like the bring-your-own-filesystem approach.

------
jlebrech
stop writing stuff in javascript (says someone who writes stuff in js)

------
ingmarheinrich
.. but why?

------
chimmy_chonga
Linus Torvalds would hate this

~~~
hestefisk
Why? It’s a clever hack.

They did it because they can.

~~~
chimmy_chonga
well, this joke didn't go over well ha.

The man went on rants about C++ I can only imagine what he has to say about JS

