Yeah they copied it. They copied it because it was better. Do you think that they copied it because it was a bad UI idea? Not sure what your point is.

And great question about the Git model, after mentioning 'phases'! Mercurial has about a billion concepts and nouns for different random things like that. It takes forever to explain all the random ideas they've piled into it in an attempt to keep up with Git.

Mercurial think they can fix everything with yet another plugin and new concepts and nouns. Git built a cleaner model where you don’t need these plugins and abstractions.

How does Mercurial feel like "it wants to just make a literal log of what I've done"? It has a UI very similar to Git's for rewriting history and a feature specifically to help do it safely.

Git copied things from Mercurial too. I don't think Git having a feature Mercurial didn't in 2007 means "Git turned out to have the better UI and architecture".

Git still has the problem Mercurial phases address.

A lot of Git users are annoyed that Mercurial branches work like other systems instead of Git and that it calls Git branches "bookmarks". New users understand Mercurial branches much more easily in my experience.

Mercurial queues are complex but only needed for workflows Git doesn't support. They're an extension so that most people don't even need to know they exist.

Do you have any other examples?

> How does Mercurial feel like "it wants to just make a literal log of what I've done"?

Because rebasing was literally an afterthought - a plugin. I don't think I ever push commits without rebasing them a few times. There's also now about six different ways to rewrite your history in Mercurial. It's a mess. Git has one way to do it and it's a normal part of the system.

If a Mercurial user asks me how to tidy up their history my answer is 'er... well there's rebase, mq, histedit, evolve...' that's a lot of options to teach people. In Git I just show them rebase.

It's all subjective isn't it? For me, less concepts, nouns, and plugins adds up to a simpler and so better architecture and UI. Maybe the extra concepts are what floats your boat and that's fine.

> Because rebasing was literally an afterthought - a plugin

Hg extensions are just as much part of hg as the core functionality. It's just that they're opt-in parts many users don't need and thus don't have to see. If your workflow requires history editing, then fine, enable rebase and histedit.

As for mq, I think I've only used it in a script where I converted an ancient CVS repo and rewrote entire parts of the history to remove stuff that should never have been in there to begin with. It's powerful, but rarely required by anyone, and thus is opt-in as well.