Hrm… It looks interesting but it seems too dedicated to crafting “the perfect commit”.

Changing our description changed the commit ID! This is why we have both IDs: the change ID has not changed, but the commit ID has. This allows us to evolve our commit over time, but still have a stable way to refer to all versions of it.

I don’t want to “evolve a commit” - I want to capture my changes over time. If I decide later that I want to prepare the commit for merging I will.

I hate it because it’s different - but even trying to give it a “benefit of the doubt” I really can’t see this as better. It’s not like it’s difficult to create a “tidy” commit with git as is.

And as far as “easier to use goes”… well… Here’s how you get a list of anonymous branches

jj log -r 'heads(all())'

And since they eschew branches with names you get to memorize hash strings instead of branch names that describe the thing you were doing?

jj new pzoqtwuv yykpmnuq -m "merge better documentation"
# vs. 
git merge my_branch_Name

I’m unconvinced. Though jj undo looks neat (and also crazy dangerous unless you can undo an undo?).