Git feels like a tool I can use to create and mould meaningful commits that best convey intent. Mercurial feels like it wants to just make a literal log of what I've done, which is a bit simplistic and isn't the same as what I want to present when my code is ready.
I also find the model of Git much easier to understand and explain to others.
What do you find easier to understand and explain about Git's model?
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.
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?
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.
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.
But git’s user experience is IMO gratuitously awful. Trying to keep track of all the various things that checkout and reset do leads mainly to frustration at the design. And I see no reason that use of the index should ever be required.
I think I have never heard that from anybody versed in git and any other distributed source control manager. Architecturally, we can look at (eg) speed performance and reasonable people could agree git leads or is a competitive contender. What UI examples is git bringing though?
I’d love to love it, but to me it feels like a UI/UX disaster, and “getting used to it” is NOT an excuse when we have mercurial or fossil showing how much better it can be.