jj describe gives a name to a commit. In jj, everything rewrites the history, so there's no real point in calling it out in the command name since it's just the default behavior.
It's not true, in that sense. Commits in jj are basically the same as commits in git as far as mutability is concerned. But in jj you normally work with changes, rather than commits, and open changes are mutable (by altering which immutable commit they point to in the backing store). And there is effectively an append-only audit trail of these alterations (which is what makes `jj undo`/`jj redo` simple).
Some comments here are confusing the issue by saying ‘commit’ when they mean ‘change’ in the jj sense.
Re the grandparent comment, `jj describe` provides a change description, analogous to `git commit --amend --edit` in git terms.
it is true. some history is marked immutable by default; in git, everything is mutable by default and you have to add branch protection on the server side. (granted, you can change what is immutable in jj relatively easily, so you shouldn't ignore branch protection if you're using jj exclusively with a git repo, either.)
describe is also the command you can use to edit the commit message of the change you're currently drafting. In jj there's no staging area, every modification to the working tree immediately gets integrated into the current commit. (This means if you have no diff in your working tree, you're actually on an empty commit.)
Not really familiar too, but jj has everything committed by default (no index, staging area, and uncommitted changes). You use ‘jj new’ to stop adding changes to the current commit.
‘jj describe’ lets you add a message to a commit as it’s not there by default.