I've been using git for a while. I opened my GitHub in January of 2014, when I was about 14 years old. My first contribution was to ranui, about a year later. I contributed to open source projects in my teens, and worked on a lot of small hobby projects that were just my own, all in git, uploaded to GitHub (there was a brief GitLab phase, but it didn't last long).
I never completely understood version control though, it was just a necessity. Software developers use git, I wanted to be a software developer, so I used git. Last year, I started my first "real" software job out of college. The project had me, another new developer, and a senior developer working part time.
I had fewer people to ask about the codebase than any project in the past. Suddenly, version control became much, much more useful. At the same time, my contributions played a much larger role than any other project I'd contributed to, and it made more sense to document each change I made along the way. The senior developer on the project pushed us to make clean commit trees. I quickly understood the value - just in getting up to speed on the codebase I could feel how much a good version history mattered. So I started pruning my commit graphs. The commit history in my pull requests wasn't just a log of changes anymore; I tried to make them tell a coherent story.
The problem was that git made this painful.
I would lose work staging and unstaging hunks, accidentally leave things in the wrong state, and the feedback loop for fixing a mistake was long.
git rebase -i helped, but felt fragile — one wrong move and I'd be untangling a mess.
That's when I started using git-branchless. It let me undo changes and move commits around easily. It felt more like writing a proof, rather than scratch work: I had a problem, and here's each step along the way to solve it. Now I could create commit graphs intended for future developers, not just a list of save states.
Eventually git-branchless got too slow, though. I had heard a lot of buzz about Jujutsu, so I decided to give it a try. It took a few attempts to properly integrate it into my workflow. I didn't want to slow down during the day, so I threw it out if it ever caused problems. After a few attempts, it stuck.
Jujutsu gives me a feeling of control I was lacking in git.
I'm far from an advanced user; my understanding of the internals of jj is less than git - which is saying something!
But a few commands go a long way.
If I make too many changes and want to split them across a few commits, I use jj split and get an interactive view in my terminal to let me split that commit in two.
If I need to move the current commit before the previous one, I run jj rebase -r @ --insert-before @-.
I have the same undo functionality as with git-branchless, but it's faster and correlates more closely to the actual commands I issued.
And I don't have to worry about my working copy — many times I've been deep in my own code, needed to switch to a coworker's branch for a review, and I can do it seamlessly with jj new AB-123_.... My own changes are left intact.
It's not all perfect. There's a learning curve to Jujutsu's model (what exactly is a "change" versus a "commit" versus an "operation"?), and occasionally a command doesn't behave the way I expect.
But the key difference from git is that when something goes wrong with jj, I usually understand what happened.
With git, a bad rebase used to feel like I'd knocked over a house of cards.
I don't understand the internals of Jujutsu — but when I run a command, I don't feel like I need to. It maps well to my mental model of what a version control system should be: a tool for organizing thought, not a system to be placated.