I absolutely love jj (just check my HN comment history). One thing I'd love to see in jj though that git does better is copy tracking. If somebody renames a file upstream, and you go to rebase your commit that touches that file onto main, jj doesn't handle this very well compared to git.
Do you have any idea if this is coming to jj soon?
I left a lengthy comment below about how we'll be supporting git as well.
I have been a member of this community for a very long time. Posting here is something I just do. jj is already pretty well known here, there's articles about it quite often. But sure, I don't think that anyone would deny that a VC backed startup posting about their product to Hacker News has marketing value. You have to get the word out somehow.
EDIT: oh, this person edited their comment after I replied. There's been a rash of these comments making wild, baseless accusations about Rust developers, thank you dang and the other mods for handling it.
I've met you (Steve) and hung out with him for a few hours after oxidize. He's none of those things, and in fact was one of the most pleasant people I've met at conferences. So not only are they brazen and vulgar allegations but I can't see even a distant parallel universe where they're even close to true.
Technically, you can still tell actually - jj writes a "change-id xyz..." in the git commit object header, which remains there as it's pushed around. It's just typically not made visible by regular things. (I wonder what other random garbage has been hidden in git commit headers that noone has seen)
Huh, fortunate for it that GitHub (especially) preserves it then!
I wonder how guaranteed that is, can imagine GH deciding to 'clean' it (how much data can you put there theoretically? Or to close a range of potential security issues) and suddenly relatively niche but genuine uses like jj's change-id are unintentionally not preserved.
Cleaning it would change the commit ID, so a forge cannot clean it even if it wanted to (not without rewriting all descendant commits too and breaking signed commits, at least).
The change-id is exactly as much part of the commit object as the author/committer name/timestamp, description, parent commit ID, tree, and participates in the commit hashing as those do.
I like to compare Google and jj to Mozilla and Rust: Google employed Martin and some other maintainers, but it's always been an OSS project under the Apache 2.0 license.
That being said, there's a few things that lead to this perception: the first is that it used to be under Google's GitHub account, but is now under its own org. The second is that contributing to jj does require signing Google's CLA. That is something that is desired to change, but that's up to Google. Due to the license, the community could fork it, and still have the rights to use the code, but that would be pretty aggressive, and so everyone involved would rather work together on this than do so. The move to its own GitHub org was one example of movement in that direction, but I'm not aware of an actual timeline to remove the CLA just yet. The project will figure it out over time.
(I have a commit bit but am not a jj maintainer, so the above is my own impression from being involved in the community for the past few years.)
Maybe if Martin could comment - his @google.com email still appears in the repo readme, I'm assuming he doesn't have access to that box anymore - was the repo move and ownership coordinated with Google prior to his leaving?
Will this have any chance if Jujutsu/jj doesn't get more traction? The effort to learn a new VCS is less than for a programming language, but many developers have not learned git in depth, and Mercurial and others have not gained a lot of traction.
I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint (lots of inconsistent naming of things and somewhat leaky abstractions), and that Mercurial faced an uphill battle in large part because it lacked compatibility with what people were already using. I haven't used Mercurial, but from what I've heard quite a lot of how jj does things is similar to Mercurial, just in a way that's compatible with git. I haven't used git directly for over a year in favor of using jj despite exclusively using git repositories, and no one I've worked with has even needed to be aware.
> I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint
Not really. I remember my early years with git and the favt was that I never needed more than clone, add, commit, pull and push. While I’ve done some mistakes that got ne to learn more, especially with creating branches and undoing. I’ve never needed a lot, even when I started using GUI which exposed more concepts.
Why? Because I have no understanding of version management and how it’s useful in a dev workflow/release process. I was just using it for checking in work.
Since then, I’ve read the “Pro Git” book, learned how devs and teams handle versioning and devel a good understanding of how git can help me in my coding process and general software development. And it’s very good at what it does.
"Properly" is doing a lot of work here (Claude would say it's load-bearing ;) If one's needs are modest, then no, the 4-5 basic operations don't need a 400-page book to understand, and are quite proper for version-controlling one's software.
I absolutely love jj (just check my HN comment history). One thing I'd love to see in jj though that git does better is copy tracking. If somebody renames a file upstream, and you go to rebase your commit that touches that file onto main, jj doesn't handle this very well compared to git.
Do you have any idea if this is coming to jj soon?
There is active work in this area, yes! https://github.com/jj-vcs/jj/issues/3386 is the bug tracking the feature request, and there have been some recent PRs working on implementing this, see here for one example: https://github.com/jj-vcs/jj/pull/9864
[flagged]
I left a lengthy comment below about how we'll be supporting git as well.
I have been a member of this community for a very long time. Posting here is something I just do. jj is already pretty well known here, there's articles about it quite often. But sure, I don't think that anyone would deny that a VC backed startup posting about their product to Hacker News has marketing value. You have to get the word out somehow.
EDIT: oh, this person edited their comment after I replied. There's been a rash of these comments making wild, baseless accusations about Rust developers, thank you dang and the other mods for handling it.
I've met you (Steve) and hung out with him for a few hours after oxidize. He's none of those things, and in fact was one of the most pleasant people I've met at conferences. So not only are they brazen and vulgar allegations but I can't see even a distant parallel universe where they're even close to true.
Super bizarre comment to see on HN.
Do you happen to have or know of any good open source projects on any public platform like GitHub, gitlab or Codeberg, that uses Jujutsu/jj?
It's hard to tell since any given dev can just use jj locally, if they want to, while everyone else uses git.
Technically, you can still tell actually - jj writes a "change-id xyz..." in the git commit object header, which remains there as it's pushed around. It's just typically not made visible by regular things. (I wonder what other random garbage has been hidden in git commit headers that noone has seen)
Huh, fortunate for it that GitHub (especially) preserves it then!
I wonder how guaranteed that is, can imagine GH deciding to 'clean' it (how much data can you put there theoretically? Or to close a range of potential security issues) and suddenly relatively niche but genuine uses like jj's change-id are unintentionally not preserved.
Cleaning it would change the commit ID, so a forge cannot clean it even if it wanted to (not without rewriting all descendant commits too and breaking signed commits, at least).
The change-id is exactly as much part of the commit object as the author/committer name/timestamp, description, parent commit ID, tree, and participates in the commit hashing as those do.
All my prs are named phil-<hash> and have been for years now. I keep waiting for someone to care/notice, but no one has.
Checkout Gisia https://github.com/gisiahq/gisia
jj uses git as a backend. None of those need to "use" jj. You can use jj in an existing git repo, with your git wielding friends.
If I remember correctly, Mitchell Hashimoto uses it for Ghostty (probably under the git backend).
excited for what you guys would be coming up with ;)
btw, did Martin leave google?
Thanks!
Martin left Google for this, yes.
Wasn't it partially owned by Google? Or are they just a contributer now?
I like to compare Google and jj to Mozilla and Rust: Google employed Martin and some other maintainers, but it's always been an OSS project under the Apache 2.0 license.
That being said, there's a few things that lead to this perception: the first is that it used to be under Google's GitHub account, but is now under its own org. The second is that contributing to jj does require signing Google's CLA. That is something that is desired to change, but that's up to Google. Due to the license, the community could fork it, and still have the rights to use the code, but that would be pretty aggressive, and so everyone involved would rather work together on this than do so. The move to its own GitHub org was one example of movement in that direction, but I'm not aware of an actual timeline to remove the CLA just yet. The project will figure it out over time.
(I have a commit bit but am not a jj maintainer, so the above is my own impression from being involved in the community for the past few years.)
Thanks!
Maybe if Martin could comment - his @google.com email still appears in the repo readme, I'm assuming he doesn't have access to that box anymore - was the repo move and ownership coordinated with Google prior to his leaving?
Will this have any chance if Jujutsu/jj doesn't get more traction? The effort to learn a new VCS is less than for a programming language, but many developers have not learned git in depth, and Mercurial and others have not gained a lot of traction.
I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint (lots of inconsistent naming of things and somewhat leaky abstractions), and that Mercurial faced an uphill battle in large part because it lacked compatibility with what people were already using. I haven't used Mercurial, but from what I've heard quite a lot of how jj does things is similar to Mercurial, just in a way that's compatible with git. I haven't used git directly for over a year in favor of using jj despite exclusively using git repositories, and no one I've worked with has even needed to be aware.
> I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint
Not really. I remember my early years with git and the favt was that I never needed more than clone, add, commit, pull and push. While I’ve done some mistakes that got ne to learn more, especially with creating branches and undoing. I’ve never needed a lot, even when I started using GUI which exposed more concepts.
Why? Because I have no understanding of version management and how it’s useful in a dev workflow/release process. I was just using it for checking in work.
Since then, I’ve read the “Pro Git” book, learned how devs and teams handle versioning and devel a good understanding of how git can help me in my coding process and general software development. And it’s very good at what it does.
But what if you didn’t have to read a 400-page book to properly version control your software?
"Properly" is doing a lot of work here (Claude would say it's load-bearing ;) If one's needs are modest, then no, the 4-5 basic operations don't need a 400-page book to understand, and are quite proper for version-controlling one's software.
I honestly kind of think your experience is in favor of the GP’s assessment.
many developers have not learned git in depth
They have less to walk away from then.
It doesn't require that everyone switch at the same time, unlike other VCSs.