In California, it's capped at a knowable amount when you buy the home and pegged at the sale price. You know what it is and what it always will be when the transaction happens. The people whom have owned a house now worth a million for 30 years probably pay a few grand a year and always have. Dry taxing the technical value of their assets today would destroy millions of families. The point is that dry taxation is generally pretty stupid.
In fact, we should have expanded it to be a "millionaire tax" where everyone who has a home worth more than $1M needs to pay a one time $50k+ tax to the highly efficient state government. I'm sure they can easily figure out how to sell a small fraction of their home to cover it.
If there is one thing that history has proven, I think it's how valuable dry taxation is for everyone in the long term.
Relicensing under any other license, including the LGPL, is exactly the same thing. Either the reimplementation copies protected expression, in which case it would be required to be GPL-2.0-only, or it does not, in which case we can choose the most fitting license.
If you believe that using an MIT license is not correct, then you defacto also believe that using an LGPL license is not correct.
Nice, I haven't dug into this yet. If we can get this usable, it would be pretty cool to have a small lib or a series of much smaller, directed libs that can be used by simpler interfaces and you can just compose the parts you need.
Not yet. I have a PR with a WASM experiment based on an earlier build, but it's not integrated. It's on my list of things to try. I _did_ get it working for some things, so it's clearly possible, but I need to put some more effort into it.
Well, there's lots of really interesting opinions here from a lot of armchair lawyers.
To clarify, my stance on this is that the reimplementation did not copy protected expressions (Jplag reports less than 1.8% max similarity between the codebases), it's done in good faith, and it's what's best for the broader Git ecosystem (assuming Grit even becomes usable, which it's currently not purported to be).
From a copyright standpoint, however, only the first argument there is relevant. Grit is an independently authored implementation of Git-compatible behavior, with negligible similarity to Git source code.
I think antirez summarized the situation quite well and I broadly agree with his position: https://antirez.com/news/162
I think that those in the community who know me and have worked with me in the Git and open source communities for the last 20 years know that my intentions are to contribute, share and foster innovation and learning. Many of the main authors of the Git source code are friends of mine and I have no intention to steal anything from anyone, only to make their great ideas more broadly useful.
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.
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.
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.
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. :)
I would not use this except to help us test it if interested. I'm announcing it because it's interesting and a milestone in the breadth of test coverage it can pass. It almost certainly cheated on a bunch of those tests and is not feature complete yet.
The author of gitoxide is also working on GitButler (who worked on this project) and we're pushing both projects forward and actively using and developing Gitoxide as well. This is simply a different and hopefully complimentary approach to the same problem.
libgit.a isn't reentrant. It will call `die()` on many errors. If you link to it in a long running binary, it will kill your process on error.
Libgit2 is meant to address this and I was heavily involved in the development of that project 15 years ago. It's great but it's not feature complete and it's development is also completely separate from git development, so it's out of sync and constantly struggling to keep up.