Some commands are not available

[shd101wyy]

Some commands such as revparse, branch are not available. Will they get supported in the future? Thanks!

For example:

> lg.callMain(["branch"])
Command not found: branch
undefined

[petersalomonsen]

All the commands come from the libgit2 examples: https://github.com/libgit2/libgit2/tree/main/examples

and you can see how they are mapped here: https://github.com/libgit2/libgit2/blob/main/examples/lg2.c#L12

So whenever there are new examples in libgit2, these will also be included in the next wasm-git version.

[alexciesielski]

What exactly stands in the way of supporting more of git's commands in wasm-git?
Why does it only support the ones from libgit's examples section?
(not meant to be an attack, just curious)

[petersalomonsen]

Nothing is in the way for creating whatever git functionality you want. In my first hack to compile libgit2 to wasm I implemented my own git commands ( see https://github.com/fintechneo/libgit2/blob/master/emscripten_hacks/jslib.c ).

But when doing this again "properly" in wasm-git, I fixed the actual bugs in emscripten instead of the workarounds I did in my first hack. Also I wanted to be more aligned with libgit2, and instead of implementing every git command myself, rather benefit from all the commands already implemented in the libgit2 examples. I also contributed to a few of them too. So by using the examples I can easily take advantage of everything added in libgit2, without very much effort.

The only downside of using the examples is that results goes to stdout, while if doing as I did in my first hack, results was returned from the functions (API). However writing your own API needs more planning, documentation must be maintained etc, while the examples are already documented and the output is very much alike the standard well known git commands. It's also easy to capture stdout on the javascript side and wrap a more dev-friendly API there. And libgit2 is well maintained so that means wasm-git can also keep up to that same standard with very little effort. If introducing an API specific to wasm-git then that needs much more maintenance than the capacity of a one-man hobby project :)

But of course, for your own forks, adding extra functionality to wasm-git is quite easy if you know C and get up to speed on the libgit2 library (which is really well documented). The purpose for wasm-git is to be as little extra to libgit2 as possible, it's just to add the wasm capability for running in the browser and nodejs, and then it's up to anyone who use it to extract whatever libgit2 capacity needed.

[ethomson]

I wholeheartedly support @petersalomonsen's position. libgit2's language bindings should be layers on top of libgit2 - their purpose should be to provide a reasonable, idiomatic language representation of libgit2. Functionality should be in libgit2 itself. That way every language binding can take advantage of that functionality.

Otherwise, the libgit2 community (such as it is) gets sharded and some language bindings have more, different, and incompatible functionality. LibGit2Sharp, for example, implements some of its own "commands". These are poorly maintained, inefficient and incompatible with git. 😢

We're investing in libgit2's core functionality - with things like commit graph and midx support - as well as higher-level interfaces. We're adding a proper command-line interface, albeit slowly. Almost all of the core refactoring to support this is complete and I expect to see the first pieces of the CLI landing in main before the end of the calendar year.

Contributions are always welcome. 😁

[alexciesielski]

Thanks for these in-depth answers.
Yes, I'm just starting to wrap my head around what these libraries try to solve.
I actually expected a full-fledged git client when looking at wasm-git for the first time last week.

Edward, if you don't mind me asking: that PR seems rather old and inactive, why do you think this will land by EOY?

I'll be honest, that looks exactly like what I need for my project, currently I'm just trying to make things work with whatever commands are currently supported in wasm-git (which is not that bad, git pull was easily implemented by doing a fetch+merge, and git reset just undoes deletes and modifications by comparing the working directory with what's in git). But yeah, I would prefer using something a little bit more battle tested.

I would love to contribute but unfortunately C is a little like black magic to me.

[ethomson]

Edward, if you don't mind me asking: that PR seems rather old and inactive, why do you think this will land by EOY?

That's a good question. 😁 That PR was a "spike" - if you will - or a proof of concept. That got to a place where I had fleshed out the ideas in my head and the strategy to get there. Much of the groundwork on that PR is refactoring and reorganizing the libgit2 code base to be able to deal with another project. The "pure" utility classes are getting split out into a separate project so that they can be shared between the library and a new CLI project. For example: we have a set of generic hashing functions (git_hash_*) that should be able to be used by any C project anywhere. Instead, they used to write into a git_oid struct that is very much a libgit2 object.

The code in libgit2/libgit2#5507 was a first - but sadly naive - attempt at making a clear delineation between libgit2 and generic utility classes. Doing it "right" has been a months long refactoring that touched a surprisingly large number of areas like libgit2/libgit2#6017, libgit2/libgit2#6016, libgit2/libgit2#6082, etc.

I didn't keep libgit2/libgit2#5507 up-to-date or rebased as I've gone. There would just be too many conflicts and too little to gain from resolving them. But to use it as an indication, the last real piece of refactoring - I think - is actually making that split of the utility functions into their own project with no dependencies back on libgit2. (IOW, libgit2 depends on util, but util doesn't depend on libgit2.)

I think that the last piece here is that the git_path functions know about repositories (in order to do .git validation). I'll break that out this weekend and then I think that we'll be roughly at libgit2/libgit2@2d615d6 in that giant PR.

After that I think that it's all additive and it's mostly net new code and not reorganizing and refactoring what's there. I think that at that point it should go relatively quickly. 🤞

[alexciesielski]

Thanks for that insightful write-up, sounds very promising. I will definitely be keeping an eye out for new releases.
Best of luck!

[petersalomonsen]

The CLI is great news @ethomson . Wasm-git will for sure benefit from this, being able to expose new functionality out of the box by just building with a new version of libgit2.

[yxshv]

when will pull command would be supported?

[petersalomonsen]

Pull is just a fetch and merge which you can see an example of here: https://github.com/petersalomonsen/githttpserver/blob/master/public/libgit2_webworker.js#L96

[yxshv]

Pull is just a fetch and merge which you can see an example of here: https://github.com/petersalomonsen/githttpserver/blob/master/public/libgit2_webworker.js#L96

I see... thanks!