So interestingly, many folks I've talked to had a reaction of "so jj is just a frontend to git, big whoop. There are hundreds of them, my favorite is X". That's an understandable reaction.
But jj is more than that, and you couldn't implement it as a git wrapper. I think the core innovation is that rebases are so fast they are essentially free, which opens up amazing potential.
But so far I haven't found a way to really convey the full weight of this without a long explanation, because people are so used to thinking in git, it takes a long time to go beyond "so rebase -i will be faster, then? But it's not slow, is it?"
It's funny, that git is now in the position that subversion was in almost two decades ago: People were so used to svn and felt productive with it, it was hard to convey why free branches and a distributed data model are a gamechanger, and how much svn limited their thinking. But as a git user you had certainty that you were right, and that your tool is superior.
Now, people are so used to git, in an eerily similar way. But ask most git users, "how would you move a specific change from your branch to another?" I have yet to receive a confident answer and workflow to this (they do exist ofc), the common reaction I get is that this isn't something they'd ever need anyways.
I'm curious how this will look in a few years :)
> this isn't something they'd ever need anyways.
Oh I do that quite often, either because I didn’t realise I was committing on the wrong branch, or I decided to split my work in two branches, or i need some other unmerited change for my current branch…
It’s usually a rebase —onto or cherry-pick, I’d say I agree it’s not simple.
jj seems interesting, I’m very comfortable with git but I think its UX is terrible, but everyone use git and it is not an area where I have capacity or willingness to innovate. I’d love to see git being replaced with something better designed though
Nobody else needs to convert to jj for you to use it, so there’s no real downside to switching.
The difference between git and svn is, svn is very fixed in terms of workflow. On the other hand, git allows many different workflows, and allows people to handle their codebases the way they see fit.
Of course, no tool is truly universal, and git frontends and alternatives leverage different parts of the underlying data structures with different trade-offs.
I personally never use rebase, and am a merge guy. I don't use a gazillion branches either, not because I'm afraid of them, but my mental model works like that. Some people squash commits, others rebase, etc. Everybody is different in their ways.
svn to git was a fundamental change and allowed new things to happen. jj on the other hand makes some workflows easier while others take the back seat. So I don't see jj as a git disruptor, but an opinionated alternative tool which uses git data structures as the backend.
I agree that the change isn't of comparable magnitude. But JJ changes the user facing conceptual structure of version control. It unifies working directory, stash, index and commit, and replaces them with a single thing. And it shows that all existing git workflows can efficiently be constructed on this much simpler conceptual basis.
In my mind this demonstrates convincingly that gits conceptual model carries unnecessary incidental complexity. Within a fixed complexity budget jj absolutely does allow new things to happen.
I also don't really see any workflow examples that truly suffer under jj, so I don't think it's just another trade-off. It's a real substantial improvement. If it wasn't it wouldn't be making headway against gits network effects.
From what I understand, all these different places/things (working directory, stash, index and commit) confuses, and comes across unnecessary to some people. They want a simpler solution, and less mental load during version control phase of their software, that's understandable.
In my experience software developers come in two flavors. a) Developers who want to understand all the pieces they work with and have the desire to deep-dive into them b) Developers who write and commit code. They think that former part is their job and care about it. They don't care after it leaves their machine (in the sense of "I give box to machine it magically integrates").
IMHO, jj is very enticing for the latter camp, and that's not a bad thing. Not all of us are passion programmers/developers, and some are don't want to think about beyond their immediate realm. I respect these people. But, again, from my perspective, jj doesn't make sense for me. It's useful alright, but I actively use index, commit and stash very naturally. I might be good at understanding it because Eclipse has a great git integration which makes everything super workable and understandable, and I'd never change a power tool like git to something "push button, magic happens" class of tool.
jj might be very conductive to more complex workflows by removing some complexities, but unifying my stash, staging area and index is not something I want to be dome to my workflow for example.
Some trade-offs make great headways into networks because a large part of that network is silently suffering without being aware, and the trade-offs are worth it. See Rust for example. People accept 5x mental load and 10x compile times for memory safety. Same for jj. People accept a much simpler interface because it makes their painful workflows "push button, magic happens" levels of simplicity. Or, the people who like jj work under time pressure and want to remove a time-sink from their workflows, again understandable and respectable.
Having something like "jj" is not a bad thing. What I'm squarely against is "git is dead, new king is jj. Now move to your new kingdom and worship jj" mentality.
I think you have it backwards. jj is absolutely for "a) Developers who want to understand their tools". The simpler data model opens up new workflows that weren't possible before.
Unifying concepts is not taking away any expressive power. It just makes the system as a whole simpler to reason about.
I think it's a similar step up in power as moving from Windows to Linux. On Windows, to toy with the system at all you need to set up a C++ project and dig through win32 API docs and deal with opening/closing handles and void* pointers just to change anything, so I rarely bothered. On Linux everything is right there in the file system so there's almost no friction to changing things. You can do anything imaginable in a minute or two with just a shell script.
In Linux, Everything Is A File. In Jujutsu, Everything Is A Commit.
You’re making an understandable mistake. Jj being simpler doesn’t mean it is less powerful. It means it’s more powerful. This happens very rarely, but it is the case here. Removing the index and stash as unique concepts doesn’t mean that their use cases disappear: they gain power, because you can use any tool that works on a commit on your “index” or “stash” because they’re also just commits.
I actually like git’s CLI. I never understood why people wanted a simplified git. I’m never going back to git from jj. It’s just better.
Being in group #1 does not mean that I want to interact with every system at the lowest possible levels. I want to interact in ways that fit how I work, not to fit how I work to the ways the system works.
> "git is dead, new king is jj. Now move to your new kingdom and worship jj"
No one is saying this. If you feel like people getting excited about Jujutsu is them telling you that you must love it, that's on you. The fact that it is built on top of Git means that even if others are using Jujutsu, you are not forced to when working in the same repos.
I was a git power user. I am comfortable with and understand the index, stash, rebases, the reflog, and all the rest. I have written a git implementation.
I have converted to jj and will never go back. It is simpler and more powerful.
> I personally never use rebase
Probably a lot of that is because it is painful. When it becomes a no-op, suddenly a lot of things become easy to do.
Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard.
Do you ever want to maintain a linear chain of branches? Branch A needs to be merged before Branch B needs to be merged before Branch C. It’s a massive pain with git, especially if you need to change Branch A. It’s a no-op in jj.
There are a ton of straightforward and useful workflows in git that are just completely impractical.
> Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard.
Also unnecessary, "git rebase -i" has an "edit" command that pauses the rebase at that commit to let you do whatever.
You’ll find this to be true about many things.
For example, the solution to almost all problems is oddly kubernetes shaped even though that was not the case 15 years ago. And Google themselves would be the 1st to tell you that kubernetes is not capable of doing all jobs.
Monocultures are insidiously bad, they poison solutions and reasoning, but they have their upshots too- if you never need to learn a new mental model; us tech workers become more interchangeable and the cost to onboard goes down.
You've been so welcoming in the jj community. Thank you.
I don't understand how absorb works in your example. Why would the commit "z" be affiliated with some random documentation changes you come across and fix in the wip commit.
All that I see is it makes it easier to make small refinements to preciously altered lines ?
Super excited for jj.... Almost want to find a work opportunity to promote it. Been a refreshing tool I've adopted in 2024 I'm happy about.
> Why would the commit "z" be affiliated with some random documentation changes you come across and fix in the wip commit
It's not? z is the root pseudo-commit.
> All that I see is it makes it easier to make small refinements to preciously altered lines ?
Well yes, the point is to untangle working copies with various unrelated changes (usually fixups) which should really go into older commits.
This does halfway convince me to try it using jujitsu.. However I think the biggest barrier so far is that I understand how to undo mistakes in git but I don't in jujitsu.. if you accidentally run 'jj squash --into x --keep-emptied' when you meant 'jj squash --into n --keep-emptied', how do you undo that?
Literally `jj undo`
There's a whole operation log (`jj op log`), as another sequence of actions, and you can undo them. It gets crazier from there, but I've also been enjoying jujutsu lately and I had to RTFM a good couple of times to get comfortable with it.
You can even undo operations that aren't the most recent one.
Huh this comment thread may have convinced me to finally try it. I’m comfortable with git, and fixing mistakes in git, but not being able to trivially reverse any and every transaction is annoying.
I made a mess of a jj repo recently. A big mess. Ran `jj op log`, found the operation I wanted, and just `jj restore`d my way back to that exact prior state. Then started what I was planning afresh and got it right. Felt magical.
And I didn't have to learn anything like the hell of git refs. The UI is self-explanatory as long as you know the feature exists.
Another very nice thing is that conflicts aren't roadblocks. They're legit changes, first-class jj citizens. So, when I do something that ends in a conflict, I can just move over to a different change, do the work I'm already trying to do, and then go back and resolve the conflict when I want.
Ah yes, I’ve heard it makes the hell of huge conflict ridden rebases a bit less annoying. Always wished I could just get to the end of the rebase to see it all in context, _then_ resolve conflicts, but with the option to resolve the obvious ones along the way too.
Yep, this was the thing that encouraged me to look at jj. I am so done with rebases where I’m stuck in some meta-state where I need to figure out exactly what needs to be done—linearly, right now, and without making any mistakes—but all the regular tooling to jump around and explore is unavailable until I’m finished with the whole thing.
I would honestly use jj for just this even if that was all it offered.
I hear ya. I've done some crazy things with `git reflog` (which I always pronounce git re-flog instead of ref-log) but it is not fun.
There's the usual cognitive shift, and in my case a bit of a best-practice shift I had to go through to get comfortable with `jj` -- specifically, keeping the repo directory pristine (and putting my temp output in a git-ignored dir, or outside the repo) because /everything/ is tracked. Flip side being, I've forgotten to `git add` new files at least a few times a year, and now that won't be an issue.
But yeah, can highly recommend, and I'm excited to start to jump between multiple open branches^Wbookmarks at will and learn more about the intricacies of conflict management (and the original link is a good glimpse at that!)
Are new files tracked by default? If I forget to ignore a bunch of build outputs, will that make my repo huge immediately?
There’s a configurable cap on max file size to auto-add, IIRC. It defaults to something “reasonable”.
If you do somehow add a terabyte of small files by accident, it’s still just git under the hood so you can make sure nothing active points at them and GC them.
I'm thinking of something like node_modules, sounds like I'll need to not forget.
Those are usually in your gitignore, right?
Also, this behavior (automatically tracking) is configurable. I thought I would hate it but I actually really like it.
Yeah they usually are, I'm sure it's great because I add files more often than I ignore, but I need to be careful with the temporary files I write left and right in the repo dir during development.
Why? You can easily remove them if they’re accidentally added.
Just because I might not remember/notice, and I don't want sensitive data to be committed by accident if I put an env var on disk for some reason.
If you check `jj status` regularly and/or use `jj split` to build up your commits (like `git add -p`) then you’ll notice. They might end up in your local repo (until a gc) at worst.
Ah, that's not too bad then, thank you!
To elaborate on the other comments, it is extremely easy to use the op log to undo basically anything.
I was live demoing something and performing some manual repo surgery in order to demonstrate some thing that can happen with git but is nicely solved by jj. In doing the surgery I absolutely fucked everything.
I had never used the undo feature or the op log before. In less than five minutes—during the live demo—I was able to figure out how to reset things back to a known good state. It was stupidly easy.
Does jj do anything about submodules being horribly buggy in Git, or LFS being taped on the side as an afterthought? I guess they can fix the submodule bugs but presumably they can't fix LFS without breaking Git compatibility?
Right now Jj basically ignores submodules, they do want to fix it but haven’t yet. So you just use git commands in a colocated repo for now.
Large file stuff is also a “want to do something better but no progress yet” kind of thing.
I think having both those working would be a serious reason for a lot of people to switch. E.g. just having working submodules and worktrees would do it for me.
Fingers crossed. Glad we're finally getting some viable Git competition with jj, Sapling and Pijul.
How does jj handle very large git repos, e.g. this linux clone with a mix&mash of quite a few upstreams with a 6GB big .git dir?
(I agree I probably shouldn't focus on that first, and could just try jj first on smaller rpos... But git is already slow enough in there that it's an honest question, I don't need to keep using git there as long as I can keep pulling from stable kernels git trees for regular merges)
It works fine on nixpkgs, which is by some measures larger than the linux git repo.
jj git clone/fetch/push are using the corresponding git commands under the hood so they won't improve on git performance but also it doesn't have much overheard of its own.
If you're using the -T revset syntax, you can specify a revset that requires looking at every commit, which is slow, but that's equivalent to asking for `git log -n 1000000`
I am slowly inching towards trying out jj. I think the main issue will be if I find some issue in the git compatibility aspect. I do two kinds of work:
1. Work on smaller projects with simple histories. Git is perfectly satisfactory.
2. Work on huge projects with very complex git histories and weird legacy workflows (primarily Linux kernel).
jj is only interesting for part 2, but then it's only useful if it's easy to bridge into the Git world that everyone else uses.
But this workflow is exactly the kind of thing that seems handy. There's so much stuff that Git can totally _do_ but could just do a lot _better_.
Just try it!
I converted 6mo ago after finally pulling together the motivation to give it a shot. My biggest hesitation was in how long I expected to struggle with it before feeling comfortable, followed closely by skepticism about how good the compatibility story actually is.
Both, it turns out, were non issues. It took all of a day to feel perfectly comfortable using it. I spent the rest of the week gradually plugging most of the remaining holes in my workflow. And git compatibility is as advertised. A coworker switched shortly after I did and zero people have noticed or cared.
Though at this point I don’t even bother colocating the .git repo alongside .jj. Meaning I haven’t found a need to fall back to git commands in maybe four or five months.
> Though at this point I don’t even bother colocating the .git repo alongside .jj. Meaning I haven’t found a need to fall back to git commands in maybe four or five months.
That interests me -- is there a native jj protocol for push/fetch? Even if just ssh? Or do you just work in local repos?
Backends can do whatever. The git backend knows how to push to git remotes. If you used a different backend, it would know what those backends expect. There aren’t any of these publicly, but Google has one to work with piper.
Google's internal git support for the Google3 monorepo was deprecated/is unsupported in favor of fig, the mercurial/hg based client for Google3.
Microsoft has a custom git client internally which includes a filesystem shim (think: the Windows equivalent of FUSE) since stat-ing monorepo amounts of files doesn't work. Also GitHub's running custom git servers, though their custom database backend is behind a compatibility layer.
Finally, sapling, Meta's git replacement which maintains supports for git servers also supports sapling servers (which was not released). Unsure whether to count that as a git backend though.
For sure. This kind of thing is very useful. It’s why jj is backend agnostic by design.
How's the tool compatibility when using gg tho? My repo work tends to be split between git and magit, and while I would very much welcome the ability to get rid of git for a better experience, doing so at the cost of magit is an extremely steep hurdle.
I actually find jj great for (1). The project I reference working on in this post is in exactly that bucket, and the kinds of things I do with it are not “complicated” but jj is still much, much better than working with Git—not least for the kind of workflow I showed in this post!
jj might be the future. I certainly hope git is not. My current system is Mercurial with hg-git and evolve, and so far I find this to be fantastic for local development. There are a few rough edges but I just find hg so simple to use and consistent in functionality. I can usually just figure out how to do what I want from the --help screens. In git I often read the man page for a commit and then I just ask ChatGPT how to do it because the man page for each sub command is a novel. I hope that jj will aim for simplicity in the long run but I guess we'll see.
Looks amazing -- hopefully some day they'll add git-lfs support and I'll finally be able to try it. :-)
Goddammit. This gets me every-time. Click these threads expecting Jujitsu only to find source control!
There’s also gitbutler for this kind of workflow, a bit more visual.