It wouldn't really be a git wrapper then though, would it? 😉

No.... hmm..... "Ungit: worlds best git client"

@gravypod yup would be awesome to get rid of that dependency, but I afaik there's no good replacement right now. Some of the stuff I've been looking at:

• https://github.com/creationix/js-git looks very promising, but I don't think it supports "commits" yet (I mean with creating patches and everything, not sure that's even in the scope of his project) and it's very very new
• https://github.com/libgit2/node-gitteh doesn't support writing (and seems like they're changing maintainer right now)
• https://github.com/nodegit/nodegit also looks promising but seems like it requires python :/
• https://github.com/danlucraft/git.js last updated two years ago and seems to only support reading

And there's also a bunch of other libraries with either limited functionality or limited activity :(

You are not seriously considering this, are you? oO

@Profpatsch well I'm not considering writing my own git implementation no, but if any js implementation of git becomes stable enough I might switch to that yes.

@FredrikNoren Have you seen this library? https://github.com/creationix/js-git

@gravypod yup but last time I looked it was missing some functionality for me to be able to use it straight off (don't think it supported creating patches/commits from a "dirty" working directory). But it looks promising otherwise.

@FredrikNoren If you want some help cleaning it up I could help pitch in. We should get in touch via Email or IRC, which ever is better for you.

How can you be sure this won’t screw up my repository?
Until now ungit uses the git client, an incredibly battle-tested client closely looked after by hundreds of people and used by millions. I am sure this won’t kill my repository if ungit doesn’t run a completely stupid command.

But this git-js is nothing of the above, not even very usable. So who (or what) guarantees that this won’t seriously damage valuable git repositories?

@Profpatsch Lots of testing, testing, and more testing before merging it into the master

@gravypod Thanks but I don't think I'll be trying this any time soon, as @Profpatsch pointed out it might be a bit early for that. Though by all means help creationix with his project, would be awesome if it became stable (and feature complete) enough for me to use it in ungit

https://github.com/creationix/js-git seems to be coming alng well.

I wudl like the option to use this library.

the reason si that we have many people that are non technical and they are using ungit to be able to edit content and a bit of js and they need to push to the git branch, and then the github hooks to an auto deploy.

so it would be useful to use because having their machines (windows) setup to run node-gyp is a nightmare to maintain

this is why it would be great to have a config setting with ungit to allow the user to target the normal git binary Or the git.-js version.

I guess that’s why we can’t have nice things.

funnily enough i just found an extension for brackets that doe the job well.
The editors use brackets and it has a git extension.

https://github.com/zaggino/brackets-git

so far works very well for basic work flows.

I just found this, thought it might be fun to drop it off: http://gitlet.maryrosecook.com/

I wrote Gitlet to explain how Git works. I didn't write it to be used. It would be unwise to use Gitlet to version control your projects. But it does work. Sort of.

So yeah. Not really something we could actually use, but still interesting.

@gedw99

From the Readme:

To make Brackets-Git work you'll need Git installed in your system:

So, not a JavaScript implementation of git. Just another wrapper, just like ungit is.

Gitteh sounds like the obvious choice. @aspiers has a similar project over at aspiers/git-deps which uses libgit2 via the python bindings. As long as you want to work directly on disk-based Git repositories, I don't think js-git is the right thing.

Gitteh looks interesting, but doesn't provide all the features necessary for ungit yet. From their README:

Right now, the bindings cover read only access to raw objects (trees/commits/blobs/tags/references), and basic access to remotes (including basic cloning/fetching support).

@Ajedi32 Sorry, I simply assumed that Gitteh was a thorough implementation as it is referenced from the libgit2 homepage (update: libgit2 now references nodegit). It seems NodeGit has more activity and features. @FredrikNoren commented earlier that it requires Python, but that's only at build-time, according to their README.

@tfnico Yeah I think you're right (about nodegit). It also looks like they are making some fairly good progress.

@tbranyen @johnhaley81 @maxkorp (maintainers of nodegit): do you guys have any input on the feasibility of using nodegit for ungit? To give you some background (if you are unfamiliar with ungit): ungit is a UI, built on top of the git cli, which means that you have to install git to be able to use ungit, which is why we are interested in projects such as yours so that users can use ungit without having to install git first. (Lots of "git" in that sentence but I hope you get the idea :) )

