It's very sad to see bitbucket dropping mercurial support. Now only Facebook and volunteers are keeping mercurial alive.
Sometimes technically better architecture and user interface lose to a non user friendly hard solutions due to inertia of mass adoption.
So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use. GitHub successfully marketed git, so git and GitHub are synonymous for most developers. Now majority of open source projects are reliant on a single proprietary solution Github by Microsoft, for managing code and project. Can understand the difficulty of bitbucket, when Python language itself moved out of mercurial due to the same inertia.
Hopefully gitlab can come out with mercurial support to migrate projects using it from bitbucket.
For people who believe in self hosted solution can install Kallithea (https://kallithea-scm.org) or Rhodecode open source edition. Kallithea is used by Unity engine to manage their source code internally with mercurial.
I started my distributed version control journey when SVN was still king of the hill and git and mercurial were both tiny challengers.
I actually picked mercurial first. I found the interface more intuitive, especially coming from svn. The problem was that everyday commands were just dog slow -- 5, 10 seconds on every single interaction. It felt like wading through molasses, contrast to git, which was effectively instantaneous on small repos and git on my large repo was still multiples faster than hg on a small repo. Also, IIRC hg didn't have a "git stash" equivalent. I chose git on its merits and didn't look back.
A few years later (2010 ish?) I met a mercurial evangelist who said things had changed on the performance front, but I checked and they hadn't.
I'll give hg the benefit of the doubt that it eventually got better, but I have serious doubts about your accusation that git's success had to do with marketing. I gave hg a more than even chance and it lost, fair and square, on technical merit, as weighted according to my everyday use cases.
Git was once fast for my use too. Then I returned to Microsoft to work on building Windows. Even after 2.5 years of improvement,[1] "git is slow" is still one of the most common complaints about the Windows engineering system.
On my Skylake+SSD desktop, it takes over ten seconds to switch branches with git checkout, several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.
We are making many great strides here at Microsoft to improve git performance, such as with VFS for Git which my Windows repo clone uses. But with hundreds of gigabytes in a unversioned download of the source tree, there is only so much we can do.
I started with CVS then moved to svn. From there moved to bazaar (bzr), from there moved to git and at last used mercurial and settled on it. I still keep an active look at fossil SCM.
In my earlier team at fortune 100 firm, most developers use Windows with svn. We tried git and it did not work well due to UI and windows support. They were able to pick up UI easily and were quickly productive in mercurial. It worked pretty good on all 3 platform Windows, Mac and Linux. I am talking of time when GitHub was not that popular in corporate world.
Performance was never an issue.
Also at that time mercurial followed philosophy of being explicit and every merge needs to be explicit and committed with immutable history. So can see the evolution of code along with the mistakes made.
I believe the success of git is due to GitHub and for many it's synonymous.
>I'll give hg the benefit of the doubt that it eventually got better
It did not. We had a giant hg monorepo at Yandex, and even mere "hg id" took ages (and required net access to source repository for some reason). The plan was to eventually switch to it from SVN, not sure if they eventually did because I left the company.
> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use.
Marketing is often necessary to get a start, but it is rarely sufficient for a long-lasting success. The claim that "it's all marketing" is usually made by those who look at one aspect of the technical merits and miss others that turn out to be more important. Just as in the actual VHS vs. Betamax story [1]. Betamax had a slightly, almost imperceptibly better picture quality, while VHS had double the recording time of Betamax. VHS won on the technical merits as they mattered to users.
> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use.
this is an amazing opinion. Git won over mercurial because its capabilities and usage model are vastly better than that of mercurial. I had all of my projects on mercurial for many years and finally switched over to git, it was like a whole new world opened up. My daily workflows are now entirely based on concepts that are complete anathema to mercurial, where changesets are just objects that can be moved around or deleted once no longer needed, where commits to master represent complete features in a single changeset. Throwaway or hypotehtical branches are now changesets in Gerrit, rather than "feature branches" that exist forever whether or not they were used. I'm not sure if mercurial found a way to work out those problems of having zillions of little "fix typo" style commits crowding up a feature as well as zillions of dead feature branches forever crowding up the repo, but it at least was not apparent to me seven or eight years ago which would mean it's not easy to use.
> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use
The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better.
In the case of VHS vs Betamax, VHS won because it was better overall. Some people point to one or two advantages of the Betamax format, but ignore that overall it wasn't better than VHS. (Because Beta tapes were physically smaller, you were usually forced to use a slower tape speed, loosing the very minor picture quality improvement at the highest tape speed. Thus, longer prerecorded Beta movies looked worse then their VHS versions.)
The same thing is also the case with git versus Hg. I used Hg years ago because it was easier to learn; but once I learned git, I see no reason to go back to Hg. Yes, Hg has an easier learning curve, but that's one particular detail.
> The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better.
I can’t speak for all “the people”, but I disagree strongly. There are fine reasons for picking things other than git (I’ve used fossil since it’s near-inception); git’s dominance or fossil’s loss in the market does not make gits UI/UX superior. Thats like saying McDonalds is the height of cuisine, because “Billions and Billions Served”.
“One particular detail” is a gigantic understatement. Having introduced several people to git, it is uniformly awful as a tool to learn, and that bad design doesn’t go away once you memorise the basics.
Git won because it's superior in a way that many programmers think doesn't matter: performance.
Git is incredibly fast. Many operations happen almost instantaneously even on large repositories. It's really nice. I've heard a lot of people talk about how they abandoned mercurial because it's slow. Some even switched to git from svn not because git's model is better but because svn is slower.
"Premature optimization is the root of all evil" is an old programming advice quote that is so horribly misunderstood that it's basically wrong. It means think about your problem at the high (algorithm and overall goal / design space) level before worrying about low-level optimizations. It does not mean that optimization is bad or that performance isn't important.
I made another comment recently on the same issue. I really wish that quote would die in favor of more substantial advice that won't be so misunderstood.
"Premature optimization is the root of all evil" means: make it work correctly first, and then - if anybody cares - make it fast.
Readability/maintainability, then only as needed trade it off for speed, because not all code needs to be highly performant.
I don't agree with the assessment that betamax was superior. Sure it had more advanced technology, but it was too expensive and much more complicated - it fit the business requirements of a home video system poorly
Unlike the VHS vs betamax comparison, Mercurial was not strictly-better than Git. Mercurial is quite slow in comparison and becomes brutally painful to wait for once your repo gets reasonably large.
> I think Git turned out to have the better UI [...]
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.
As somebody that spent a lot of time trying to convince people that BSD was superior to linux and eventually having to give in when linux won due to various other reasons I know how mercurial fans can feel.
I still almost choke on my own vomit whenever I have to do any networking in linux that's more complicated that setting an IP address.
I like mercurial not because I am fan, but pragmatic and my team can work well with it. I still use it on daily basis. Indeed my team use hg-git and also git to work with GitHub for synchronizing some upstream repository of libraries we are using.
Also you bring a topic of BSD, I used it since 1993 along with Linux and still use both of them. These days I don't use Solaris and other Unix though.
In early years used various flavors of Unix like IRIX, AIX, HP-UX, Tru64 Unix and settled on BSD and Linux.
I didn't know that, I thought Google is using customised perforce and later moved to Piper for their mono repository. I do not know if Piper still use some parts of mercurial or is based on mercurial. But it's good to know Google is supporting mercurial.
Just that git (w/o the central hosting/PR concept/issues) is the total opposite than proprietary, and despite the popularity of the social network GitHub (because that what it is) the market for hosting git repos is very active. Look at Gitlab, Bitbucket, Azure Repos, AWS, ... which are all just fine.
I agree however with the fact that it is a pity to rely on a single tech which is not even the best of breed.
As you said it's sad but fortunately we have Rhodecode. In my previous company I was using Rhodecode plus mercurial and for developer working with it was a pleasure.
Now in current company we using Bitbucket, we'll think then to moving to rhodecode because we still want to use Mercurial
“a single proprietary solution Github by Microsoft”
Moving (Edit: Just the code, not issues and not pull request information) away from GitHub is trivial, since Git itself is open source and distributed, requiring merely setting up a repo on the new server (such as the open source Sourcehut) then running these commands:
git clone https://github.com/foo/bar
vi bar/.git/config # Add new remote location
cd bar
git push baz master
I've been using Mercurial and git for a long time and I have to say git's workflow is a lot better. Mainly Mercurial doesn't let me pull or do other stuff with outstanding changes, for no apparent reason other than that the author wanted it that way.
I'm using RhodeCode, and so far it has been working great for both git and mercurial repo hosting - paired with Concourse CI it makes for a great combo.
It's funny to see how the whole world concentrates on this Git thing, while there is a treasure trove called Mercurial.
Mercurial was made for humans. It is seriously convenient and productive. Something I cannot say about Git, which more reminds me of an adhoc job.
I use both Git and Mercurial on daily basis. But my preference goes to Mercurial: it is just more sane in a big way. It is clearly a piece of art and love.
The ease of use is a big thing for me. I find Git a bit arcane -- it's better than it used to be (around the Hg 0.9 era), but it's still quite bad.
Hg has this way of actively pushing you towards the safe way of doing things (e.g. if you try to change history). Git will let you blow away a month's work if you mistype a command.
I get the impression Git is the popular option because it underpins the Linux Kernel and Android development processes. That means it's popular, not that it's perfect for every use case.
Mercurial is especially powerful when given to developers who know Subversion. A ~20% productivity boost just from being able to losslessly branch off and merge back without worrying about stepping on other devs' feed.
Another team found out about it and were interested, but ultimately deployed Subversion -- because having one authoritative repository in one place was important to their process.
> Git will let you blow away a month's work if you mistype a command.
It's sad to hear someone say that, presumably you've been bitten by it.
What you describe is not true. While it's easy to blow away work you haven't committed, every commit you've made in the past month is saved in the reflog. Going back to any one of them is as easy as finding it and typing git reset --hard.
Erasing something from the reflog is hard. Possible, but it's not going to happen by mistyping a command or two.
Makes me sad because of course I agree the git UI is terrible, and I don't blame any user for not being able to figure it out. Although Googling "how do I recover lost git commit" does pull up useful results.
> Git will let you blow away a month's work if you mistype a command.
No, it won't. It's much harder to lose work in Git than you think. But really, if your remote repository is setup correctly with protected branches, this should never happen.
At least on Windows Mercurial doesn't support filenames written in various languages. Git does. So Mercurial was made for one billion people while git for the rest 6.5 billion of us.
What does "written in various languages" mean? Mixing multiple legacy encodings in one filename? Unicode filenames work fine on Linux (I just tested it with Chinese) and I would be very surprised if they didn't on Windows.
IMHO: Because Github just came at the right time for a free "no strings attached" project hosting solution when Sourceforge decided to become evil. That was the reason why I switched to Github anyway.
That Github used this strange version control system cobbled together by the Linux kernel devs for their specific workflow was a bit weird, but that wasn't a showstopper for moving to Github.
After all it was just one amongst many version control systems, and a VCS shouldn't be the centre of the universe anyway, over time Github would probably offer different systems anyway after they become more popular.
Nobody expected that Github was essentially a Trojan horse ;)
* Fogcreek (creators of Trello and Stackoverflow) picked Mercurial to power Kiln
Early on, both tools had different advantages but they evolved toward each other making the choice more about flavor and popularity. My guess is
* git was strongly associated with Linus so it won that crowd handily
* Github had a stronger association with open source than Bitbucket (dunno why though). Maybe it all came down to marketing. <-- there's a startup lesson
I used both at the same time at work for about 2 years, and mercurial was worse.
Hg was slow, and the (custom) python plugins around it we used were frustrating (specifically, we had a build pipeline that used the mercurial module in python, along with an arcane scons thing) and there were some specifically irritating pain points like bookmarks and shelve that didn't seem to work properly.
I mean, I get it, network effect... but all I can say is at least some people (like me) tried both and pick git on technical merit.
Linus Torvalds made it. That at least got me to look into it. Then saw it was better than svn and never looked back. Or sideways, so I missed mercurial.
i was using mercurial and svn before git. git was hard to learn but i went with efficiency and speed over convenience. also, if you have a good shell or a good GUI you don't need to memorize git commands. and if you are not a game developer uploading large binaries, git is the best around.
Many will not admit it, but git is just better.
Back in 2008 I made a presentation about DSCVS where I introduced git, mercurial and bazaar, and my advice for fellow programmers was "use git".
> June 1, 2020: ... all Mercurial repositories will be removed.
It's understandable that they would discontinue Mercurial support, but this part is shocking. No doubt that 1% includes more than a few obscure but historically interesting repos that will disappear because the owner wasn't monitoring their email (or is no longer with us).
Is BitBucket really that pressed for disk space? I hope they will reconsider and move those repos to a read-only archive like Google Code and CodePlex did instead of obliterating a piece of history for no good reason.
* February 1, 2020: users will no longer be able to create new Mercurial repositories
* June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed.
"""
The February 2020 deadline to prevent creating new Mercurial repos seems too late. Why delay? Ok, not next week by why not 1st November 2019. You will just upset randoms that by accident creates a Hg repo with bitbucket only to be told it will be deleted soon.
The June 1st 2020 deadline, is two parts. 1st part of disabling Hg features seems fine.
But as you say the second part should be punted way into the future if not never.
Sure, cripple it to read-only browsable only. But don't delete. There are plenty of tumbleweed open source projects that won't react before next year and be lost.
Read only browse means nearly all the same code, with whatever vulnerabilities it has, is there and needs to be supported. I'm sure a good chunk of removing the all Mercurial support is not needing to keep an eye on the code to allow repo browsing, etc.
They could just convert them to Git repos automatically. If you do that manually, their press release implies that the repos will stay around. So it can't be a disk space issue. Why haven't they offered to do this rather than just remove them?
According to the comments on the OP they tried to make a tool but couldn't make sure it would work in all cases for all repos, so they decided to not make a tool (and delete our repos instead). Such a disgrace.
The funny thing is that github has an import tool. Since we are forced to move to the industry standard of DVCS, I guess many will use this opportunity to move to the industry standard of platforms as well. For my use case Bitbucket is now inferior or equal in all respects.
It’s very expensive to maintain two SCM implementations in something like Bitbucket and maintain feature parity between the two. Poor cost/benefit ratio.
I remember back when I was at Atlassian and we had introduced Git repositories, Git usage grew an order of magnitude almost overnight.
> we had introduced Git repositories, Git usage grew an order of magnitude almost overnight
Not sure what you mean. There weren't any git repos before so yeah usage of git grew. Or do you mean global usage of git, including outside Bitbucket? I doubt it grew an order of magnitude.
where "zip backups" and network copy (each 7.9%) and "no version control" (4.8%) are higher than Mercurial (3.6%).
If you're in that boat, I can understand not using git (87%) because its UI sucks (IMHO), and not using SVN (16%) because it needs infrastructure, but Mercurial has neither of those hindrances. Heck, even RCS would be better than nothing at that point, and Hg is better than that.
Well git is the go-to default at many companies, so junior developers, if they learn anything, will learn git. People using network copy, no version control, or zip backups didn't choose those answers because they preferred them to mercurial; rather, they ended up with those because they either don't yet know about or understand how to use git (or any vcs).
IMHO mercurial's usage is so low because github/gitlab don't support it. I understand bitbucket not wanting to, but it says nothing about what mercurial's usage would be like if people didn't have to choose between it and being able to use github or gitlab.
Hi GitLab employee. While we don't officially support it, there is a friendly fork project of GitLab CE that does, and we do provide official support to them :) https://heptapod.net/
I'm not a Mercurial user, but some might be interested on this team that's working on adding Mercurial support to Gitlab, currently in the from of a fork or distribution called Heptapod:
Sourcehut has Mercurial support. It's open source and community maintained, and will remain supported for as long as the Hg community wants it to be. We recently took our Hg team out to Paris to meet the Mercurial community at the first Hg conference, and discussed how we can get involved in the future of Mercurial and committed to continuing to improve our offering into the foreseeable future.
I've whipped together a script to help you migrate your repos to hg.sr.ht, for those interested:
One important feature is unfortunately missing: to also clone the wiki (which on Hg projects is a Hg repo in its own right). But that would probably pose a bigger problem, given that Sourcehut appears to have no feature like the (Gollum-based) Wikis in GitHub and GitLab (not sure what they were based on in Bitbucket, though).
Evaluating hg.sr.ht right now. On quick scan I saw that man.sr.ht has no API reference for hg - I was wondering what the status for that bit is. Thanks!
Sigh. I really hate seeing hg languish like this. Command line is nicer, and I have yet to find any git gui frontend that matches what TortoiseHG can do (both in terms of invocating dialogs from the cmdline; and in terms of presenting and manipulating the graph).
I really hope something happens to help hg start accumulating more market share. Not just for my opinion on the tooling; but because IMO the "git = github = the only place for opensource" monoculture is kinda problematic.
The best TortoiseHg equivalent I've found (after a lot of searching) is SmartGit [1]. It's not as good as TortoiseHg and its not free but it's nice enough for most of my use cases.
I've been using Bitbucket with Mercurial repositories since 2011, both for private and public repos. I can count more than 50 mercurial repos that I'll need to manually move somewhere else. I'm really disappointed right now. I can understand their motives but they need to provide a single click method to at least convert a repo to git (this is a MUST IMHO).
I love mercurial but also can see that the community is shrinking, mercurial still relies on Python 2.7, and we are approaching to the EOL of Python 2.7. TortoiseHG also suffers from this, and the release cycle is always out of sync with the hg releases, and this breaks thg. These little things shows the sad state of mercurial, and in the end, this will drive most of the developers away from using it.
I guess it was great while it lasted... now, Bitbucket, please provide the developers the right tools to move away from mercurial with celerity.
Hg already works with Python 3, and tortoisehg's Python 3 development is proceeding at a rapid pace. They're not dead, they just left it to the last minute, relatively speaking. I expect them both to make the cutoff of Python 2 EOL with stable releases.
The releases being out of sync is not great, but if you're on Windows you download tortoisehg with a compatible hg, and if you're not your distro's repositories should ensure they don't push a new hg to you before tortoisehg is updated. I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks. Not a big deal. On Arch Linux since tortoisehg isn't in the repos it's a slight pain to hold back mercurial. Hopefully after the Python 3 transition tortoisehg makes it into the repos.
...though if there is not mercurial hosting available by the time bitbucket sunsets support, then maybe I won't care. I really want to keep using mercurial for my public open-source projects.
I didn't know that Hg already works with Python 3, that's great! The problem is that most distributions still will distribute the Python 2.7 version, I guess it makes sense until TortoiseHG catches up with Mercurial. I hope this happens soon, but I think that I'm going to switch to Git for the convenience of using GitHub over the other solutions (for open source projects the visibility is a good plus, for private projects I think GitLab is on par on features).
> I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks.
3 weeks for me is a lot of time, that's at least 3 weeks I can't use TortoiseHg, something I use on a daily basis. Anyway, since this happened several times now I manually update hg and thg to avoid this problem (but it's a PITA). I know this is a problem with the distributor and not from the Hg or Thg devs, but still it's a common problem that could be coordinated between the two projects. I actually started using Mercurial because Thg was way better than the Git GUI tools at the moment, and I think this still applies.
In conclusion, a hope the best for the Mercurial project but I'm afraid this will have a negative impact in the long term.
Readit News
So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use. GitHub successfully marketed git, so git and GitHub are synonymous for most developers. Now majority of open source projects are reliant on a single proprietary solution Github by Microsoft, for managing code and project. Can understand the difficulty of bitbucket, when Python language itself moved out of mercurial due to the same inertia.
Hopefully gitlab can come out with mercurial support to migrate projects using it from bitbucket.
For people who believe in self hosted solution can install Kallithea (https://kallithea-scm.org) or Rhodecode open source edition. Kallithea is used by Unity engine to manage their source code internally with mercurial.
I actually picked mercurial first. I found the interface more intuitive, especially coming from svn. The problem was that everyday commands were just dog slow -- 5, 10 seconds on every single interaction. It felt like wading through molasses, contrast to git, which was effectively instantaneous on small repos and git on my large repo was still multiples faster than hg on a small repo. Also, IIRC hg didn't have a "git stash" equivalent. I chose git on its merits and didn't look back.
A few years later (2010 ish?) I met a mercurial evangelist who said things had changed on the performance front, but I checked and they hadn't.
I'll give hg the benefit of the doubt that it eventually got better, but I have serious doubts about your accusation that git's success had to do with marketing. I gave hg a more than even chance and it lost, fair and square, on technical merit, as weighted according to my everyday use cases.
On my Skylake+SSD desktop, it takes over ten seconds to switch branches with git checkout, several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.
We are making many great strides here at Microsoft to improve git performance, such as with VFS for Git which my Windows repo clone uses. But with hundreds of gigabytes in a unversioned download of the source tree, there is only so much we can do.
[1] since https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...
In my earlier team at fortune 100 firm, most developers use Windows with svn. We tried git and it did not work well due to UI and windows support. They were able to pick up UI easily and were quickly productive in mercurial. It worked pretty good on all 3 platform Windows, Mac and Linux. I am talking of time when GitHub was not that popular in corporate world.
Performance was never an issue.
Also at that time mercurial followed philosophy of being explicit and every merge needs to be explicit and committed with immutable history. So can see the evolution of code along with the mistakes made.
I believe the success of git is due to GitHub and for many it's synonymous.
It did not. We had a giant hg monorepo at Yandex, and even mere "hg id" took ages (and required net access to source repository for some reason). The plan was to eventually switch to it from SVN, not sure if they eventually did because I left the company.
Deleted Comment
Marketing is often necessary to get a start, but it is rarely sufficient for a long-lasting success. The claim that "it's all marketing" is usually made by those who look at one aspect of the technical merits and miss others that turn out to be more important. Just as in the actual VHS vs. Betamax story [1]. Betamax had a slightly, almost imperceptibly better picture quality, while VHS had double the recording time of Betamax. VHS won on the technical merits as they mattered to users.
[1]: https://en.wikipedia.org/wiki/Videotape_format_war
this is an amazing opinion. Git won over mercurial because its capabilities and usage model are vastly better than that of mercurial. I had all of my projects on mercurial for many years and finally switched over to git, it was like a whole new world opened up. My daily workflows are now entirely based on concepts that are complete anathema to mercurial, where changesets are just objects that can be moved around or deleted once no longer needed, where commits to master represent complete features in a single changeset. Throwaway or hypotehtical branches are now changesets in Gerrit, rather than "feature branches" that exist forever whether or not they were used. I'm not sure if mercurial found a way to work out those problems of having zillions of little "fix typo" style commits crowding up a feature as well as zillions of dead feature branches forever crowding up the repo, but it at least was not apparent to me seven or eight years ago which would mean it's not easy to use.
The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better.
In the case of VHS vs Betamax, VHS won because it was better overall. Some people point to one or two advantages of the Betamax format, but ignore that overall it wasn't better than VHS. (Because Beta tapes were physically smaller, you were usually forced to use a slower tape speed, loosing the very minor picture quality improvement at the highest tape speed. Thus, longer prerecorded Beta movies looked worse then their VHS versions.)
The same thing is also the case with git versus Hg. I used Hg years ago because it was easier to learn; but once I learned git, I see no reason to go back to Hg. Yes, Hg has an easier learning curve, but that's one particular detail.
I can’t speak for all “the people”, but I disagree strongly. There are fine reasons for picking things other than git (I’ve used fossil since it’s near-inception); git’s dominance or fossil’s loss in the market does not make gits UI/UX superior. Thats like saying McDonalds is the height of cuisine, because “Billions and Billions Served”.
Git is incredibly fast. Many operations happen almost instantaneously even on large repositories. It's really nice. I've heard a lot of people talk about how they abandoned mercurial because it's slow. Some even switched to git from svn not because git's model is better but because svn is slower.
"Premature optimization is the root of all evil" is an old programming advice quote that is so horribly misunderstood that it's basically wrong. It means think about your problem at the high (algorithm and overall goal / design space) level before worrying about low-level optimizations. It does not mean that optimization is bad or that performance isn't important.
I made another comment recently on the same issue. I really wish that quote would die in favor of more substantial advice that won't be so misunderstood.
https://www.youtube.com/watch?v=ddYZITaxlTQ
https://phacility.com/
Maybe these things have not proved true in the long term? I think Git turned out to have the better UI and architecture.
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.
I still almost choke on my own vomit whenever I have to do any networking in linux that's more complicated that setting an IP address.
Also you bring a topic of BSD, I used it since 1993 along with Linux and still use both of them. These days I don't use Solaris and other Unix though.
In early years used various flavors of Unix like IRIX, AIX, HP-UX, Tru64 Unix and settled on BSD and Linux.
Again due to linus/linux community, git has amazing polish (efficiency, error messages, docs) of a superb data model and brepus user interface.
https://engineering.fb.com/core-data/scaling-mercurial-at-fa...
That's from 2014, but I don't believe they've moved away from it since. In 2018, there's this:
https://news.ycombinator.com/item?id=16565299
I agree however with the fact that it is a pity to rely on a single tech which is not even the best of breed.
I used to run Rhodecode some years ago, and switched to Kal when they forked. At this point I wouldn't be without it.
Moving (Edit: Just the code, not issues and not pull request information) away from GitHub is trivial, since Git itself is open source and distributed, requiring merely setting up a repo on the new server (such as the open source Sourcehut) then running these commands:
(Replace foo, bar, and baz with real names)Not sure what that means?
It was just the best development environment on windows
Mercurial was made for humans. It is seriously convenient and productive. Something I cannot say about Git, which more reminds me of an adhoc job.
I use both Git and Mercurial on daily basis. But my preference goes to Mercurial: it is just more sane in a big way. It is clearly a piece of art and love.
Hg has this way of actively pushing you towards the safe way of doing things (e.g. if you try to change history). Git will let you blow away a month's work if you mistype a command.
I get the impression Git is the popular option because it underpins the Linux Kernel and Android development processes. That means it's popular, not that it's perfect for every use case.
Mercurial is especially powerful when given to developers who know Subversion. A ~20% productivity boost just from being able to losslessly branch off and merge back without worrying about stepping on other devs' feed.
Another team found out about it and were interested, but ultimately deployed Subversion -- because having one authoritative repository in one place was important to their process.
It's sad to hear someone say that, presumably you've been bitten by it.
What you describe is not true. While it's easy to blow away work you haven't committed, every commit you've made in the past month is saved in the reflog. Going back to any one of them is as easy as finding it and typing git reset --hard.
Erasing something from the reflog is hard. Possible, but it's not going to happen by mistyping a command or two.
Makes me sad because of course I agree the git UI is terrible, and I don't blame any user for not being able to figure it out. Although Googling "how do I recover lost git commit" does pull up useful results.
No, it won't. It's much harder to lose work in Git than you think. But really, if your remote repository is setup correctly with protected branches, this should never happen.
Fortunately, that can always be undone with another command
What's the command to mistype?
That Github used this strange version control system cobbled together by the Linux kernel devs for their specific workflow was a bit weird, but that wasn't a showstopper for moving to Github.
After all it was just one amongst many version control systems, and a VCS shouldn't be the centre of the universe anyway, over time Github would probably offer different systems anyway after they become more popular.
Nobody expected that Github was essentially a Trojan horse ;)
* Bitbucket provided unlimited free private repositories and they were exclusively Mercurial. Github had limits for private repos.
* Google evaluated both and preferred Mercurial for code.google.com http://www.saturngod.net/articles/dvcsanalysis-support-analy....
* Fogcreek (creators of Trello and Stackoverflow) picked Mercurial to power Kiln
Early on, both tools had different advantages but they evolved toward each other making the choice more about flavor and popularity. My guess is
* git was strongly associated with Linus so it won that crowd handily
* Github had a stronger association with open source than Bitbucket (dunno why though). Maybe it all came down to marketing. <-- there's a startup lesson
Hg was slow, and the (custom) python plugins around it we used were frustrating (specifically, we had a build pipeline that used the mercurial module in python, along with an arcane scons thing) and there were some specifically irritating pain points like bookmarks and shelve that didn't seem to work properly.
I mean, I get it, network effect... but all I can say is at least some people (like me) tried both and pick git on technical merit.
i was using mercurial and svn before git. git was hard to learn but i went with efficiency and speed over convenience. also, if you have a good shell or a good GUI you don't need to memorize git commands. and if you are not a game developer uploading large binaries, git is the best around.
Deleted Comment
It's understandable that they would discontinue Mercurial support, but this part is shocking. No doubt that 1% includes more than a few obscure but historically interesting repos that will disappear because the owner wasn't monitoring their email (or is no longer with us).
Is BitBucket really that pressed for disk space? I hope they will reconsider and move those repos to a read-only archive like Google Code and CodePlex did instead of obliterating a piece of history for no good reason.
"all Mercurial repositories will be removed"
does indeed sound quite at odds with why people use Bitbucket. dissonance re core value-proposition.
I hope Atlassian finds a less destructive way to phase out Mercurial support. Gladly they do have enough time to clarify / reconsider.
"""
* February 1, 2020: users will no longer be able to create new Mercurial repositories
* June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed.
"""
The February 2020 deadline to prevent creating new Mercurial repos seems too late. Why delay? Ok, not next week by why not 1st November 2019. You will just upset randoms that by accident creates a Hg repo with bitbucket only to be told it will be deleted soon.
The June 1st 2020 deadline, is two parts. 1st part of disabling Hg features seems fine.
But as you say the second part should be punted way into the future if not never.
Sure, cripple it to read-only browsable only. But don't delete. There are plenty of tumbleweed open source projects that won't react before next year and be lost.
Read only browse means nearly all the same code, with whatever vulnerabilities it has, is there and needs to be supported. I'm sure a good chunk of removing the all Mercurial support is not needing to keep an eye on the code to allow repo browsing, etc.
The funny thing is that github has an import tool. Since we are forced to move to the industry standard of DVCS, I guess many will use this opportunity to move to the industry standard of platforms as well. For my use case Bitbucket is now inferior or equal in all respects.
I remember back when I was at Atlassian and we had introduced Git repositories, Git usage grew an order of magnitude almost overnight.
Not sure what you mean. There weren't any git repos before so yeah usage of git grew. Or do you mean global usage of git, including outside Bitbucket? I doubt it grew an order of magnitude.
Deleted Comment
* https://insights.stackoverflow.com/survey/2018#work-_-versio...
where "zip backups" and network copy (each 7.9%) and "no version control" (4.8%) are higher than Mercurial (3.6%).
If you're in that boat, I can understand not using git (87%) because its UI sucks (IMHO), and not using SVN (16%) because it needs infrastructure, but Mercurial has neither of those hindrances. Heck, even RCS would be better than nothing at that point, and Hg is better than that.
https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_19...
I've whipped together a script to help you migrate your repos to hg.sr.ht, for those interested:
https://hg.sr.ht/~sircmpwn/invertbucket
Let me know how it works out for you - I'd like to hear some test results before I post it to sr.ht-announce. Cheers :)
1. `invertbucket` should check that the machine has `hg` installed. (I accidentally ran it on a machine that didn't.)
2. Say my sr.ht username is "thegreengiant" and my bitbucket repository is "abc". At the end of its run, `invertbucket` says:
> Imported to: https://hg.sr.ht/srht_owner/abc
That URL 404s. It would be an improvement if `invertbucket` replaced "srht_owner" with "~thegreengiant".
https://man.sr.ht/git.sr.ht/api.md
So you can create and manage repos over the API today. We're still figuring out a good API design for fetching hg data over REST.
I really hope something happens to help hg start accumulating more market share. Not just for my opinion on the tooling; but because IMO the "git = github = the only place for opensource" monoculture is kinda problematic.
[1] https://www.syntevo.com/smartgit/
I love mercurial but also can see that the community is shrinking, mercurial still relies on Python 2.7, and we are approaching to the EOL of Python 2.7. TortoiseHG also suffers from this, and the release cycle is always out of sync with the hg releases, and this breaks thg. These little things shows the sad state of mercurial, and in the end, this will drive most of the developers away from using it.
I guess it was great while it lasted... now, Bitbucket, please provide the developers the right tools to move away from mercurial with celerity.
The releases being out of sync is not great, but if you're on Windows you download tortoisehg with a compatible hg, and if you're not your distro's repositories should ensure they don't push a new hg to you before tortoisehg is updated. I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks. Not a big deal. On Arch Linux since tortoisehg isn't in the repos it's a slight pain to hold back mercurial. Hopefully after the Python 3 transition tortoisehg makes it into the repos.
...though if there is not mercurial hosting available by the time bitbucket sunsets support, then maybe I won't care. I really want to keep using mercurial for my public open-source projects.
> I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks.
3 weeks for me is a lot of time, that's at least 3 weeks I can't use TortoiseHg, something I use on a daily basis. Anyway, since this happened several times now I manually update hg and thg to avoid this problem (but it's a PITA). I know this is a problem with the distributor and not from the Hg or Thg devs, but still it's a common problem that could be coordinated between the two projects. I actually started using Mercurial because Thg was way better than the Git GUI tools at the moment, and I think this still applies.
In conclusion, a hope the best for the Mercurial project but I'm afraid this will have a negative impact in the long term.