We will have to migrate 78 repositories: it will take a long time to convert source codes!
But the most critical question is: how could we transfer all the settings (metadata, issues tracker, etc.) from the old Mercurial project to the new Git project without an automatic function?
"...no longer be able to create new Mercurial repositories"
Fine, I prefer mercurial but, yes the industry has chosen and it would be a support burden, my new projects will be git.
"...and all Mercurial repositories will be removed."
I'll be looking at alternative providers.
You are at the very least going to have to clarify what removed means? If we miss the boat are we going to be able to download the source or will all our work just be gone? The latter seems reasonable to implement and given your refusal to provide an online migration tool seems the least you could do.
Presumably Atlassian's end goal is to get out of the source code hosting business and focus on Jira, because this move wouldn't make sense any other way -- what reason is there to host a Git repository on Bitbucket instead of GitHub?
Heptapod looks interesting, but I'd have to self-host it. I'll be keeping an eye on this thread to see what people have to say about other cloud-based hosts.
Incidentally, I found the first email I got from Bitbucket after signing up back in 2011. Here's what it said at the top:
Thank you for signing up for Bitbucket!
We're excited that you're getting started with Mercurial, arguably the best distributed version control system around.
I want to take a minute to thank Bitbucket for years of excellent service. As company we pay hundreds dollars monthly for mercurial hosting, and lot of our infrastructure are tied to like 600+ Mercurial repositories.
I love Mercurial, and I find that it's more comprehensible tool for my tasks. It is my opinion. But it seems that we are going to be forced to move to Git, it is going to be Github, especially with Github actions available for us in beta, it is a no brainer for Git development.
I'd encourage anyone that would consider a bitbucket hg -> gitlab git migration that retained issues/pull requests/etc to comment / vote on that issue please!
I just realized the extent, and possibly the rationale, of the refusal to provide a migration tool...
This also means that our 100s or thousands of issues will be lost ( for example https://bitbucket.org/axcryptab/axcrypt-net/issues ), because the issue-list is tied to the repository - so even if we succeed in migrating the source code to a git repository on bitbucket - our issues won't. And git repositories on bitbucket doesn't support the issue feature. So I guess the idea is to move the issues to Jira. Manually!?
And... Atlassian seems to say that in June 2020 they will just summarily delete the repositories - including the issues presumably then since there is no issue-functionality in Bitbucket git repositories.
And no migration available, in fact Atlassian explicitly and definitively says everybody is on their own.
Wow, I just say wow....
No bloody way I move all this back to Bitbucket after converting to git and manually moving to Jira - in another 5 years Atlassian sees gold at the end of another rainbow and then summarily kills Jira as well I guess.
Too bad, I really liked Bitbucket, Mercurial and especially the perfectly lightweight issue tracker!
github imports to git from a bitbucket mercurial repository by simply supplying the repository address. Really simple.
Sadly I believe this only imports the source code, and not any of the history of issues, pull requests, etc - though I'd be very happy to be corrected if I've missed something.
As well as "Bitbucket in the cloud", we have a self hosted Bitbucket system containing private repos. Will this decision affect any of these Mercurial repos too? Obviously you wouldn't be able to delete the repos (I would hope!) but will support for the Mercurial features continue to exist, or do I need to find an alternative solution for these as well?
As a side issue I am interested that you have used the results of a StackOverflow survey to drive this decision. But I am curious as to how many Mercurial repos you are hosting and also compared to how many Git repos you have. Because my (unsubstantiated) feeling is that a LOT of people are still using Mercurial for various good reasons. Would you be prepared to publish these numbers?
It's clear from virtually all the posters here that you'll have to provide some kind of transformation tool. I want to add my voice to this as well. I think you risk alienating way too many users otherwise. If you want to remain competitive, give users a reason to stay. A stellar customer service, like this, would let us believe in you.
It doesn't even have to be flawless. It's not the end of the world if some edge case isn't covered. Just make it work well enough that you don't lose the code, and that'll satisfy like 80% of people.
If you instead ask people to do the git transformation by hand, I don't think they'll choose bitbucket as the "target" system.
I think mercurial users will leave bitbucket. I doubt that the important of all the meta data (issues etc) will work (I am glad to use a mercurial extensions for my own issues)
If they switch to git they can ask themselves why not not to use github.
hg-git is good if I want to access the git repositories of others but it is not to good for my own, since it cannot provide support for named branches, because git does not have this important feature.
I tried out sourcehut in the last 2 hours, it works, but bitbucket is more comfortable.
This is pretty disappointing but I think it's also short-sighted and possibly misinformed. Both Google and Facebook have invested significant amounts into mercurial tooling which increases the likelihood that people will continue to use Mercurial. I really hope you reconsider.
To get hg-git installed on windows with the Mercurial binaries from the MSI installer, I had to hack a Mercurial zip file to patch in hg-git and its dependency, dulwich. Though TortoiseHG has this already, I didn't want to change my hg workflow by installing another version. In my case, the file in question is:
I copied the library.zip file to a temporary location, opened it using 7-zip, and wrote the directories hg-git/hggit and dulwich/dulwich from the previous steps into the root of the zip file. Then I replaced library.zip with the patched version using the Windows file explorer, using admin permissions to overwrite. Then its just a matter of creating the bare git repos, and doing an hg push from inside the hg repo into the bare git repo. A final clone turns the bare repo into a regular git repo. Then you can make new git repos on Bitbucket and git push there.
This could all be made into an automated script or packaged into a standalone solution, but I'm sure there's some corner cases that wouldn't be handled properly. At least, I wouldn't want to maintain such a thing. That said, I hope the above ideas help others.
hg-fast-export seems to have done things pretty seamlessly for me.
Anyone know of a utility that will convert .hgignore formatted files to .gitignore? They're not identical; though it's not the end of the world having to do it manually.
Any chance you could provide a feature for importing issues from one repo to another? So that the new git repos I create based on the soon-to-be-defunct hg repos can take the issues across?
528 comments