But these days, I’ve moved on to jujutsu, a git-compatible version control system with much better primitives than git.
If you haven’t tried jj, I highly recommend it. The first-class conflicts and powerful but simple primitives for editing the commit graph are amazing.
It makes stacking branches an absolute breeze compared to git. And since it is git compatible nobody on your team has to change how they work.
It’ll take awhile for people to switch, but I think it will happen eventually. Invisible git compatibility means we don’t have to get everyone to switch all at once, and the benefits of primitives more aligned with the mental model of what we’re trying to do are undeniable.
I agree anyways, replacing Git is or would be a very difficult task in many cases.
That said, let us say I have a team of 3 people and we are starting a new project. We can definitely choose something other than Git, like Darcs (or later Pijul). If we use a project management software that only supports git, however, then that would be a very limiting factor. We probably would just continue using git, or use another project management software or I have no idea. I have used Git most of the time ever since I started using VCSs.
Jujutsu has all the advantages with none of the downsides and—unlike the alternatives—adoption doesn’t need to happen all at once. Every single person who I’ve convinced to give it a meaningful shot has fully converted. That speaks volumes.
It's like using Zig instead of C. You get a much better, handier tool, but you can interact with C very easily, transparently. You can mix and match.
Things like Monotone and Darcs were exquisite research projects, they tested many important ideas, but could not hope to become the standard. Jiujutsu does have this chance.
jj’s first class conflicts and the way it handles rebase offers a UX that’s not possible with git.
Like with jj rebasing a stack of branches is just a single command. In git you would have to rebase the branch at the top and then hard reset each branch pointer one by one. jj’s rebase is just more powerful than git’s. Like it doesn’t just rebase a linear series of commits it rebases merge commits, other sibling branches, etc… it’s absolutely mind blowing.
There’s workflows that I do with jj that are just completely impractical with git.
What I would focus on is what it enables you to do that’s hard in git: editing and revising commits that you’re iterating on, extracting out a large block of work into smaller commits, or splitting unrelated work out into a separate branch without needing to do a bunch of stashing, jumping around between branches, rebasing, etc.
Hell, even just being able to switch branches without having to do a wip commit or mess around with the stash is worth the price of admission to me. And having all of my work tracked during a long rewrite even if I don’t think to make checkpoint commits along the way.
But yeah, I’d 100% focus on what new superpowers you can add to your existing workflow before trying to actually change your workflow.
jj git fetch to pull upstream main.
jj rebase -d main to rebase your branch on main
As you add commits to your branch jj bookmark move to update the branch then jj git push -b branchname to push it to remote
Also I highly recommend a couple neovim plugins: hunk.nvim for splitting commits and jjdiffconflicts.nvim for resolving conflicts.