3 ms·

Git had a very small initial implementation, while jj is under development for years and is large. If jj is not too complex to have multiple implementations, wh

Git had a very small initial implementation, while jj is under development for years and is large. If jj is not too complex to have multiple implementations, why have new implementations not sprung up by now? Is it the Google CLA, or are too few people using jj, or is jj too complex, or some mixture of all of the above? The Google CLA is still required as of 2026, which I find strange. https://lwn.net/Articles/958805/ https://lwn.net/Articles/958805/ > Second, I thought about contributing a fix to that table, and then I saw the contributing requirements: > > Contributor License Agreement > Nope, not happening. Nobody should adopt this until it's been freed from that requirement, either by getting the project to remove it or by establishing a version of the project that takes contributions without that requirement.

KingMob 1mo ago
> why have new implementations not sprung up by now? Nobody wants to yet? FWIW, while there aren't multiple reimplementations of the core yet, there ARE multiple GUI and wrapper projects that fulfill various needs, if you're just looking for outside contribution as a health measure.
aseipp 1mo ago
Jujutsu also started out very small, just like Git did. The core concepts aren't too complex. But this is 2026, not 2005 or 2019. Most of the modern Git implementations are extremely large, highly optimized and featureful codebases that are difficult to replicate. Many of Git's performance and structural improvements over the last few years have nontrivial implementations and designs. Jujutsu is also a large, featureful codebase. You can't build a modern Git implementation with all of the highly optimized goodies (multipack indicies, partial clones, etc) and a good UX without a lot of code and work. Or any version control system, frankly. It's just how it is. - Gitoxide is 80,000+ lines of code. - Git itself is over 170,000 lines of code. - Even "Game of Trees" or "got" by the OpenBSD developers, which is a wholly separate project that has its own porcelain, is +120,000 LOC. - Jujutsu itself is about 100,000 LOC. - JGit for Java is around 200,000 LOC. These are all roughly approximate and include things like testing code (but I think that's fair because tests are part of the project). All of these projects started small years ago, and are now large. > If jj is not too complex to have multiple implementations, why have new implementations not sprung up by now? "Make multiple implementations" is not, in and of itself, particularly valuable without some underlying justification to do so. It also is not how (AFAIK) any other version control system has ever worked; Git's "identity" as an on disk format is a particular design choice (with pros and cons), so yes you can get multiple tools with varying levels of features that agree on the basic disk format and poke at it. But most projects just don't work this way, much less other VCSs; there also aren't really many "Linux re-implementations" beyond toys because it is easier to just collectively contribute with each other, because Linux is not a "standard" written in stone, but a living and breathing thing.

KingMob 1mo ago

> why have new implementations not sprung up by now? Nobody wants to yet? FWIW, while there aren't multiple reimplementations of the core yet, there ARE multiple GUI and wrapper projects that fulfill various needs, if you're just looking for outside contribution as a health measure.

aseipp 1mo ago

Jujutsu also started out very small, just like Git did. The core concepts aren't too complex. But this is 2026, not 2005 or 2019. Most of the modern Git implementations are extremely large, highly optimized and featureful codebases that are difficult to replicate. Many of Git's performance and structural improvements over the last few years have nontrivial implementations and designs. Jujutsu is also a large, featureful codebase. You can't build a modern Git implementation with all of the highly optimized goodies (multipack indicies, partial clones, etc) and a good UX without a lot of code and work. Or any version control system, frankly. It's just how it is. - Gitoxide is 80,000+ lines of code. - Git itself is over 170,000 lines of code. - Even "Game of Trees" or "got" by the OpenBSD developers, which is a wholly separate project that has its own porcelain, is +120,000 LOC. - Jujutsu itself is about 100,000 LOC. - JGit for Java is around 200,000 LOC. These are all roughly approximate and include things like testing code (but I think that's fair because tests are part of the project). All of these projects started small years ago, and are now large. > If jj is not too complex to have multiple implementations, why have new implementations not sprung up by now? "Make multiple implementations" is not, in and of itself, particularly valuable without some underlying justification to do so. It also is not how (AFAIK) any other version control system has ever worked; Git's "identity" as an on disk format is a particular design choice (with pros and cons), so yes you can get multiple tools with varying levels of features that agree on the basic disk format and poke at it. But most projects just don't work this way, much less other VCSs; there also aren't really many "Linux re-implementations" beyond toys because it is easier to just collectively contribute with each other, because Linux is not a "standard" written in stone, but a living and breathing thing.