[mwcz]

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.

[stouset]

> jj is harder to adopt for people with a thorough mental model of git

No, it really isn’t. I have used git since shortly after it was first released and I’ve written a git implementation.

I switched to jj in one day. And the amount of git arcana I have to keep in working memory is now basically nil. My VCS now works in almost a 1:1 mapping with how my brain wants to interact with my repo rather than having to go through a translation layer.

If you understand what git commands are doing, what jj does is essentially trivial to add to your mental model.

I also get the benefit of being able to use workflows that I always want to use in git but which are an enormous pain in practice. And I get access to wildly powerful new workflows I didn’t even consider because they would be outlandish in git.

[steveklabnik]

Glad you like that I like it!

What I will say is this: there is certainly an adjustment period, and I also totally hear you about how learning internals can be time consuming.

I think you can get a lot of the way there with at least the core concept with something like this, if you'll indulge me:

With git, you build up stuff on your filesystem. You then select which bits go into a diff in your index, and then when you're done, you stamp out a commit.

With jj, you instead start by creating a commit. In this case, it's empty. Then, every time you run a jj command, it does a snapshot, and this produces a new commit. However, because we want to have a stable identifier for a commit, we introduce a new one: the change id. This is basically an alias for the latest commit snapshot that was made. Your git history is just made up of each of these latest commits for each change.

... does that make any sense? Obviously there's more to all of the features than this, but that's sort of the core way that the histories map to each other.

[Valodim]

I was in the same position. Then I tried jj. I knew within the day that I wouldn't switch back.