19 ms·

A pure JavaScript implementation of Git for Node and browsers

381 points by axiomdata316 8y ago

abritinthebay 8y ago
Very clever! I particularly like the bring-your-own-filesystem approach.
deleted 8y ago
[deleted]
wintorez 8y ago
"Any application that can be written in JavaScript, will eventually be written in JavaScript." -- Atwood's Law
- fb03 8y ago
  we should just implement js in js and go full circle already.
  - bpicolo 8y ago
    There's a bunch: https://github.com/jterrace/js.js/ https://github.com/jterrace/js.js/
  - roywiggins 8y ago
    already done: https://github.com/NeilFraser/JS-Interpreter https://github.com/NeilFraser/JS-Interpreter
  - EMRZ 8y ago
    Just wait for the Electron browser...
    - bartread 8y ago
      Given the somewhat non-awesome performance and resource requirements of some of the Electron apps out there, waiting might end up as the defining experience of an Electron browser.
    - Izkata 8y ago
      What, like this? https://blog.jscrambler.com/building-a-web-browser-using-electron/ https://blog.jscrambler.com/building-a-web-browser-using-ele...
    - moogly 8y ago
      Brave is built on Electron, IIRC.
    - RandallBrown 8y ago
      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 8y ago
        XUL is still alive but XBL is at least going away now. XUL will probably eventually go away too.
  - tlrobinson 8y ago
    Done, by Brendan Eich, in 2004: https://github.com/mozilla/narcissus/ https://github.com/mozilla/narcissus/
  - madeofpalk 8y ago
    not full circle enough https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
    - securityfreak 8y ago
      Best tech talk ever!
  - samatman 8y ago
    I have done this. In continuation passing style. AMA.
- mkirklions 8y ago
  5 years ago I'd be like: Noooooo Today: My body is ready
Boulth 8y ago
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?
ryanackley 8y ago
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 8y ago
  I can't begin to describe how sad I am that we didn't end up using mercurial everywhere.
  - bartread 8y ago
    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 8y ago
      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.)
kbenson 8y ago
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 8y ago
  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.
  - deleted 8y ago
    [deleted]
  - test6554 8y ago
    ...hey everyone, I made a C/C++ developer blood pressure checker in Rust.
    - diegoperini 8y ago
      Your entire program should be wrapped by unsafe{}.
  - jordigh 8y ago
wheresvic1 8y ago
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 8y ago
  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.
chimmy_chonga 8y ago
Linus Torvalds would hate this
- hestefisk 8y ago
  Why? It’s a clever hack. They did it because they can.
  - chimmy_chonga 8y ago
    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
rashthedude 8y ago
Why oh why?
- Dirlewanger 8y ago
  "Everything that can be written in JavaScript will eventually be written in JavaScript"
- lcfcjs 8y ago
  Why not? Don't be rash, and actually read the link.
AntiRush 8y ago
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 8y ago
  Used it, works great. Also really good to understand what git really "is".
indescions_2018 8y ago
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 ;)
the_duke 8y ago
Soon, there will be a rewrite of the Linux kernel in Javascript. Finally, a way to run Linux in your browser!
- stdclass 8y ago
  https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/buildroot-x86.cfg https://bellard.org/jslinux/vm.html?url=https://bellard.org/...
  - hathawsh 8y ago
    That's a fun place to type "rm -rf /" ;-)
pducks32 8y ago
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 8y ago
  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.
ronjouch 8y ago
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?
- viraptor 8y ago
  There's still a bit of bash hiding in the git commands if I remember correctly. That wouldn't be trivial to compile.
  - iguessthislldo 8y ago
    I was going to write: "Simple, we just make a bash compiler", but I realized this might have already been done and to my horror a quick google search confirmed this, or more technically a sh to C transpiler: http://www.linux-magazine.com/Online/Features/SHC-Shell-Compiler http://www.linux-magazine.com/Online/Features/SHC-Shell-Comp...
- mr_toad 8y ago
  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 8y ago
    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
wheaties 8y ago
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.
chuckdries 8y ago
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.
martin_drapeau 8y ago
With something like this, GitHub will soon become my web app’s database (pending that PR). So awesome...
overgard 8y ago
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?)
CMCDragonkai 8y ago
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.
preordained 8y ago
JavaScript: Because that's what we know.
- ndesaulniers 8y ago
  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.
  - tuananh 8y ago
    NAPI has ease that pain.
  - ndesaulniers 8y ago
    > 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 ...
jgalentine007 8y ago
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 8y ago
  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 8y ago
    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.
jlebrech 8y ago
stop writing stuff in javascript (says someone who writes stuff in js)
fithisux 8y ago
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.
ingmarheinrich 8y ago
.. but why?
edem 8y ago
Just one question: why do we need this? Apart from the intellectual masturbation, this does not make sense whatsoever. Not to mention that writing a Git in a language such as Javascript is just asking for trouble in the long run.
harrisreynolds 8y ago
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-git https://chart.ly/github-dashboard/isomorphic-git/isomorphic-...
juancampa 8y ago
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.

