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 :)
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
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.
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.
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.
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.
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.
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.
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.
Two hours later you realize your experiment is a total failure and you wish you had the half-working changes from earlier. You don’t need to have actively commited anything, it’s all in the obsolte log and you can retrieve it.
I want to repeat that last bit. Unlike git, there was no point where you needed to finalize your changes with a commit in order for them to be persisted and archived for later retrieval.
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.
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_.
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.
That interests me -- is there a native jj protocol for push/fetch? Even if just ssh? Or do you just work in local repos?
(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)
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 think the nixpkgs workflow is much less prone to rebase/merges (some cherry-picks to stable branches I don't do much), but it's a very good data point, thank you. I guess I'll give it a try over christmas break..
Large file stuff is also a “want to do something better but no progress yet” kind of thing.
Fingers crossed. Glad we're finally getting some viable Git competition with jj, Sapling and Pijul.
