[kccqzy]

> 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.

[jdiff]

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.

[kccqzy]

Of course I use jj every day. In fact it improves on mercurial by eliminating the need to run `hg evolve` because it just auto-evolves for you.

[jdiff]

I've never had much contact with Mercurial myself, so are there any features from Mercurial that JJ doesn't already incorporate? Or any differences you find interesting?

[anal_reactor]

You mean "git tag"?

[dwattttt]

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.

[anal_reactor]

When you fix bugs, you don't edit history, you treat these as new features.

[dwattttt]

Correct. The comparable git workflow when you fix a bug is that the work goes on the branch of the feature the bug was in, and "main" is updated to use the new head of that branch.