Hacker News Reader

Comment by feoren | Hacker News Reader

I wonder if this is why Mercurial is so much simpler and easier to understand than Git -- precisely because Git was forced to adopt a more "out there" approach. Personally I'm sad Git won out over Mercurial -- the latter is a much better technology from my experience.

View on HN

> Mercurial is so much simpler and easier to understand than Git

I think it must just be a mindset thing. The way git works makes perfect sense to me and I don't know why you would do it any other way.

But git was already gaining significant traction when I started using version control.

I can see how having built your mental models around previous version control systems and then trying to superimpose that on git would cause dissonance.

But my entire concept of version control is based on how git does it, so it seems perfectly natural.

It's, of course, impossible to do a practical experiment where someone doesn't learn, and therefore become biased toward, one of them first, and then learn the other after.

For my part, what I can say is, I used Mercurial for one year, and Git almost exclusively (I do occasionally touch Subversion) for a straight decade after that. And I still find myself having to consult Git's documentation far more often than I ever did with Hg. And, even now, I find myself having to un-pick minor screw-ups in Git more often than I did after only a couple months on Mercurial.

I'm pretty sure that the problem here is ultimately the UI and not the data model. No, I'm sure it is. Every time there's a conversation about Mercurial vs Git, and someone says, "Git's not that bad, all you have to do is learn the data model, and then learn all the different ad-hoc ways the UI is bound to it," my immediate thought is, "You see, that's exactly the point. The thing that's nice about Hg is that you don't have to take this extra learning step, because the data model and the UI model are one and the same."

Also, merge conflicts seem much more common in Git. I'm not sure if that's a UI problem or a data model problem; I could see it being either or both. In any case, I felt much more comfortable allowing branches to live for days in Hg. In Git, branches that survive past 24 hours seem to always result in either shaving or getting trampled by yaks.

Underlying technology aside, mercurial has (I think) quite objectively better cli interface. All flags are the same among commands, and all commands have their undo counterparts.

> Underlying technology aside, mercurial has (I think) quite objectively better cli interface.

I disagree. The fact that mercurial relied extensively on extensions to implent basic features, thus exposing a non-standard interface to the world, made it's mental load significantly higher than simply using a standardized (albeit debatable) interface to do standard things.

Case in point: requiring installing extensions to stash local changes.

> relied extensively on extensions to implent basic features

Sorry, this is a strawman. Yes, `hg shelve` is a very nice extension. But that's about the only add-on I've ever needed, while working more than 7 years on reasonably complex projects spanning about a dozen teams, in multiple timezones and repositories. And it takes less than 5 minutes to install.

We were forced to move to Git after being acquired, and while the migration was painless, the day-to-day friction caused by Git porcelain is notably higher than with Mercurial. The issues caused by line-endings alone waste more time than all the Mercurial issues combined.

> Sorry, this is a strawman.

It really isn't,and you cannot hide Mercurial's failings by trying to move the goal post.

It's a fact that Mercurial's non-standard interface created a mental load for basic ops that is considerably higher that git's reliable and predictable (and, more importantly, learnable) interface.

> Yes, `hg shelve` is a very nice extension. But that's about the only add-on I've ever needed.

It's not a "nice extension". It's core functionality, which is a part of any basic introductory workflow.

And with mercurial instead of just being able to stash changes with a simple $ git stash , all of a sudden you need to bother with installations and setups and configs and checking if everything is it's place.

Just. To. Stash. A. Change.

And if you find stashing nothing more than "a nice extension", and nothing else pops into your mind, then you clearly have limited experience in using revision control systems.

> And it takes less than 5 minutes to install.

Did you failed to notice that it forces you to waste time ensuring you're bolting on all the stuff you need whenever you jump a seat or pop into an instance?

And did you failed to realize this problem is not experienced with pretty much any revision control system? Not just git, but pretty much all of them.

While Git is conceptually beautiful, it's CLI seems something of an afterthought and is maddeningly inconsistent at times.

As another data point, I used CVS and later SVN for years before I used git, and I find git to be incredibly easy to use and understand. But I've been using it for over a decade, and spent time in the early days to understand how it works under the hood.

This isn't to say git has a good user interface. I don't think it does. I'm comfortable with it because I've spent many years using it, and because I expended extra effort (effort I don't think an average user should have to expend) to learn it well, and to be unafraid of making mistakes while poking around.

Short of breaking backwards compatibility at this point, there’s nothing preventing Git from being as simple as Mercurial CLI-wise. The two projects are nearly identical on a high level.

I know git is confusing on the one hand, and somehow instills over-confidence on the other. But the underlying implementation of "Store everything, SHA it, and build a merkel tree" is, in my opinion, the kind of thoroughness I want in a version control system.

Reply on news.ycombinator.com