4 ms·

I know isomorphic-git has been useful to a variety of projects. But may I ask what advantage does being pure JS have over writing a wrapper around the git execu

by O_H_E 6y ago

I know isomorphic-git has been useful to a variety of projects. But may I ask what advantage does being pure JS have over writing a wrapper around the git executable?

yaseer 6y ago
It's probably the most natural way of providing a browser-based git implementation, for systems like github/gitlab and browser-based IDEs. Browser-based coding is pretty popular these days, it seems.
brundolf 6y ago
There may be some small platform-compatibility benefits even as a CLI since it can run anywhere JS can be interpreted But also: why not? It's cool, and it's probably a good learning resource for JS devs who want to learn how git works
freeqaz 6y ago
It seems like the way Git deals with the filesystem is quite tightly coupled, and that component needs to be swapped out in a browser-based environment. When we looked into this, this was my first instinct as well. Seems like others have tried and failed. Isomorphic-git was by far the most polished library!
TheRealPomax 6y ago
no-compile bundling comes to mind. Also, there is no "git executable" available in the browser, which is where this library shines (e.g. online IDEs that sync/share using github or gitlab repos)
dheera 6y ago
Given the wealth of browser-based coding tools available today it's only a matter of time before you can actually be productive as a dev on a Chromebook or arbitrary machine with a web browser and nothing installed locally. Git is an obvious missing gaping hole in that ecosystem.
smarx007 6y ago
Little benefit for Node, deal-breaker for browsers.
exyi 6y ago
Even when not considering browsers - working with git server-side is a pain as it's so coupled to the filesystem. Not only you have to be careful about races, but also you have to know at which state is the repository at the moment. Any time a command fails, the repository is in an unpredictable state (is it a merge or what???), so the code using git has to delete and reclone...
rektide 6y ago
Git executable is good for one off commands. Ideally, an in-language git implementation would also let you model & compute on git in a more enduring fashion. I don't think isomoprhic-get is particularly set up to allow folks to do incremental-computation, but one could imagine having the git tree in memory, & manipulating it there across a series of operations, & then generating a diff or what not, without needing to touch the file system or re-read the tree while multiple operations are happening. This is a bit of a leap of topics, but I think one of the main things missing in JS is a good representation, an abstraction for files. Node has an api for opening files & reading & writing, very normal stuff, but it relies entirely on the platform. There's no abstract concept of a file at a path. Because of this, one can not easily substitute in something powered by S3 or something powered by WebDAV, since there is no abstraction in the language. The once-well-known Node.js build tool Gulp is based very much around one of the libraries out there filling this gap, called vinyl-fs[1]. From the start of it's readme, "Vinyl is a very simple metadata object that describes a file. When you think of a file, two attributes come to mind: path and contents. These are the main attributes on a Vinyl object." By defining a file in an abstract manner, it allows for non-platform implementations, like S3, or WebDAV, or in-memory. It allows talking about files, without having to actually do unto files. It's a bit hard to connect back to the discussion on git and git executable's run-to-completion model, but this idea, of the language having it's own abstractions & being able to do computing inside the runtime without having to keep going back to the platform as the one & only source of truth, allows a lot of flexibility for manipulating the system that is otherwise often cumbersome & involves redundant back & forth work. Getting away from git's normal run-and-execute command model, & comprehending git is the sort of thing that's super useful if you're writing editors, ides, github-like systems, & gitops tools. [1] https://github.com/gulpjs/vinyl-fs https://github.com/gulpjs/vinyl-fs

by O_H_E 6y ago

I know isomorphic-git has been useful to a variety of projects. But may I ask what advantage does being pure JS have over writing a wrapper around the git executable?

yaseer 6y ago

It's probably the most natural way of providing a browser-based git implementation, for systems like github/gitlab and browser-based IDEs. Browser-based coding is pretty popular these days, it seems.

brundolf 6y ago

There may be some small platform-compatibility benefits even as a CLI since it can run anywhere JS can be interpreted But also: why not? It's cool, and it's probably a good learning resource for JS devs who want to learn how git works

freeqaz 6y ago

It seems like the way Git deals with the filesystem is quite tightly coupled, and that component needs to be swapped out in a browser-based environment. When we looked into this, this was my first instinct as well. Seems like others have tried and failed. Isomorphic-git was by far the most polished library!

TheRealPomax 6y ago

no-compile bundling comes to mind. Also, there is no "git executable" available in the browser, which is where this library shines (e.g. online IDEs that sync/share using github or gitlab repos)

dheera 6y ago

Given the wealth of browser-based coding tools available today it's only a matter of time before you can actually be productive as a dev on a Chromebook or arbitrary machine with a web browser and nothing installed locally. Git is an obvious missing gaping hole in that ecosystem.

smarx007 6y ago

Little benefit for Node, deal-breaker for browsers.

exyi 6y ago

Even when not considering browsers - working with git server-side is a pain as it's so coupled to the filesystem. Not only you have to be careful about races, but also you have to know at which state is the repository at the moment. Any time a command fails, the repository is in an unpredictable state (is it a merge or what???), so the code using git has to delete and reclone...

rektide 6y ago

Git executable is good for one off commands. Ideally, an in-language git implementation would also let you model & compute on git in a more enduring fashion. I don't think isomoprhic-get is particularly set up to allow folks to do incremental-computation, but one could imagine having the git tree in memory, & manipulating it there across a series of operations, & then generating a diff or what not, without needing to touch the file system or re-read the tree while multiple operations are happening. This is a bit of a leap of topics, but I think one of the main things missing in JS is a good representation, an abstraction for files. Node has an api for opening files & reading & writing, very normal stuff, but it relies entirely on the platform. There's no abstract concept of a file at a path. Because of this, one can not easily substitute in something powered by S3 or something powered by WebDAV, since there is no abstraction in the language. The once-well-known Node.js build tool Gulp is based very much around one of the libraries out there filling this gap, called vinyl-fs[1]. From the start of it's readme, "Vinyl is a very simple metadata object that describes a file. When you think of a file, two attributes come to mind: path and contents. These are the main attributes on a Vinyl object." By defining a file in an abstract manner, it allows for non-platform implementations, like S3, or WebDAV, or in-memory. It allows talking about files, without having to actually do unto files. It's a bit hard to connect back to the discussion on git and git executable's run-to-completion model, but this idea, of the language having it's own abstractions & being able to do computing inside the runtime without having to keep going back to the platform as the one & only source of truth, allows a lot of flexibility for manipulating the system that is otherwise often cumbersome & involves redundant back & forth work. Getting away from git's normal run-and-execute command model, & comprehending git is the sort of thing that's super useful if you're writing editors, ides, github-like systems, & gitops tools. [1] https://github.com/gulpjs/vinyl-fs https://github.com/gulpjs/vinyl-fs