I have thought about this recently, and it feels like jj would be a lot easier to teach to new users than git.

For one, jj lets you work on things directly without having to worry about an index, while still giving you all the advantages of one if you're advanced enough to need that.

THe commands also feel a lot easier to explain than in git. For example, you use `edit` to change what commit you're working on, `restore` to copy a file from a commit to your working directory (and abandon your changes to it), and `abandon` to drop a commit completely. Meanwhile, git has `checkout`, `restore`, `switch`, `reset` and `reset --hard`, which all do various parts of one or more of these.

The one that stood out in my mind:

  `jj checkout` and `jj merge` are both deprecated; use `jj new` instead to replace both of these commands in all instances.

  Rationale: jj checkout and jj merge both implement identical functionality, which is a subset of jj new. checkout creates a new working copy commit on top of a single specified revision, i.e. with one parent. merge creates a new working copy commit on top of at least two specified revisions, i.e. with two or more parents.

  The only difference between these commands and jj new, which also creates a new working copy commit, is that new can create a working copy commit on top of any arbitrary number of revisions, so it can handle both the previous cases at once. The only actual difference between these three commands is the command syntax and their name. These names were chosen to be familiar to users of other version control systems, but we instead encourage all users to adopt jj new instead; it is more general and easier to remember than both of these.

You then add your changes and "git commit --amend".

(These could be aliases. Mine are "ci" and "ca" respectively.)

Then when you have the changes lined up you --amend that same commit.