Often node modules need to depend on git to do developer experience things. Having it be available in node with no dependencies is really nice, you don't need to assume anything about the git in the environment your user is using.
You can include JS in iOS apps. You basically embed Javascript and call it directly from Swift/ ObjectiveC and it runs on the same Javascript engine that runs in Safari.
I don't think you need to. Node is essentially a way to run Javascript from the command line. iOS provides a different way to run javascript. I think you just build the app similar to the way you bundle something for the web.
We just had a kerfuffle about fixing this in real git, but it looks like this repo still uses "master". Can we all just stop hating POC pls? A one-word change to avoid evoking centuries of bigotry is not that hard, so cope.
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?
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!
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)
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.
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...
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.
We actually use this library to provide the ability to "one-click" share projects in Refinery. It works really well (except in Incognito)!
If you go to this[0] link, you'll see a bunch of nodes in a graph. Each one represents an AWS Lambda that will be deployed (and an API endpoint). The edges between are "microservice" calls between Lambdas that get configured with the deploy too.
That's all coming from a Git repo here[1].
And if you edit the project by adding more blocks, it will actually push a commit to Git (if you're signed up and auth'd GitHub). Each block is just a folder, and the "project" is a YAML file. We have a bi-directional "compiler" that lifts/drops the project in either direction.
This library made it super easy to ship this. We tried using the server first and it was a huge pain. We just had to setup a GitHub proxy to make this work. It's stateless now (your browser does the work) :)
Yeah, exactly. The proxy is a part of Isomorphic-git. You're basically just using git via HTTPS. The proxy just injects the GitHub oauth token into the request (and handles the CORS problem of GitHub).
40 comments
[ 0.28 ms ] story [ 93.8 ms ] thread0: https://news.ycombinator.com/item?id=25152185
[1] https://twitter.com/GitShark/status/1273043228355252224
you need to chill, if you don't like something, don't use it. Easy
What does wanting to script git have to do with web?
/s
Try POSIX sh and awk first; don't use bashisms or gawk features unless you need to.
Browser-based coding is pretty popular these days, it seems.
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
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
Browser-based coding environments are becoming huge (an observation, not a suggestion of what should be).
This is a natural fit for those environments.
If you go to this[0] link, you'll see a bunch of nodes in a graph. Each one represents an AWS Lambda that will be deployed (and an API endpoint). The edges between are "microservice" calls between Lambdas that get configured with the deploy too.
That's all coming from a Git repo here[1].
And if you edit the project by adding more blocks, it will actually push a commit to Git (if you're signed up and auth'd GitHub). Each block is just a folder, and the "project" is a YAML file. We have a bi-directional "compiler" that lifts/drops the project in either direction.
This library made it super easy to ship this. We tried using the server first and it was a huge pain. We just had to setup a GitHub proxy to make this work. It's stateless now (your browser does the work) :)
0: https://app.refinery.io/import?q=pq4rsai019bm
1: https://github.com/freeqaz/gensim-refinery
Also 2018: https://news.ycombinator.com/item?id=17083807