[ocular-rockular]

But why build a whole VCS around that one use case? I looked through the docs and honestly it looks like it complicates life instead of making it easier.

edit: everyone is so focused on the "single use case" part and not the fact that it looks more complicated and verbose than regular git. Unless everyone using it is some git god that runs into edge cases left and right... maybe my workflow is just not that complicated to need a solution to problems I don't have?

[stouset]

Because every person in here who’s actually used jj is telling you straight up that it’s less complicated.

Using jj is less complicated in—as far as I can tell with six months of conversion—actually 100% of the time. I spent one day adapting and maybe two week of having to look something up every other day. And now all of git’s infamous pain points are gone.

There is no index. There is no stash. Rebase conflicts are (and rebasing in general is) no longer painful. Jumping between work is a no-op. Fixing up earlier work is a no-op. There are no modal “interim” states like during conflicts where you have to abort or continue to get back to normal.

You don’t have to be a git god to run into the many sharp edges of git, and all of the “but my workflow is simple” comments break down upon even cursory inspection. Everyone’s workflow is simple until a rebase goes wrong, or they unstash in the wrong branch, or they need to unfuck an earlier commit, and that list goes on and on. And when you’re in these states you have no practical way to save or persist incomplete work.

Jujutsu is both more powerful and simpler, and I say that as someone who knows git inside and out and who’s used it pre-GitHub.

[ocular-rockular]

Okay, happy it works for you. Still don't see a point.

[SansGuidon]

The point for me is to build better and remove the need to know so much about vcs. Git is powerful but requires too much knowledge about git itself to get things done or to tackle possible conflicts in collaboration. Jujutsu tried to remove some of the concepts or make a better ui, to remove some complications. It's like providing an abstraction like python instead of C. Yet it's not perfect. I also struggle to transition to jujutsu yet I admit some benefits. But honestly both are yet too complicated and error prone for something as basic as communicate changes and align versions with each other. I'm happy to see initiatives such as jj but it's still an alpha.

[mamcx]

> looks more complicated and verbose than regular gi

Is Git not verbose and complicated?

It is like the poster child of it among ALL THE OTHER options in his space!

---

I was a heavy user of mercurial, I learned it in a day or two, then maybe only had one or 2 major complications for years.

I use git now for 'social' pressure reasons, and despite I use it more heavily than hg, i need to check stuff every week.

And have some bash scripts around to automate how to back out of rebase hell.

[steveklabnik]

You’re like the perfect audience for jj. Give it a try with some of your git repos. If you hate it, easy to go back to git afterwards. But I think you’ll like it.

[mamcx]

Ironically the major thing that blocks me is the need for more adoption.

I predict I will have enough of it in the next mess of trying to stack PRs or resolve another rebase of 30 steps.

[ocular-rockular]

Not to me.

[lawn]

It's not the only improvement though, depending on your workflow.

Another thing you can do is work on multiple branches at the same time. See: https://ofcr.se/jujutsu-merge-workflow

[keybored]

It’s not necessarily the only use case.

But as I’ve read (according to Martin) doing it this way simplifies the implementation a lot. You track everything directly in the DB. In turn you don’t have to care about all sorts of states like being in conflicted git-am state, conflicted git-merge, etc.—these states cannot happen, it’s all in the DB (not some dirty working tree state where some flags or files somewhere in `.git` or `.jj` tell you “there are some conflict markers thereabouts, enjoy”).

And that frames it in terms of being easier for the people implementing jj. But I think it will also benefit us users by making it easier for them to create streamlined tools.

git-rebase(1) and all that is great and all. But definitely messy. And we only recently got `--update-refs` to update dependent branches, which is kind of late considering how important branches are in Git.

[zug_zug]

Moreover, even if it was say 15% better than git (and I doubt it is), the overhead of moving a whole industry across VCs is billions of dollars of loss.

Every single engineer has to start over in their mastery experience by learning all the new quirks and issues, and all the tools, libraries, pipelines need to be rewritten.

IMO better to support the dominant tooling than invest in fracturing one of the few areas where engineers can agree on something for once (to everyone's benefit).

[eviks]

It's also billions of dollars of gain: every single future engineer won't have to waste time due to 13% worse design.

But jj supports git as a backend, so not clear what fracturing you mean, do people using magit front-end fracture?

[lawn]

The upside with jujutsu though is that it's completely compatible with Git and you can work on the same repository with Jujutsu while your coworkers use Git.

This allows the people who want the 15% gain to have it, while not forcing anyone to do a costly migration.

[KerrAvon]

I know people who really hate git because the UI is so awful, and it’s (theoretically) way more than a 15% gain for them. They’ll get to stop rubbing broken glass against their legs every day.

[SansGuidon]

Git feels like solving puzzles everytime there are branches or collaboration made on a repo. So every day. Most productive days are when I dont need to use git. JJ is a workaround for git pains but the UX is not mature enough for replacing git yet.

Having distinct local working copies of same repo per git branch still works great, not stash needed, no conflicts or pain with local wip and drafts changes overwritten by pull. No blocker for switching branches. No reset hard/soft whatever. And makes files comparisons easier and makes my git workflows easier.

I still feel vcs could be simpler and solved problem if more engineers care about the topic of vcs and generally speaking about the ux of their main tools instead of creating new TUI and plugins to workaround broken ones.

[stouset]

> Every single engineer has to start over in their mastery experience by learning all the new quirks and issues, and all the tools, libraries, pipelines need to be rewritten.

I was a git power user. I became comfortable enough with jj to replace git entirely in one day.

[stouset]

> IMO better to support the dominant tooling than invest in fracturing one of the few areas where engineers can agree on something for once

If Linus had this mentality we’d all still be using Subversion.