I'm one of the git users you describe who are resistant to jj. jj sounds great, Steve Klabnik's endorsement is very convincing, and I would probably love it, but here's the issue: I've used git for 17 years and have internalized its idiosyncracies sufficiently to practically never run into problems, and help anyone on my team who does.

jj is harder to adopt for people with a thorough mental model of git, because it's harder to accept jj commands at face value. I know it's modifying my git tree, so I feel compelled to grok exactly what it's doing, but that's distracting and time consuming.

People like me should probably trial jj exclusively for two weeks, to shed that antijjotic resistance and form a more clear-headed opinion.

It's not a trick or workaround. It's a very straightforward use of a command flag on one of the most used git commands. It's even conceptually very simple, you're just rebasing a subset of commits of a branch onto a different parent. Anyone who has ever rebased already has a working mental model of this operation. Framing this issue where knowing a single flag on a command every git user uses every day to perform an operation they already broadly understand as some arcane knowledge and 'nonsense' is ridiculous.

> introduces some mental friction in walking away???

I don't think it's just mental friction. Suppose you've learned git well enough that everything you do in it is automatic and fast, and the things which aren't fast by default you've built aliases and tooling for over the years. Yes, starting from ground zero you might want something like jj, but at the current point in your life you're not starting from ground zero. Switching to jj means learning another tool to achieve similar outcomes on your workflows.

There is also mental friction with learning an entirely new tool. `jj` is different enough from `git` that one can't transfer knowledge. Currently the documentation is not good enough to assuage that issue.

For me, the answer is stgit. https://stacked-git.github.io/

For me the answer is lazygit. I rarely use the git cli. I don't want to learn the jj cli and the TUI wrappers for jj seem less polished.

I have one and a half decades of muscle memory burned in with inoremap jj <Esc>`^

It's not something I can just shift away from.

Wish i could remember my issues with jj. I tried it, i wanted to stick with it because i loved the fact that i could reorder commits while deferring the actual conflicts.. but something eventually prevented me from switching. Searching my slack history where i talked about this with a coworker who actually used jj:

1. I had quite a bit of trouble figuring out a workflow for branches. Since my companies unit of work is the branch, with specifically named branches, my `jj ls` was confusing as hell.

`jj st` might have helped a bit, but there were scenarios where creating an commit would abandon the branch... if i'm reading my post history correctly. My coworker who was more familiar explained my jj problems away with "definitely pre-release software", so at the time neither of us were aware of a workflow which considered branches more core.

Fwiw, I don't even remember when the jj workflow had branches come into play.. but i was not happy with the UX around branches.

2. iirc i didn't like how it auto stashed/committed things. I found random `dbg!` statements could slip in more easily and i had to be on guard about what is committed, since everything just auto pushed. My normal workflow has me purposefully stashing chunks when i'm satisfied with them, and i use that as the visual metric. That felt less solid with jj.

Please take this with a huge grain of salt, this is 10 month old memory i scavenged from slack history. Plus as my coworker was saying, jj was changing a lot.. so maybe my issues are less relevant now? Or just flat out wrong, but nonetheless i bounced off of jj despite wanting to stick with it.

jj does not support git submodules, this precludes even a casual use on my own personal repo.

> why not just use jj

1. It's very new; I haven't had time to learn it properly yet.

2. It's very new and tooling doesn't support it well, e.g. VSCode. There aren't many GUIs yet.

3. I tried it once co-locating with Git and you definitely can't use both at the same time, even if it can use a `.git` directory. It ended up in a huge mess.

I'm definitely in favour of better-than-Git alternatives but I don't think it's reasonable to expect everyone to switch to JJ right now. It isn't so much better that abandoning the de facto standard is obviously worth it yet. (In contrast to things like the iPhone, Rust, SSDs, etc.).

Also I really wish they would focus on some of the bigger pain points of Git. I can deal with rebasing and whatnot. Sometimes it's painful but it's usually not that bad.

What I can't deal with are submodules and LFS. Both are awful and fixing them properly requires fundamental changes to the VCS which aren't going to happen in Git. JJ has an opportunity to do that. Imagine if JJ could say "we have submodules but they aren't awful!" or "you can check in large files!". Those are the sort of huge advantages that would mean you can say "why not just use JJ".

It’s a bit like qwertz. Sure, it is not optimal, there are better alternatives available. But it is good enough, and it is universal. That trumps a 5% typing improvement on my own custom keyboard layout at the cost of not being able to use my coworkers keyboard.

Also, I dislike all of the alternate git frontends I tried, because they are opinionated in a way they clash with my workflow.

Moreover, I don’t think the git CLI is that bad. Once you learn some basic concepts, it makes a lot of sense and is pretty consistent.

Most problems people report stem from a refusal to learn the underlying structure and models. That is on them. And when using a different frontend, they don’t disappear either. They are just abstracted, to allow you to avoid learning them. But they are still there, and you will probably still need to know them at some point.