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.
I have to work with Gerrit, which requires amending existing commits after they’ve been pushed to the remote branch to address comments. I’ll frequently have lots of commits I’m working on above the commit in review. Along with a couple other branches. Every commit also has to compile and pass tests. I’ll frequently go git rebase -i --autosquash paired with git fixup. I’ve made mistakes before that are hard to untangle. With jj it’s just jj edit <change-id>.
Or if I want to insert a commit between two others it’s just jj new -A <change-id> to create a new commit after the change id (but BEFORE the previous change that was after the commit). With git I’d need to commit then rebase, put it in the right slot and recompile, rerun tests, re-edit. If I work on a branch I’d need to rebase, possible merge conflicts. jj just puts me on that commit then helps me manage merge conflicts going up. It’s fewer commands focused on what I want to do and less on the tree like git.
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.
I’m not impressed with how they’re approaching the development. They’ve been rushing cosmic development without taking time to do some things properly. They forked iced and have a huge amount of changes. Instead of keeping the history clean they squashed their changes into a 50,000 line commit. Their compositor has no automated testing last I looked at it. Hundreds of warnings during compilation.