Same experience. At first I really didn’t get it and now I could never go back. The ease of rebasing, renaming, reordering, splitting, etc. Has drastically changed the way I work. My PRs are undoubtably much better now, and I am never afraid of messing up thanks to jj undo and the op log in general

Do you have a public example of an open source project that you are using that showcases those features?

In your opinion, is jj losing steam? How do you feel about it requiring a CLA to contribute to, which would enable the developers to go closed-source and keep all the contributions of the community? Are you afraid of vendor lock-in?

> a public example of an open source project that you are using that showcases those features?

IMO that's almost fundamentally impossible. The whole point is that it makes maintaining a "clean" linear commit history easier than git, so by the time you push anything the observable differences are already gone. At best you just see a repo without any WIP-style commits, which can be done using more effort and git alone.

IIUC, "@--+::" should read "all descendants of the children of the grandparents of the current commit".

Or if it were a family tree, "all descendants of your parents and their cousins" (ignoring that family trees are way more constrained than DAGs).

I have no idea why you would use that revset; I assumed it was just an example of revset's complexity and power.

As a pragmatic matter, unless I'm scripting with revsets, I personally stick to a few go-to aliases.

They're not experienced with git, but still use the command-line? Interesting. Or would you think a jj GUI would help them?

CLI is preferred from my point of view if only because it's the supported standard interface. VSCode's version control interface is reasonably close to a standard, and I love the tree view there. But generally I don't want to use random third party things because they either aren't consistent (i.e. now I have to learn what joe schmoe thinks a version control interface should be), or don't stick around long enough.

But I don't tell my team what they have to use as long as it's compatible. The last thing I want to do is try to teach them a different VCS when they've spent time learning how to get by with git.

I've told them about JJ, what I like, what pain points it solves for me. They are all adults, they can make their own decisions about it.

JJ is for me. It helps me unwind some rather elaborate problems we've had with rebasing, or dealing with conflicts from bringing some old support branch up to date, or back porting some particular thing. It helps me create pretty clean MRs, break things up into smaller reviewable chunks, etc. You can do all this with git, but it's easier in JJ. In particular if you have to do shuffling and rebasing and conflict arise. JJ lets you solve conflicts asynchronously to rebasing. Git stops you in your tracks. There's some rerere thing that is supposed to help but give me a break. Git's a train wreck of dumpster fires. But it's still been basically better than everything else since svn.

Until JJ IMHO. Valid arguments can be made for other things like maybe mercurial or even fossil. But JJ is the most pain-free vcs evolution I've seen.

Mercurial's big failing was making too many critical things optional. It's the same screw-up riscv is going through now in the chip architecture space.

isn't that what protected branches etc are supposed to fix in platforms like GitLab/GitHub/etc? My team has yet to break any important branches