[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.