Tbf you wouldn't use/switch to jj for (because of) those kind of commands, and are quite the outlier in the grand list of reasons to use jj. However the option to use the revset language in that manner is a high-ranking reason to use jj in my opinion.

The most frequent "complex" command I use is to find commits in my name that are unsigned, and then sign them (this is owing to my workflow with agents that commit on my behalf but I'm not going to give agents my private key!)

    jj log -r 'mine() & ~signed()'

    # or if yolo mode...

    jj sign -r 'mine() & ~signed()'

I hadn't even spared a moment to consider the git equivalent but I would humbly expect it to be quite obtuse.

▲ palata 8 hours ago | parent [-]

Actually, signing was one of the annoying parts of jujutsu for me: I sign with a security key, and the way jujutsu handled signing was very painful to me (I know it can be configured and I tried a few different ways, but it felt inherent to how jujutsu handles commits (revisions?)).

▲

arccy 7 hours ago | parent [-]

The only reasonable way to use signing in jj is with the sign-on-push config https://docs.jj-vcs.dev/latest/config/#automatically-signing... rather than as commits are made

▲

Zambyte 6 hours ago | parent [-]

Why? I have my signing behavior set to own and I haven't noticed any issues, but I don't actually rely on signatures for much.

▲

singron 4 hours ago | parent [-]

If you need to type in a password to unlock your keychain (e.g. default behavior for gpg-agent), then signing commits one at a time constantly is annoying.

Does "own" try to sign working copy snapshot commits too? That would greatly increase the number and frequency of signatures.

	▲	Zambyte 3 hours ago \| parent [-]
		Ah, I use my SSH key to sign my commits and I don't have a password on my SSH key. > Does "own" try to sign working copy snapshot commits too? Yes