> The tool was so correctly designed, it didn't give way for something like github to be required for it to work. You only needed someone with an IP and port, and you can get a running host. Have a team near you? Run hg serve and you can collaborate immediately.
Why would Git require "something like github" to work? You can just initialize a repository and give people access via SSH. Done. There's no need to even run a Git specific server.
> So now we are all stuck with three options: git (github), git (gitlab), and git (bitbucket). Good job, mercurial. You beat git so well, you kicked yourself out the fight.
Bitbucket supported Mercurial for a long time but the support was eventually removed because nobody was using it.
The (internal unverified Atlassian) mythos goes, that in the early days, both GitHub and Bitbucket were on equal MAU footing, but as Git mindshare started to take over, the Bitbucket founder, a Mercurial fan, dragged their feet on adding Git support. This delay lost them the war.
As a long-time Mercurial user, I'm not entirely convinced. On the one hand, Mercurial's command-line UI is so much better thought-through than git's that the comparison is ridiculous. And mercurial doesn't have an index, yay! (Okay, the ability to, on occasion, stage things is useful, but git's index usually just serves to confuse, even as someone who is also a long-time git user.)
On the other hand, Mercurial's model of the world is IMO fundamentally quite a bit worse than git's. Revision _numbers_ are obnoxious and add negative value. Mercurial's concept of branching is just plain wrong. Mercurial's mq extension is spiffy, but it's far more tedious to use than git rebase -i. Stripping mercurial repositories is a bit scary, and it solves a problem that git never had in the first place.
I appreciate mercurial existing and I think there are lots of good ideas, but I _really really really really_ like the working tree/staging area/index model of git. It works so well for allowing commits to be done cleanly, even when the initial work is likely not done that cleanly.
I don't fully believe this, but I kind of believe that having the staging model is what allows git to be very good at modelling almost anything nicely. New workflows can be easily rolled out because we have this phase separation between committing and simply staging.
And just as a general thing, `git add -p` totally made me a better developer overnight, at least in terms of actually rereading my changes seriously (and fixing them up etc). The model isn't necessary to this kind of workflow but it helps!
> I appreciate mercurial existing and I think there are lots of good ideas, but I _really really really really_ like the working tree/staging area/index model of git.
> Git is the only DistributedSCM that exposes the concept of index or staging area. The others may implement and hide it, but in no other case is the user aware or has to deal with it.
> Mercurial's rough equivalent is the DirState, which controls working copy status information to determine the files to be included in the next commit. But in any case, this file is handled automatically. Additionally, it is possible to be more selective at commit time either by specifying the files you want to commit on the command line or by using hg commit --interactive.
[…]
> If you need the index, you can gain its behavior (with many additional options) with mercurial queues (MQ). Simple addition of changes to the index can be imitated by just building up a commit with hg commit --amend (optionally with --secret, see phases).
Oh, to be clear, I’m a huge fan of git add -p. I also use TortoiseHG’s equivalent feature.
What I don’t like is that git’s index is called an index (what does “index” have to do with its usecases?) and that the index is live even when you don’t want it. It should be opt-in, not opt-out.
> I would very much like hg to have an equivalent of `git commit -p` and `git commit -v`, agreed.
See perhaps:
> ! This extensions is deprecated, the feature is now part of Mercurial core as hg commit --interactive.
> The record extension provides the record command, which may be used in lieu of commit. This command lets you choose which parts of the changes in a working directory you'd like to commit, at the granularity of patch hunks. It is similar in spirit to the darcs record command.
TortoiseHG can do this, more or less. I find that I sometimes need to click a couple times on the revision list to change the state and change it back to get the correct commit view to show up, but it usually cooperates.
> the ability to, on occasion, stage things is useful
I used Mercurial in the past and I don’t remember it lacked such a feature. I use the git stage a hundred times a day to prepare my commits, and I don’t think I could ever go back to a tool that can’t do this.
Mercurial is slow and unpopular, and it may never be made fast enough to compete with Git. I learned it once upon a time (when I barely knew Git) and thought the UI was marginally better. But now that I have used Git for a while and learned more, I think Git is way superior technologically and in terms of features.
I wouldn't fault anyone for liking Mercurial, but it definitely isn't better than Git except in giving a superficially better impression in its user interface. Once you get past initial impressions and start to do more advanced things, Mercurial sucks. There's good reasons why Mercurial fell out of favor.
Before anyone tries to say Facebook uses Mercurial, I'm just gonna point out that their VCS seems to be an entirely different implementation of Mercurial compared to what is available publicly. And even then, the tech lead on that has said recently that they have performance problems to solve. I doubt if they ever will solve those problems because they are inherent to Mercurial's implementation. Fixing it would break compatibility with old repos, and take a hell of a lot of work.
In fairness, companies with an enormous codebase have great difficulties
with git as well.
Often end up developing their own hacks around git to make it work.
> It has very intuitive verb commands that do precisely what you would believe they would do.
I love Mercurial, but I'm not sure if it's straightforward to figure out how verbs "revert", "rollback", and "backout" differ. But, when you get used to it, it's good, yes. Much easier to learn than git reset --hard HEAD^!@#$ at least.
> This is precisely the problem. The tool actually solved the problems you needed. So there just simply was no real reason why you would need to spend money on a web host or forge for mercurial.
I'm not sure I follow the argument here. The tool removes the need to spend money. So people didn't use it because they needed to spend money?
The idea is that because you could simply use open source mercurial to achieve whatever you needed, a company couldn’t build services around it and make money off of it, so there were no dollars around to promote it either and pay sales people to sell it to enterprises or sponsor GitHub conferences and hackathons, etc.
Large orgs are often biased towards spending money for things as well rather than being inclined to use free stuff like individual developers tend to.
Anecdotally I've experienced a number of times some exec has proudly announced they've paid for some commercial product for everyone to use because their salespeople have sold it as a silver bullet for some common problem, and then dev teams need to diplomatically explain that there's industry standard open source tooling that's better and nobody wants to use the commercial thing.
That's specious reasoning at best, and for multiple reasons. The bulk of software development platforms standardized and uniformly built their services on FLOSS, and version control ends up being a tiny version of the whole offering. In fact, the bulk of their business model is based on providing version control services as a loss leader, as none charge for it. They charge for ticketing, CICD, package hosting, Docker image registries, etc.
Also, some of them offerer Mercurial as well. Somehow Mercurial still failed to gain traction.
I don't think being too good is the reason it didn't beat git. I think Mercurial didn't beat git because it's only marginally better. Not nearly enough to overcome network effects, but also just not enough to make people move for personal use. It is always advertised as more intuitive, and it might be, but the list of "very intuitive verb commands" largely matches git for the most common actions.
In addition the different kinds of branches are confusing. Once you understand git branches they're simple. Once you understand Mercurial branches you understand just one of the branching models it offers. I believe "bookmarks" are the most similar to git branches, but good luck finding out about them from the website without already knowing they exist. Instead it tells you all about keeping around a bunch of copies of the source tree.
> I don't think being too good is the reason it didn't beat git. I think Mercurial didn't beat git because it's only marginally better.
I don't really agree. Mercurial was missing some critical features that were left as an afterthought, like support for stashing. It takes some rose-tainted glasses to spin Mercurial as being an all-good,no-bad tool and Git the exact opposite.
I was using Mercurial ages ago because it somewhat felt easier, but at that time I was using Tortoise* and Hg flavour was more straightforward to use that Git one (using mingw or somesuch) and my grasp of the concepts was... lacking to say the least. Fast forward and I took some time to learn git (and also migrated to mac which had great shell) and each time I had to use hg it was painful... odd concepts and it was sooo sloooooooow...
Yet another Mercurial-stan convinced of their "rightness" in the face of the overwhelming popularity of the alternative. Just blame "Github" and the "cool kids" for picking the "wrong thing".
I used Mercurial for a while when I was still also learning Git and migrating from SVN. It had serious UX problems and Git just "clicked" for me in a way that Mercurial just never did.
Perhaps I just wasn't smart enough to see the genius of Mercurial.
I also just didn't really get on with mercurial. I think while the main flow was a bit more intuitive for those coming from SVN, the underlying model was quite complex and fussy. While Git has a pretty unintuitive and hard to remember UI, the underlying model is simple enough I can basically just go "I want to manipulate the graph like X" and then figure out which command actually does it (and there is always one available, even if it's not sensibly named). With mercurial the answer usually was "Well, what you should have done was enable this extension (or worse: one of two extensions, each of which has slightly different capabilities) and configure it like so, and then do these steps. What you've got now can't be changed".
> Yet another Mercurial-stan convinced of their "rightness" in the face of the overwhelming popularity of the alternative. Just blame "Github" and the "cool kids" for picking the "wrong thing".
Any time someone complains about popularity and tries to sell rewrites in Rust as a solution to attract more users, you know right there and then what kind of delusion you're dealing with.
That was really the worst part of the post. Just the total lack of self awareness. "Look it is clearly the best tool, all we have to do is rebuild it completely from the ground up."
A general rule is that when someone clones a piece of software because the original is too hard to understand, the new software is isn’t any getter, because the authors are by definition not the brightest bulbs. That is Mercurial.
Why would Git require "something like github" to work? You can just initialize a repository and give people access via SSH. Done. There's no need to even run a Git specific server.
https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-...
> So now we are all stuck with three options: git (github), git (gitlab), and git (bitbucket). Good job, mercurial. You beat git so well, you kicked yourself out the fight.
Bitbucket supported Mercurial for a long time but the support was eventually removed because nobody was using it.
https://bitbucket.org/blog/sunsetting-mercurial-support-in-b...