381 points by axiomdata316 8y ago

abritinthebay 8y ago

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

deleted 8y ago

[deleted]

wintorez 8y ago

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

fb03 8y ago
we should just implement js in js and go full circle already.
- bpicolo 8y ago
  There's a bunch: https://github.com/jterrace/js.js/ https://github.com/jterrace/js.js/
- roywiggins 8y ago
  already done: https://github.com/NeilFraser/JS-Interpreter https://github.com/NeilFraser/JS-Interpreter
- EMRZ 8y ago
  Just wait for the Electron browser...
  - bartread 8y ago
    Given the somewhat non-awesome performance and resource requirements of some of the Electron apps out there, waiting might end up as the defining experience of an Electron browser.
  - Izkata 8y ago
    What, like this? https://blog.jscrambler.com/building-a-web-browser-using-electron/ https://blog.jscrambler.com/building-a-web-browser-using-ele...
  - moogly 8y ago
    Brave is built on Electron, IIRC.
  - RandallBrown 8y ago
    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 8y ago
      XUL is still alive but XBL is at least going away now. XUL will probably eventually go away too.
- tlrobinson 8y ago
  Done, by Brendan Eich, in 2004: https://github.com/mozilla/narcissus/ https://github.com/mozilla/narcissus/
- madeofpalk 8y ago
  not full circle enough https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - securityfreak 8y ago
    Best tech talk ever!
- samatman 8y ago
  I have done this. In continuation passing style. AMA.
mkirklions 8y ago
5 years ago I'd be like: Noooooo Today: My body is ready

Boulth 8y ago

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?

ryanackley 8y ago

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 8y ago
I can't begin to describe how sad I am that we didn't end up using mercurial everywhere.
- bartread 8y ago
  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 8y ago
    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.)

kbenson 8y ago

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 8y ago
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.
- deleted 8y ago
  [deleted]
- test6554 8y ago
  ...hey everyone, I made a C/C++ developer blood pressure checker in Rust.
  - diegoperini 8y ago
    Your entire program should be wrapped by unsafe{}.
- jordigh 8y ago

wheresvic1 8y ago

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 8y ago
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.

chimmy_chonga 8y ago

Linus Torvalds would hate this

hestefisk 8y ago
Why? It’s a clever hack. They did it because they can.
- chimmy_chonga 8y ago
  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

rashthedude 8y ago

Why oh why?

Dirlewanger 8y ago
"Everything that can be written in JavaScript will eventually be written in JavaScript"
lcfcjs 8y ago
Why not? Don't be rash, and actually read the link.

AntiRush 8y ago

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 8y ago
Used it, works great. Also really good to understand what git really "is".

indescions_2018 8y ago

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

the_duke 8y ago

Soon, there will be a rewrite of the Linux kernel in Javascript. Finally, a way to run Linux in your browser!

stdclass 8y ago
https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/buildroot-x86.cfg https://bellard.org/jslinux/vm.html?url=https://bellard.org/...
- hathawsh 8y ago
  That's a fun place to type "rm -rf /" ;-)

pducks32 8y ago

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 8y ago
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.

ronjouch 8y ago

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?

viraptor 8y ago
There's still a bit of bash hiding in the git commands if I remember correctly. That wouldn't be trivial to compile.
- iguessthislldo 8y ago
  I was going to write: "Simple, we just make a bash compiler", but I realized this might have already been done and to my horror a quick google search confirmed this, or more technically a sh to C transpiler: http://www.linux-magazine.com/Online/Features/SHC-Shell-Compiler http://www.linux-magazine.com/Online/Features/SHC-Shell-Comp...
mr_toad 8y ago
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 8y ago
  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

wheaties 8y ago

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.

chuckdries 8y ago

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.

martin_drapeau 8y ago

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

overgard 8y ago

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

CMCDragonkai 8y ago

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.

preordained 8y ago

JavaScript: Because that's what we know.

ndesaulniers 8y ago
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.
- tuananh 8y ago
  NAPI has ease that pain.
- ndesaulniers 8y ago
  > 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 ...

jgalentine007 8y ago

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 8y ago
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 8y ago
  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.

jlebrech 8y ago

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

fithisux 8y ago

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.

ingmarheinrich 8y ago

.. but why?

edem 8y ago

Just one question: why do we need this? Apart from the intellectual masturbation, this does not make sense whatsoever. Not to mention that writing a Git in a language such as Javascript is just asking for trouble in the long run.

harrisreynolds 8y ago

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-git https://chart.ly/github-dashboard/isomorphic-git/isomorphic-...

juancampa 8y ago

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.