As mentioned, we also work on the Gitoxide project and Byron is a member of our team. We are well aware of all large community efforts and we're also cohosting the Git Merge conference this year.
There is a recent effort to vibe-loop more Git into Gitoxide, which is interesting:
I still think that this is a project that can have value with a little more work. This announcement is merely a milestone, not the end product. I wasn't sure it was really possible to do, even halfway through the project. There has been a lot learned and there is a lot to learn, but I think there are useful applications for both a high quality, hand crafted, opinionated partial Git library (Gix) as well as a vibed, fully implemented, partially sloppy LLM Git library (Grit). We think it's worth exploring and investing in both options for now.
Also, I am the exec involved and I've done quite a lot for the Git community over the years. I would never try to have my "own copy" of it, that's ridiculous. I wrote and open sourced the Pro Git book (https://git-scm.com/book/en/v2) and Git community book before it (https://schacon.github.io/gitbook/index.html), I created the official Git website (https://git-scm.com), I cofounded GitHub which hosts nearly all open source in the world, I have evangelized and supported the Git ecosystem for almost 20 years now. I restarted and funded development of libgit2 15 years ago, which you could similarly argue was an exec trying to have our "own copy" of Git under a more permissive license and would have been a similarly ridiculous argument.
> Also, I am the exec involved and I've done quite a lot for the Git community over the years. I would never try to have my "own copy" of it, that's ridiculous. I wrote and open sourced the Pro Git book (https://git-scm.com/book/en/v2) and Git community book before it (https://schacon.github.io/gitbook/index.html), I created the official Git website (https://git-scm.com), I cofounded GitHub which hosts nearly all open source in the world, I have evangelized and supported the Git ecosystem for almost 20 years now. I restarted and funded development of libgit2 15 years ago, which you could similarly argue was an exec trying to have our "own copy" of Git under a more permissive license and would have been a similarly ridiculous argument.
This "I am Scott Chacon" part doesn't matter. 95% of people here already know.
I think Byron (Gix author/maintainer) is one of the most excited people about the Grit project.
Gitoxide is great and we will continue to push it forward. Grit is an orthogonal project. Perhaps we can use one in the other or maybe Grit goes nowhere. But we thought that a small investment in a different approach is worth the effort.
I see it differently. I look at it as if I had written this code myself, using this same approach. Look at the docs, look at the tests, look at the source, implement something that is interactively compatible but a very different approach.
For example, this is exactly what I did when I tried to get SSH commit signing working properly in GitButler:
You can see in the post that I dug through the C source to figure out how it was canonically done and then implemented something that accomplished the same thing in Rust but without copying source code.
There are some similarities between the Grit Rust source and the Git source, but it's mostly around time/formatting type things or byte offset type things needed to make packfile parsing and whatnot work, but as far as I can tell, there is no straightforward copying of code. The approach needed to make this a reentrant, memory safe, library driven codebase is so different that copying is generally not useful. But nobody can _guess_ how packfiles or reftable binary formats are specified, since they're not really documented. I'm aware of this because I'm pretty sure I _personally_ am one of the only ones who has ever attempted to document the packfile binary format: https://schacon.github.io/gitbook/7_the_packfile.html
You have to read the source. Which means that libgit2 and Gitoxide and every other Git reimplementation is also "license-washing" per this definition because they also had to reference the Git source to see what the technical specification is.
If you find any code in Grit that is clearly line-for-line copied, please point it out and I will replace it. But the Git source is the Git specification and every reimplementation, LLM or not, is forced to use this approach to build anything compatible.
On Gitoxide: Given that the author read the docs and source code [0], and literally copied files over from the git source [1], it also is license-washing. At least libgit2 is GPLv2 with a linking exception. I don't think people would have much to say if these projects honored the original projects' intents and kept a copyleft GPL license. But they don't.
> The approach needed to make this a reentrant, memory safe, library driven codebase is so different that copying is generally not useful.
This is obvious given how different Rust is from most languages. So are licenses pointless as a concept now, because anyone can argue their Rust implementation of a GPL (or whatever) project is meaningfully different? Nice loophole there.
Stripping away the GPL in favor of MIT/ASL2.0 seems to be the trend for rust projects (see uutils, etc). I'm really glad that we can make it easier for large companies to extract value from community labor and, in general, not contribute much of anything back.
> You have to read the source. Which means that libgit2 and Gitoxide and every other Git reimplementation is also "license-washing" per this definition because they also had to reference the Git source to see what the technical specification is.
This makes no sense:
1. A court might agree with you if a human read the sources, then wrote a new implementation. Doesn't apply to trade secrets (i.e. cleanroom implementations), but certainly for copyright.
2. A court is not going to agree that passing the original sources through a machine means you own the results!
I mean, that's what it comes down to - as far as the courts are concerned, passing copyright stuff through a machine results in the output retaining the original copyright. Passing copyright material through a person is not so clear cut.
> I see it differently. I look at it as if I had written this code myself, using this same approach. Look at the docs, look at the tests, look at the source, implement something that is interactively compatible but a very different approach.
I could look at a C to Zig compiler in the same way: I read some C code, write the equivalent Zig code, repeat.
The compiler could also do some circumlocutions in order to provide an apparently different approach.
I'm assuming you didn't read the article, since I'm pretty sure I covered all of this, but I'm happy to respond.
Don't bother.
It's probably not for you. It's slower, more obtuse, more bloated, less capable, exponentially less scalable at any size. Canonical Git is better in every way, except being a linkable library.
Even in the arena of being linkable libraries that can do Git stuff, both Gitoxide (Rust) and libgit2 (C which has git2 crate Rust bindings) are both better, they're just not feature complete. That is the only point of this project.
We're choosing a license that is usable by the entire community. Our goal is a linkable library, which makes GPL impossible. If we had chosen to go with LGPL or GPL with linking exception (like libgit2), it would have the same issue of changing the license, so we went with whatever was the most permissive so everyone could use it for anything if they wish. This has nothing to do with business - I hope I can get the project to the point where Jujutsu or whomever can use whatever is valuable here for whatever they want.
We clearly learned from how Git does operations and emulated it in order to function interoperably, the same way that Gitoxide and libgit2 have, and released it under a license that would be the most valuable for people wanting to use a linkable library, the same way that Gitoxide and libgit2 have.
> Our goal is a linkable library, which makes GPL impossible
Not impossible. It forces the code using the library to be under a GPL-compatible license and requires the binary to be released under the GPL license.
The distinction is quite important. It's only impossible in the mind of someone who wants to release proprietary software. Even for people releasing software under permissive license it's not impossible, just highly inconvenient (and the LGPL is always an option in this case).
>We're choosing a license that is usable by the entire community.
What a weaselly way to put it.
A GPL library, as I'm sure you know, is perfectly usable by anyone including jujutsu and anyone else. They just have to also license under the GPL and this is no barrier to open source projects.
I'm happy to take contributions if you want to throw some tokens at it. Bug reports would be amazing, since I haven't tested it for real very much (enough to know you can do basics).
I want to get it to the point where we can replace fork/exec'ing to an unknown Git binary or having said binary be an external dependency for GitButler. The networking stuff (push/fetch) is currently an external dep for both GitButler and Jujutsu (and pretty much every other Git-based tool in the world). I'm pretty sure I can get the project good enough at these networking ops (including all the hairy credential stuff) to be able to not need those fork/exec calls.
I started the project as Gust, but felt like Grit was such a better name. I asked Tom if I could boot the name back up again because I always liked it and he said it was fine.
Also, I worked on the Ruby Grit pretty extensively during the early days of GitHub, so hopefully I earned the right to carry on the mantle. :)
https://github.com/gitbutlerapp/gitbutler
reply