upvote
> history is a stream of content-addressed commits

Not quite true for mercurial. You also get stable identifiers for commits that remain the same even after being manipulated such as after rebases or amends. It also enables tracking the evolution of a changeset which then enables `hg evolve`.

Being content addressable isn’t a desirable feature in a user-friendly version control system. Who cares about it? Giving stable identifiers to commits is a much more needed feature.

reply
Have you used Jujutsu before? It's git-backed and it sounds like it incorporates a lot of these niceties from Mercurial. I find it an awful lot more intuitive than Git to use and the stable identifiers are absolutely lovely to have.
reply
You mean "git tag"?
reply
If you tag every commit, sure. You don't know which commit has a bug that needs to be fixed in advance. And at the point you're tagging every commit, you're fighting git.

EDIT: reconsidering: you would have to move a tag when you make changes. A tag is just giving a name to a commit, not a stable identifier that follows a change. A branch is a more appropriate analogy.

A git-native workflow for this would be to have a sequence of branches you continue to update, where 'main' is those branches merged at all times.

reply
git rebase -i drops you into a text editor where you have to manually copy, move, and edit lines, knowing what words mean what and manually type them each time.

hg histedit gives you a TUI which shows an interactive list and allows quick manipulation with the arrow keys and single characters for actions.

The two are as "equivalent" as i3 and KDE.

reply