I'm currently using https://github.com/rust-lang/git2-rs to interact with git in my software. Are you aiming to have a stable api that could act as a pure-rust replacement for that at some point in the future?
Absolutely! My plan is to proclaim a version 1.0 once the basic workflow of clone-commit-push can be performed, which should be enough for many to start using it. From that point on, the API should remain stable, following semantic versioning as usual.
It is my hope that the quality and stability will be high enough to convince people [in the Rust ecosystem] to move away from libgit2 and instead contribute to the maintenance and development of gitoxide, rewarding everyone with better performance and improved usability.
This sounds great, I added support for signing git commit's in git2-rs and would be happy to try to do something similar in gitoxide if I start to use it.
I might have missed your attention to this thread, but I'll ask and hopefully you'll be able to check later. I have to deal with a monolithic codebase that is of excessive size (10's of millions of lines of code) and has a very large number of developers committing against it.
I haven't looked at the internals of Git much, but performance becomes an issue with it in this context (we currently use a different vcs), and switching seems impractical at the moment. Issues from local performance (30 seconds or so for git status, git checkout, etc) and clone/fetch speeds.
I'm curious, given your experience on porting, have you noticed areas where we might be able to make improvements that might be easier based on Rust's safety improvements? Such as more threading or other areas that could improve Git for use with very large code bases?
(I plan to review the project as this would be an exciting area to work in to help with productivity in this space)
That sounds like such a project should definitely see improvements when using GitOxide. Even in projects of the size of the Linux Kernel checkouts can take time as those only reach about 3000 files per second. You will see only 70% of a single core being busy and a lot of kernel overhead. On my machine, using all the 4 cores, this number can be 7500 when checking out in parallel, something that `gitoxide` is definitely going to do from day one. After all, there is no value in just being as fast as git.
The same applies when checking for changes on disk - right now git does not do that in parallel. These are low hanging fruit that I plan to pick for my own sake.
There is another contributor who is very interested in increasing pack performance, which will directly impact fetch and pull speeds. Judging from my experience with packs thus far, I believe a lot of options are still to be tapped in that field as well. Rust will open it up for contributions and experiments to a greater audience, so I would hope that this will go way beyond of what I can do.
Even though this project is not very contributor friendly right now, I will be working on improving this so more people can join in (see https://github.com/Byron/gitoxide/issues/8).
Unfortunately I can't yet tell, as the corresponding code does not yet exist. Object and pack lookup is competitively fast so I would hope that translates well to everyday operations like that.
Right now, the project is clearly missing contribution guidelines, but now that it's a bit more public these will be added soon, possibly along with some tickets that are ready for pickup. For now I am very focussed on implementation.
That said, I have created a quick issue for you with a small tasks and high value: https://github.com/Byron/gitoxide/issues/7
Thanks a lot for your consideration <3
Great project - more power to you for driving it so far.
My 2 cents. I think rust-analyzer offers a great new dev onboarding experience. issues labelled with has-instructions usually have a a link to the relevant snippet of code in the repo and sometimes even the stub of a failing unit test. While it might be obvious to you, the author, how and where to find the necessary code, it enables a great many people to send patches.
I am not interested in competing with libgit2, and have no plans in adding and maintaining C-bindings to the project. This doesn't mean, however, that other parties couldn't maintain them out-of repo at first, and once things stabilize, it just makes sense to make them part of an organization that maintains it along with the project. After all, C-bindings open it up to be used in interpreters, which might be especially interesting for users of `GitPython`. It has been around for a decade and is definitely in for an alternative (I am the author and maintainer of that one, too).