> How do you consider the UX "nearly identical" or "arguably worse"?
The core concept is similar -- history is a stream of content-addressed commits. Concepts map almost 1:1. git does some things arguably better.
> hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively.
hg histedit is basically identical to git rebase -i. The names are different, but the operations end up being more or less the same. hg amend -> git commit --amend. Graft -> cherry-pick.
> I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times.
I don't know what to tell you. I've also worked with Mercurial for 5+ years, but I've never rm -rf'd a git repo.
> 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.
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.
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?
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.
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.
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.
I don't know what version of hg you're using, but the histedit I've used drops me into an identical text editing setup as git rebase -i. It includes a summary of what the verbs mean in a comment at the bottom.
Interesting. The curses interface for histedit has been around since 2019, and I had no idea it wasn't the default since it's dramatically nicer to work with: https://www.mercurial-scm.org/relnotes/4.9
The core concept is similar -- history is a stream of content-addressed commits. Concepts map almost 1:1. git does some things arguably better.
> hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively.
hg histedit is basically identical to git rebase -i. The names are different, but the operations end up being more or less the same. hg amend -> git commit --amend. Graft -> cherry-pick.
> I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times.
I don't know what to tell you. I've also worked with Mercurial for 5+ years, but I've never rm -rf'd a git repo.