I'm wondering if I can use this in an ERP system I'm developing. A feature request has been to see a diff history of actions on an entity (say, Purchase Orders). Using something like this, I believe I could make a 'commit' on each save, then display a history of commits to the user to 'diff' against to see previous revisions (who added which items, when did the PO number change, etc).
I was planning on storing this history in the database as raw JSON, then diffing the JSON server-side, but this may provide a more robust solution.
That could work, but note that there are other libraries that are purpose-built to do diffing without the rest of git's many features. We are using jsondiffpatch [1] and quite happy with it. It also has builtin formatters to output e.g. html view of the changes.
I am personally using Isomorphic Git exclusively in my automation scripts (written in Node) where it is about infinity times more convenient than shelling out to Git and parsing its output (something which feels dirty to me even in scenarios where it works, like in VS Code's version control pane which does this), however I know a few folks are looking at online IDEs and various things with P2P - like using WebRTC to mesh up clients and using Git in a truly distributed fashion across this WebRTC mesh. The fact that you can supply your own fs implementation makes these kind of applications really easy.
Let say you are building a document editor web app, or any app for creating content. Instead of simple undo/redo you could leverage git powers for versioning + tagging + branching + collaboration on document content. I needed this kind of functionality on one project, but I haven't yet looked into isomorphic-git to see if it is actually a good fit for such purpose.
Pretty much this. I’m building a WYSIWYG note taking app that syncs with GitHub, sort of like Prose.io but more focused on the note taking than CMS part (although the option of publishing notes would combine these two).
I think there’s two benefits of isomorphic git for this use case.
1. It’s more api agnostic: if I wanted to support Gitlab, I wouldn’t have to write substantially more code tailored specifically for Gitlab’s API because it speaks git. You would only have to switch out Github's auth for Gitlab's auth. I also found that add multiple files and versioning them with Github’s API is a pain; they’re remaking a client called Octokit but it’s pretty underdeveloped right now.
2. Offline version control: you shouldn’t have to be online to take notes. With isomorphic git I can add and commit, and then push back to GitHub later when I have Internet. Fun fact: to get git to work on the browser, the author of isomorphic-git wrote a library to port NodeFS commands backed by IndexedDb. This means you can also have offline image drag-and-drop.
There are some minor issues with isomorphic-git when I checked a month ago.
- Largest one is only fast-forward merges are supported; not sure how to get around this one besides cloning the remote Github branch and maybe manually merging files.
- Another one is a bug with git init followed by git add remote and git pull which leads to a reference error because no local commit has been made yet; you can imagine a user who immediately logs in with Github so you want to sync with a pre-existing repo.
Ok - but isn't the hard part of collaborative authoring the conflict resolution not the storing of versions per se. Git has a merge mechanism, but it's not necessarily that user friendly?
Isn't something like OT ( operational transforms ), or CDRT ( Commutative Replicated Data Type ) a better way to do this?
Conflict resolution of course depends on actual content. Source code could be among most tricky ones to auto-resolve or detect when manual merge is necessary. Documentation, art and other not-so-strict content could be more auto-resolvable than source code. Git is here simply a mechanism for allowing different work flows. Your web app should enforce best practices for non-expert users. The added benefit is developer familiarity with git concepts.
I wasn't familiar with OT and CDRT, so maybe I'm off the mark. They seem to try to solve real-time collaboration between multiple users editing same part of same document. This would always require some meta-document or meta-channel where users coordinate what should be changed, in what way and who does what. I would argue that git model is better: user decides when to pull and when to push changes, and the communication between collaborators is outside the scope of the versioning system.
Collaboration is just one application. Even single-user content creation could vastly benefit from built-in versioning. This would eliminate some mental burden and usage friction (tagging), and open up more possibilities to experiment with different directions (branching). The feeling you get when you check-in working version of your code and you are now free to break stuff, that kind of feeling is missing when creating slides, graphics, music, CAD design...
Further - I am using git commits to store hashes for code-created artworks, so that I can reproduce and remix the exported PNG at a later point. See here:
Fork-able web content (e.g. blog posts, class notes) is something I've been looking at, but you would still need to rely on an online service like Github or Gitlab.
I'm having a failure of imagination on the browser side though - anybody got killer use cases running git in the browser?