upvote
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?

reply
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
reply
[flagged]
reply
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.

reply
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.

reply
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?
reply
It's hard to tell since any given dev can just use jj locally, if they want to, while everyone else uses git.
reply
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.
reply
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)
reply
If I remember correctly, Mitchell Hashimoto uses it for Ghostty (probably under the git backend).
reply
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.
reply
excited for what you guys would be coming up with ;)

btw, did Martin leave google?

reply
Thanks!

Martin left Google for this, yes.

reply
Wasn't it partially owned by Google? Or are they just a contributer now?
reply
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.)

reply
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?

reply
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.
reply
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.
reply
> 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.

reply
But what if you didn’t have to read a 400-page book to properly version control your software?
reply
I honestly kind of think your experience is in favor of the GP’s assessment.
reply
It doesn't require that everyone switch at the same time, unlike other VCSs.
reply