[incognito124]

I spoke about this before, but jj has the Blub Paradox problem, from the pg's essay Beating the Averages (https://paulgraham.com/avg.html).

Yes, you can do most commit manipulations with git just like with jj. But, users of jj know they're "looking down the power continuum" (to reuse pg's terminology) when they look at git, whereas git users cannot fathom what's exactly the deal with jj. Unfortunately, the only way to get it is to spend a week with it, with an open mind. It's close to impossible to describe it except "it's really neat" and "wow it removes all git's friction I didn't know existed".

And, apparently, there's a pattern of having to try at least two times before it becomes intuitive!

[bsder]

> I spoke about this before, but jj has the Blub Paradox problem

It's not relevant. Don't try to convert git users--you don't need to. They're fine doing what they do, and the git backend store is acceptable. People who understand how broken git is will gravitate to jj with the lightest of prodding--give them a light poke and then don't harass them further.

The main difference is that I can teach jj (like I could teach hg) to normal people. And, because jj is based on the git store, they can operate in a Github world.

So, just teach jj to people who haven't yet broken their brain with git. Running on the git backend already gains most of the network effect, so don't proselytize the git people.

[hooper]

It's interesting that even clear advantages like `jj undo` are hard to communicate because of this.

[ruszki]

The problem with this mindset, that there is zero reason to move away from Git. I can do effortlessly everything with it. There is no incentive. I never said "it would be so good that I would be able to X"... and I didn't find a solution for it quickly. As under this post is obvious as much as under other previous posts, you can do the same things effortlessly with Git. The effort is not that I need to use 2 commands less, but to separate the code (in this specific case), which takes about a 100-1000x more time than typing those 2 extra commands, or really the need to think what kind of commands need to be used in any VCS.

The same problem with vi for example. Which I learned, deeply and for a long time. Maybe I will be break even in a decade or two. And for example, I can code faster than anybody who I know and use vi all the time (or some vi keyset in Emacs or something), not because I type faster, but because I don't need to rewrite my code that many times than them.

The same with jj. I'm happy that it clicks better than Git for some. But I know Git from inside and out. Git was never the bottleneck for me. And really any VCS in the past. If I learn jj, then I don't expect that the effort pays off in a decade or less in the best case. My work's result would be the exact same thing, just with different commands, commands which takes almost no time compared to my other tasks.

[skydhash]

> Unfortunately, the only way to get it is to spend a week with it, with an open mind

We do get it. But have you ever thought that git inflexible nature and full control is what some people people like?

Having three different state for your work (working tree, staging, and committed) is nice for reviewing code. Picking lines and chunk give me an additional mental state to think about the design of the code.

And once upon a time, I preferred history log like the one in the article. But this days (mostly inspired by mailing list development style) I wants the commit in my main log to be either features or bug fixes. Everything else is “wip”, which I will squash. It makes it easier when rewriting history, cherry picking, or just browsing the log.

[jolux]

There’s nothing stopping you from using separate changes to emulate the staging area if you want.

[entrope]

That is, in essence, the "squash workflow": https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...

The big differences are that the jj approach gives you a commit message for the staging change, and lets you jump to some other commit without extra steps.

[skydhash]

I can, but I don’t need to.

jj has nothing I need, so it would be changes for the sake of changes. I’m not saying it’s bad, but people do need to realize that their struggles are theirs, not the whole world.

[sswatson]

Not trying to tell you how to live your life, obviously, but I think “changes for the sake of changes” overstates it. For example, `jj undo` is a pure ergonomics win.

It’s been said a million times but it is really true that jujutsu’s appeal is something you feel (or don’t) after giving it a proper go. It doesn’t survive compression into the feature list.

Actually I think that property is a much bigger obstacle to adoption than what it does or doesn’t offer to the rare true git wizard.

[skydhash]

I use magit on a daily basis. And I do use tig occasionally (I don't like lazygit). Most of my magit workflows only requires a handful of keys (most are only two keys). If you've not tried Magit before, it's like vim for a git repo. tig is more barebones, but I could quickly configure it to be able to do most of the magit tricks I need.

Git cli is tedious. But like all cli operations the goal is always to script your workflow or alias the most used commands in something shorter. I'm sure that jj may have an easier learning curve. But some people do know how git works and like the level of control over commits.

[sswatson]

I’ve never used magit but my impression is that it’s similar to jj in the sense that it smooths out git’s rough edges in an elegant way and in the sense that it’s hard to properly appreciate without using it.

That being said, I also much prefer a UI layer (lazygit originally, now lazyjj), and personally I find the benefits of jj to be partly complementary to the UI ones.

That is, after getting used to jj, my problems with git are (1) the CLI ergonomics, and (2) the model is actually more complex than it needs to be, in a way that materially diminishes my experience. Only the first is addressed by lazygit (though maybe magit does both; not sure).

One other point: jj doesn’t actually impose a level-of-control tradeoff on the curation of commits. You can mimic the git workflow by modeling the working copy and staging area as commits (changes, in jj parlance), or you can experiment with any number of alternatives. What git gives you is the opinionated support for the working-copy-staging-area-commit approach.

[jolux]

Totally fair :) personally I used to be a git wizard and I am relieved at how much about it I’ve been able to forget since learning jj, but I understand not everyone has the same experience.