You don’t always need the hash id. @ is equivalent to HEAD, there’s also @- for HEAD~, @-- for HEAD~2, etc. with jj log the revset can also be a complex expression https://jj-vcs.github.io/jj/latest/revsets/. You can also create a bookmark to track a remote git branch that’s also updated when you fetch. But you have to move the bookmark when you make changes locally.

Telling people they have Stockholm syndrome is not a good way to convince them to change their behavior. Present the pros, be honest about the cons and let people make their own decisions. The jj workflow isn’t for everyone, and sometimes people’s git workflows are simple enough that there isn’t a benefit to learning a new tool. I like jj because I have to deal with complicated workflows for work and jj makes them much easier. At a different job it was much simpler and I wouldn’t have paid too much attention to jj.

Jj’s closest equivalent of branches are bookmarks, but they don’t auto update when you pull from a remote. I wish it was more like a git branch in that sense.

However, editing past commits and reorganizing the tree is MUCH easier in jj. It feels like the commands are more in line with what I want to do rather than having to figure out the specific set of git commands to do what I want.

I did find the “adding EVERYTHING” behavior to be annoying initially. My workaround was to create a local folder and add it to git ignore and push all those temp files there.

YMMV but I’ve found it much easier to manage complex workflows with jj compared to git.

You’re not wrong, but unfortunately it’s not simple and can brick your motherboard if you make a mistake. I wouldn’t expect the average Linux user to do it these days. It can also depend on the hardware. If they don’t expose any ability to change the keys you’re stuck.

From https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/signing-a-kernel-and-modules-for-secure-boot_managing-monitoring-and-updating-the-kernel: “In addition, the signed first-stage boot loader and the signed kernel include embedded Red Hat public keys. These signed executable binaries and embedded keys enable RHEL 8 to install, boot, and run with the Microsoft UEFI Secure Boot Certification Authority keys. These keys are provided by the UEFI firmware on systems that support UEFI Secure Boot.”

Basically the Microsoft keys are ones that the firmware vendor (motherboard or chip manufacturer) recognizes as secure by default (via CA validation). You can override them. It’s not a Linux issue but a hardware-vendor-defaulting-to-Microsoft issue.

My best experience was in SF on a day it was raining VERY heavily. Waymo blew me away compared to Tesla"a FSD, which would just tell you to take over in rain.