Nodegit is getting better everyday. I'm not going to come out and say that we're stable and ready for prime time right now but we're getting close. We're striving for 1:1 mappings to libgit2. Next release for us is going to be 0.3.0 which will have us using the latest on libgit2 (0.22.x). So what you'd really to ask yourselves is "Does libgit2 provide everything we need". And if it does then we will fit the bill soon.

In the meantime there are always pull requests :)

Adding to what @johnhaley81 said regarding pull requests, you have to decide what your comfort level is adding features. There are a few tiers of complexity there.

Short version:
Existing libgit 2 features can be quick and easy to add (just flip a bool and add tests), or complicated (modify templating engine which outputs C++ that uses the v8 apis). Adding things to libgit2 is inherently a bit tough (or just slow) usually (I mean it's C), and libgit2 is incomplete), then they still have to be added to nodegit. Libgit is also low level and basic operations usually take several steps, but we do have a good method of adding helper functions in js to shortcut stuff or add some types of missing functionality.

Long version is at the bottom.
Nodegit is certainly an option for you, but as it currently stands you'll still probably require git to be installed for a fully featured client, unless you intend to hop on with libgit2 and nodegit dev a bit. I haven't dug in to all of what ungit exposes, so depending on it's feature set we may already have what you need. I'd invite you to hop into our gitter room to talk, and we can see what you need vs what you have, and help evaluate what it would take to fill in the gaps.

Heres the long version of adding features:

This was all way longer than I intended to write, and sounds much worse than I want it to (or than it is), just because explaining the hard parts of when things arent missing takes a lot more talk than explaining how easy fixes work lol.

If it doesn't exist in libgit2, and is an appropriate addition (more on that in a bit), you'll have to do work in there. I know some people love C, and I don't hate it, but I don't know many that consider it easy to or quick to work with.

If libgit2 does have a feature (fresh addition or not), there are two ways adding it to nodegit can go.

1. If we have similar methods (in that they behave similarly in regards to design pattern) then it's usually pretty simple to add, by flipping some config bits and writing a few tests.
2. Things that don't have similar implementations in nodegit require some more complicated work with the C++ V8 apis and native node workings to be added to our templating. Certainly doable, and we're always glad to help, but timeframe for those if we're going to do it is usually much larger. Unfortunately the learning curve for how the system is built is a bit steep as well, but we're always willing to help ramp people up. We've got a few new contributors lately, and we'd love more :)

If the feature isn't really appropriate for libgit2 (eg it's high level), we have convenience methods added in javascript. libgit2 is a very low level library; You don't tell it to pull a repo, you tell it to get the repo, open it, grab the head reference, get its OID, use that to get the branch name, grab the repos remote, tell it to download (fetch basically), grab the remote branch's OID, set the local branch to that OID, and then set the head ref back to that. We add a lot of convenience methods here, but many are missing, and once you understand how it works these are easier to add. There's also an opportunity to add things that libgit could/would/should support here temporarily using some workarounds, and that's ok, as long as an attempt is made to make the api similar to what one would expect.

@johnhaley81 @maxkorp Thanks for really good and detailed answers! Yeah Ungit is very high level, it's essentially just a UI on top of the CLI, and actually one of the things we've tried to aim for is to make it as close as possible to the CLI so that even if you first learn git using Ungit you may be able to move to the CLI later and at least have a rough idea what things do. (There are obviously quite a few discrepancies but overall I hope Ungit helps people understand how git works). So with that in mind it does sound like it would be quite a bit of work to switch to nodegit/libgit2, and especially guarantee that you can move seamlessly from the CLI to Ungit (which is very important to be able to do for those few times when you have to use the CLI to fix things).

Anyway I think it would be great to stay in touch, for instance if you guys (or someone building on what you guys are building) were to supply higher level API:s that closer match the CLI we would be really interested in hearing about that.

We are definitely planning a higher level library of nodegit once we get it stable. That project would be more trying to mimic what the CLI is doing and have a very similar interface. We don't have a timeframe on that at this point however. :(

EDIT
Stay in touch though! You can always come hang out on our gitter channel and see what we're up to.

