| > Mercurial feels like it should be the winner. The commands are more uniform and predictable. Keith Packard's "Repository Formats Matter" post nicely captures how meaningless it is to focus on this sort of thing in the long term: https://keithp.com/blogs/Repository_Formats_Matter/ I.e. yes Git has some UI issues, but those are fixable, whereas e.g. Subversion's UI was way better than Git in the early days, but its repository format limitations inherently weren't fixable. > Mercurial has a concept of commit stages to make history rewriting safer. Yeah that's a really neat feature. For what it's worth some people at Google seem to be working on trying to get an equivalent feature into Git. > For example, what Facebook did[...] Much of what drove Facebook to Mercurial has since been addressed, e.g. "status" times being slow due to lack of inotify-like integration. That's now a feature of core git. Some of the rest is being worked on and actively upstreamed, e.g. from the GVFS effort: https://vfsforgit.org |
In theory, yes. However, a decade on an I'm not sure any UI issues have been fixed?
It turns out 'legacy' is a hard problem, including just for UI "porcelain". In part because people are used to what there is. (Which is a reason it's hard to get people to switch to something that isn't git either -- enough people have figured out how to do what they need with git as it is, and most people don't like having to learn new tooling).
Everyone agrees that moving from svn to git was a net positive, nobody likes svn better.
Git is pretty good.
But it's UI can be weird. And I am pretty sure if we check back in another 10 years, if people are still using git, it will be with the same basic UI model, little "fixable" will have been fixed.
Doesn't mean it'll be a disaster, we're doing okay with git. But I don't think the "UI issues are fixable" argument carries much weight here.
(Other alternatives may have been better, it can sometimes be a mystery or subject to debate why one product "wins".)