I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable.
That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit tracks its own history through rewrites. You get cool commands like absorb and evolve. It’s easier to extend than Git.
The only downside to modern Mercurial I can think of is it’s still slower than Git, by at least a bit. But it can scale incredibly far with its extensibility. For example, what Facebook did:
So why does it never seem to get consideration? I guess it’s because of the insane proliferation of Github and Linux, which is definitely more a blessing than a curse. But it’s weird. Back in the CVS and SVN days, it didn’t seem like there was ever going to be a ‘network effect’ for source control like there is today.
I kind of wish Gitlab would implement Mercurial support. I bet it would help Mercurial gain more adoption within teams working on closed source projects. I know Bitbucket does, but to be honest that doesn’t really appeal to me much.
> I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable.
I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands.
But in the end it's deceptive; git, ugly as it is, reflects the underlying data model. Once you understand that data model, and how the basic commands manipulate that model, then it becomes a very natural language for manipulating the commit chain.
If there's a downside, it's that git doesn't let you get away for too long without learning the data model, while Mercurial lets you live in blessed ignorance until the first time it doesn't work like svn does, and then you're stuck because its data model is not as cleanly exposed, so you need to gently massage it into a good state rather than just surgically moving it to where you want it to be.
Even if you understand the data model perfectly, git still has terrible UX. reset can do 3 different things, a "remote" can mean 3 different things depending on context... I could go on all day. Just the fact that there are parodies of git man pages should drive the point home. (Disclaimer: I love git). Oh and what the hell is 'git rerere' anyway?
It allows git to record and re-use how merge conflicts are resolved. It's an esoteric command that 9/10 users will probably never use. But if part of your day job is, say, merging your startup's[1] local development with that of an upstream project[2], you will come to love this command very very quickly.
You love git because your experience, overall, is far from terrible. It's true that there are a lot of inconsistencies to memorize, and that's a worse UX than the equivalent without those inconsistencies, but that only matters so much. We both speak English - we can cope with inconsistencies in a language.
I don't love Git because it’s got a great UX. I love Git because of what can be done once you get past the awful UX.
The first year or two of Git usage ended in many, many incidents of lost work. That is not good UX for source control, its the most catastrophic UX imaginable for something designed to track source changes...
That’s why the site this post is about exists. If you don’t know about reflog, you are severely disadvantaged... and many of my coworkers at my previous employer certainly did not.
I guess I'm arguing that UX extends beyond command names and learning curves (while definitely incorporating those things). I'm on-board with the notion that there are aspects of git's UX that are terrible. But as a user, if your experience was awful, you would not love the software.
I mean, once you’ve gotten used to a given interface over years and years of practice, it’s obviously going to be a better experience for you. I practically have Git muscle memory at this point, to the point where I frequently type Git commands in Mercurial repositories.
I guess the real point is, just because we, who are experienced with Git, now have a good experience with Git, does that mean Git UX is good? I’d argue no. Bad UX doesn’t usually make software unusable or even unproductive necessarily, in my experience it usually means something more along the lines of, it’s unintuitive and confusing, and takes much more time to learn.
A good example would be something like Blender, especially pre-2.8. Is it bad? No! It’s good software. Is it good from a UX perspective? Well, it has unfamiliar paradigms and it tends to confuse people, so I would say no, and that’s why they’re trying to improve it.
In fairness, Git has done many small things over the years to improve its user experience and to reduce instances of data loss. But Facebook’s chistedit vs rebase -i is a pretty great example of UX differences imo. Git could catch up easily in some of these aspects.
"It takes more time to learn" is an important aspect of UX, and as I've said there are clearly ways in which the git UX can be improved.
But having said that, I really feel like the experience of expert users also matters and is often overlooked in discussions of UX. And I just don't think people love software when their experience using it is terrible.
I've heard this repeated a lot but honestly find it very untrue. I understand git internals and watched half a dozen talks on hit but still have to Google how to split a commit in two or how to safely rebase vs merge when I'm dealing with too many conflicts in my rebases. How to accept their or my commits during a merge or rebase so I can skip conflict resolution, how to do X or Y. It's just bad UX. It's okay! I don't blame the tool but repeating "it's fine if you understand how it works" doesn't help, it perpetuates the idea that this bad UX is somehow good
No, I strongly disagree. Exposing the datamodel can be part of an excellent user experience if your target audience are programmers, as is the case with git. Where git goes wrong is numerous commands that do numerous very different things if given different flags. That has nothing to do with the underlying datamodel being exposed; it's just sloppy planning and design. That part is terrible UX.
Perhaps, but speaking personally, that doesn't matter much to me. What matters to me is how much easier a tool makes my job, and of all the version control systems I've used, git is easily the winner.
And I don't want to say that Git isn't an improvement over many other version control systems.
But, IMO, the real sea change there is the shift to a DVCS, and not Git's interface. Within the set of DVCS that I've used, I find Git to be easily the most difficult to understand and work with, and the one where I have to spend the most time reading and grokking abstruse explanations of the tool's implementation details in order to figure out how to deal with some edge case.
I don't think that I'm the only one. My sense is that people whose only DVCS is git are much more likely to love it unconditionally than people who came to git after having first spent significant time on some other DVCS. For my part, as another concrete example, I have to spend a lot more time helping junior devs with source control snafus now that I'm at a Git shop than I did when I was at a Hg shop.
In summary, "Sure it's easy to use, you just have to read this lengthy explanation of its implementation details first," isn't really a compelling argument when you know that there are other competing products that are easy to use even if you didn't spend that much time on RTFM first.
Fair enough. I won't say git's UI is intuitive -- it's not. But once I crested the learning curve, I do prefer it over the alternatives I'm familiar with. When I need to do something unusual, I have better luck figuring out how with git than the others.
That said, I am not familiar with most of the various version control systems out there, and I could easily be missing something that's genuinely better.
I don't get that argument at all. I came from svn, used cvs and ss and I think I even tried to use Perforce at some point.
I don't see how people consider mercurial "easier", "the winner" or whatever.
I think it's like languages: if you're a french speaker and you translate everything into your native tongue while learning, then of course you won't ever get past roman languages. It's just different.
`git add -p` is my absolute favorite command ever. `tig` is just awesome. The gui clients are so beautiful and take away all the so called uglyness nowadays, though I just can't find myself using anything over git add -p. Nothing in mercurials commandline ever came close to these two. But yeah tig isn't really part of git but at the same time it's been around for so long it might as well be.
The man page for git reset states in its first paragraph:
> In the first and second form, copy entries from <tree-ish> to the index. In the third form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match.
When your documentation starts by saying (in effect) "this command does several different things", that should be a very strong sign that your command UX has some issues.
The Emacs magit status view has an even better version of git add -p: you can hit tab to expand and collapse diffs of files and hunks in the unstaged and staged changes, selectively s (stage) or u (unstage) everything or a file or a hunk. To split a hunk, highlight the relevant part with shift+arrows then hit s or u. It’s brilliant!
It doesn't matter if you've learned git's data model or not; its use of terminology is inconsistent and confusing, and its command interface is disorganized and asymmetrical. In that way, I suppose it is very much like a "natural language", and not like the sorts of languages we are more accustomed to using when getting things done. Even if I know exactly what I want to do to the data structure git is managing, that doesn't help me find the commands I need to type to accomplish it. I have been using git for ten years now and I still have to rely on rote memorization of specific recipes in order to get anything done, which sucks because I am terrible at rote memorization.
Hg and git have near feature parity, so I don't really lament Hg's loss so much. Sure Hg's CLI is a little bit better, but beyond that it never really offered any really compelling features over git. Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing.
Fossil is another matter. Fossil defies pithy car analogies. Integrating the bug tracker into the version control alone is a game changer, and that's not even all that Fossil does.
Hg actually does go beyond Git in many areas; I did outline a few but my favorites are the improved commit model (stages, natural branching, rewrite tracking,) the commands Git doesn’t have (absorb, evolve,) and the extensibility (see Facebook extensions.)
Sure, the model is similar and Fossil is different. But that is kind of an important note. If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems.
In most setups, the bug tracker and source control are separate, but that doesn’t mean you can’t get bugtracking alongside code either, GitLab provides everything from bugtracking to CI to deploying stuff to Kubernetes.
Not to say Fossil isn’t cool or doesn’t have its place, but if I disagree with the philosophy (and I do, fundamentally,) then I don’t feel like I lose much using alternative software suites.
> If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems.
Or Fossil provides a superset of the others. Like comparing a corkscrew, which only opens bottles of wine, to a swiss army knife that has a corkscrew. They both solve the same problem, but one of them also solves other problems and is generally a more useful tool to keep around in your pocket.
The world didn't lose much with Hg losing to git. But with Fossil losing, we lost a great deal. As a consequence we have a world where people feel locked into the proprietary bug trackers their git host provides. Had Hg prevailed, that situation would be no different. The only way the world would be different if Hg had prevailed would be fewer posts on HN whining about git's interface being obtuse. Not really a substantially different reality, is it?
I don’t think people feel locked into proprietary bug tracking, they just choose it out of convenience. You can export data from Github or Gitlab.
I mean hell, trac and redmine have been around forever now. Is an open source wiki+bugtracker that revolutionary?
My best guess is that there’s some benefit of merging the source control in, but I’m not sure; it’s not like other environments can’t provide integrated bug tracking.
From my perspective, your last sentence is the wrong way around. It's not merging the source control into bug tracking, it's merging bug tracking into distributed source control.
The issue that Fossil addresses from my perspective is the integration of bug/issue tracking and the VCS. The trouble with using Git{hub,lab} or other issue tracking is that the issue control isn't distributed in the same way as the source control is.
I want to be able to do a code review, deal with an issue, make changes to source, test etc offline/on a branch and then push all of the changes/impacts (source, issue, comments etc) for distribution to other developers.
I hate (or at least am annoyed by) dealing with source control, although I acknowledge the need for it.
So does the analogy still fit? And which one is better for people that are merely putting up with the necessity for source control rather than enthusiasts?
My personal preference is for Honda as well, but when you sit down in the drivers seat and survey what is in front of you in a Honda or a Toyota, you'll find they have more or less the same things. Perhaps Hondas being set up to be more agreeable to "car guys" is similar to the CLI of Hg not being so obtuse, but both are still nevertheless capable of more or less the same feats. They'll both see you through your commute and either is a bad choice for off-roading.
Driving a Toyota feels like a game/toy. Which puts me on edge, because I feel detached from what the car is actually doing. The handling feels.... too smooth.
Personal attacks will get you banned here. Would you mind reviewing the site guidelines and taking the spirit of this site more to heart? We've had to ask you this before.
If someone is wrong and you know more, reply with some of what you know, so we can all learn. If you don't want to, that's fine, but in that case please don't post anything.
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
> I.e. yes Git has some UI issues, but those are fixable
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".)
There's definitely been a lot of UI fixes in the Git command-line client. I know because I wrote some small number of those patches.
There's also cases where Git's was and still is top-notch, e.g. in the use of terminal colors by default, and opening a pager for you smartly. Both of those were cases where Mercurial trailed behind for a while, although I think now it's caught up in that area.
I concede that Git's command-line UI still sucks in a lot of areas.
What I was pointing out with the "Repository Formats" reference is that one shouldn't conflate deficiencies in the underlying formats with UI deficiencies.
The latter is easy to fix, and the git command-line client doesn't have a monopoly on fixing those things. There's plenty of other top-notch UIs for Git. E.g. Emacs's Magit, and GUI clients like GitKraken, Sublime Merge etc.
Whereas the inverse isn't true. You can't really build a client like Magit on top of CVS.
I'm not saying it won't, just that transitory UI issues are unlikely to drive a mass exodus from one source control system to another.
To reference a reply of mine to your sibling comment[1], it would have been like going through a lot of trouble to move from Mercurial to Git some years ago just because Mercurial's terminal UI didn't use coloring.
I'm an early git contributor and long time user. At the time I picked it up, I was following and using hg as well.
I found git easier to learn and use. Git has just a few basic concepts underlying how it works. Once I learned blobs, trees, commits, the index, and references (branches, tags, reflog, etc), I understood the model. It wasn't hard to grok a local vs remote repo, how history was a dag, and so forth. From there, I realized all the crazy commands, the baroque UI, these were all just ways of manipulating those objects in various ways. I could always figure out how to make git do what I wanted. It never fought me or tried to tell me I couldn't do something.
hg, by contrast, I felt was always trying to hold my hand. Its model was harder to understand. It required me to adapt to its workflow, instead of allowing me to adapt it to mine. It was generally much less flexible.
I found everything about git more Unix-philosophy like.
I understand completely if you don't want to think about your VCS and just want it to record your changes and otherwise get out of your way, but I wanted a more flexible and powerful tool.
> I kind of wish Gitlab would implement Mercurial support. I bet it would help Mercurial gain more adoption within teams working on closed source projects. I know Bitbucket does, but to be honest that doesn’t really appeal to me much.
When i started using version control for my plain text notes, I initially settled on Mercurial (because of it's supposed better support for Windows), but turns out it doesn't support unicode filenames while git does. So I went with git.
I used Mercurial exclusively for a long time. I reluctantly switched to Git when it became obvious Github was the place to be if you wanted your open-source project to get any attention.
I think the way forward for Mercurial would be to become a Git frontend, or "porcelain" as they call it. That way we would get the best of both worlds: the ubiquitous git format and hosting infrastructure; and the superior UI and workflow of Mercurial. I'm sure it would be a difficult undertaking, and might require difficult trade offs between compatibility, performance and usability. But I think it would be worth it. For one, Mercurial would become relevant again, and probably get a lot of new users. A lot of users would probably come back. And Git users would also benefit from the renewed competition between competing frontends.
> I kind of wish GitLab would implement Mercurial support
Hi! GitLab employee here. Mercurial support has been a hot-ish topic internally. If you want to weigh in then please comment on this Issue, since Issue interaction plays a big part of how we prioritize
https://gitlab.com/gitlab-org/gitlab-ce/issues/31600
(edit: I'm an idiot I should've read the full thread first since someone already linked it. gonna leave it up anyway)
Yep, mercurial really is better, but it is also noticeably slower. I used git for about a decade, and now use hg at my job. Recently, I used used git again while playing around with something over a weekend. I instantly remembered why I loved it so much. There is really something to be said for commands resolving practically before you have noticed you pressed enter. I wonder if this is inherent or accidental; I don't know the mercurial data model well enough to understand why it would be necessarily laggier.
Git won because it was a) unopinionated and b) powerful enough to support arbitrary workflows for any enterprise.
For the enterprise, being 'uniform and predictable' is way, way, way down lower on the list of important criteria in version control. (And in fact may even be a negative, due to the weird legacy workflows many enterprises have.)
That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit tracks its own history through rewrites. You get cool commands like absorb and evolve. It’s easier to extend than Git.
The only downside to modern Mercurial I can think of is it’s still slower than Git, by at least a bit. But it can scale incredibly far with its extensibility. For example, what Facebook did:
https://code.fb.com/core-data/scaling-mercurial-at-facebook/
So why does it never seem to get consideration? I guess it’s because of the insane proliferation of Github and Linux, which is definitely more a blessing than a curse. But it’s weird. Back in the CVS and SVN days, it didn’t seem like there was ever going to be a ‘network effect’ for source control like there is today.
I kind of wish Gitlab would implement Mercurial support. I bet it would help Mercurial gain more adoption within teams working on closed source projects. I know Bitbucket does, but to be honest that doesn’t really appeal to me much.