Cool that's good to know! Thanks!

I’m very sceptical about replacing git in a git client.

Compare:

https://www.openhub.net/p/git
40.000 Commits from 1.3k Contributors since 2005, ~100 years of effort, decreasing number of yearly commits (meaning it’s nearing completion and bug-freeness), written in C (no memory-safety, but basic type-safety and very mature toolchain).

https://www.openhub.net/p/nodegit
1.500 Commits from ~50 Contributors (with a lot of foreign code pulled in, so no way to tell what is new code), written in nodejs (memory-safety but no type-safety at all with a very young toolchain).

@Profpatsch Well, nodegit is just a bunch of bindings to lib2git, which is written in C, and pretty mature. https://www.openhub.net/p/libgit2

And honestly, nodegit itself is extremely mature compared to Ungit, so I'm not really sure what the problem is.

@Profpatsch 2 points:

• Github uses rugged for much of it's functionality, which is a similar binding for ruby. I know Github != git, but I suspect that if they use it to provide a good chunk of an extremely popular git service, it's at least ok.
• It seems a bit odd to me to count points against nodegit for being written in JS and therefor is lacking typesafety, when ungit itself is written in JS as well.

I'd also point out that 90% of nodegit's code (that isnt libgit2 code) is actually C++, not JS.

@Ajedi32 @maxkorp My bad, I thought it is a re-implementation of git where actually it’s about using real bindings instead of command line calls.

In that case I’m all for it of course. I get lots and lots of command line errors in ungit when I do something unexpected.

Ah no, thats libgit2, not us, but that has a massive support network, and their entire function is parity with git proper, although like I said, it's not there yet. They do a great job of keeping the features they do have at full compat though. We just wrap it, and make it accessible to JS ;)

https://github.com/nodegit/nodegit +1

See GitKraken, it's made out of electron + nodegit which only needs libgit2 has a dependency and has become more robust and complete since the last year.
The advantage of libgit2 is that we can avoid installing both Git and any SSH clients/tools such as PuTTY, Pageant and PLink on Windows and it's license is GPL + linking exception for any other licenses.

So I 👍 for https://github.com/nodegit/nodegit too.

I'm glad that this might happen and that there is now a mostly feature compliant replacement for git.

As a git lover, I'm hesitant to do this, but at the same time I understand the use cases for this.

I really wish we could do polling here but will it be better if ungit does some hybrid approach where if git exists, use git, otherwise use whatever git replacement. Would that be a better solution or are we asking for complete independence from git overall?

What would be the the point of continuing shell out to git when available if we had an interface to libgit2 working? Is there any particular benefit to using the git CLI over nodegit?

Every time crucial dependency of a project is replaced, it was never fun... so I guess I'm just very hesitant...

But I admit that scale of ungit is not as big as some of the projects I have worked on so my concern is largely unfounded....

This sounds paradoxical, removing bare bone git dependancy from ungit. I guess nowadays git outgrow tool realm and became more like protocol. Honestly I don't imagine using dev machine without one or the other.
Besides, this is just changing dependancy, not removing it completely. So maybe the real problem is git installation, maybe this project should help with that? Like packaging git into one of npm module then for user git installation would be seamless?

I have started to play with nodegit (https://github.com/ylecuyer/ungit/tree/nodegit) if someone wants to help it would be nice :)

I'd like to update this issue: node-gitteh (by the libgit2 team) is no longer being developed, and nodegit is now using libgit2.

https://github.com/git-up/GitUp (macOS only) is using libgit2 to great effect: it is way faster than calling git, and it does some very neat rebase actions like moving a commit, splitting a commit etc, while marking previous refs as undo points, making everything undoable.

Ungit is the only client I could find that is close to the overview GitUp provides, and since I'm no longer on macOS I'm really happy I found it 👍. Moving away from calling git directly can make Ungit faster and better.

At the time I tested to use nodegit directly, it wasn't mature enough to handle all the use cases required by ungit. I also tried to make another git-api backend using rugged instead but it is a lot of work and some advanced actions like merge, rebase, ... are not easy to replicate

@ylecuyer I rebased your branch: https://github.com/wmertens/ungit/tree/nodegit