I find it nearly unbelievable that you didn't provide a way to simply convert old repositories. I would have happily converted my existing repositories from mercurial to git, as I don't use mercurial much anymore either except for those handful of repos.
Since you didn't provide this capability my only choice is to migrate the repositories to a competitor since it was the easiest way to do it. Fortunately most of those repos don't have issues I have to migrate. The few that do are enough I can do by hand. I know there are also tools to do this but this is a frustrating task I could do without in the first place, much less having to mess around with some potentially flimsy third-party tools.
This is a reminder that the GitHub import tool does not always work perfectly and may silently throw away commits.
Some of the previous pages (like page 16) of this discussion thread go into more depth on this issue (and others) and provide tools that will work around the issues and ensure you end up with a git repository on GitHub that has not lost data.
Just to remind everyone that Heptapod provides a solution without any conversion to Git, thanks to its powerful builtin Bitbucket importer (issues, PRs, wikis). The latest version (0.14) is based on a supported Gitlab Version (12.10) and we keep a fast pace of improvements.
I decided to move to GitHub. I used Google Code, CodePlex and BitBucket... All of them ditched their users. Probably, it is time to choose the most popular service on the market to be sure that I won't need to move in 5 years again.
Found this new very fast hg-to-git conversion tool:
It is much faster than hg-git, maps Mercurial branches to Git branches, and allows to merge a few Mercurial repositories into one Git monorepo. Works well on Windows (it's just one small executable).
@kalthadI've just tested that tool, and it properly converted all my Hg branches to Git branches, without creation of Hg bookmarks (what is required to do when you use Hg-Git).
Eventually, I'll probably move to Git completely. At this moment I use Git at work, and Hg for personal projects. I like Hg more, but using one tool for everything is easier, and Git has much better support everywhere, unfortunately.
Not happy about this move. I left Atlasian because if this and moved to Helix TeamHub. No conversion tool, no support, kind of unprofessional if you ask me. And what's the point on focusing on Git since there's already GitHub that does that better than you? Anyways, your decision. Cheers!
Ah well it is not true that you need booksmarks not converted your named branches to git,
what you need is a very recent version of hg-git (the one which contain a patch provided by Manuel Jacob)
then you have to add to your .hgrc file
[git] export-additional-refs.named-branch-heads:revset = head() and not branch('re:\Adefault\Z') export-additional-refs.named-branch-heads:template = refs/heads/{branch}
this way when you push to git, you convert your named branches to git branches
*and*
when you later pull you recover your named branches!
that is you and your mercurial collaborates can stick to mercurial and bitbucket
this is what I do with most of my repositories, because although this hg-git solution is an alternative, for most mercurial users I know it is just too much.
Like @Betalord, I also moved a number of hg repositories to Helix TeamHub some time ago and am grateful for their benevolence towards private repositories with a limited number of users. The only difficulty I ran into had to do with the associated wikis. Before I give the details, please note that (a) Helix Teamhub does support mercurial-backed wikis; and (b) whichever migration path one chooses, completely automated migration of the associated wikis is unlikely to succeed because of internal hyperlinks and the like.
The issue that I ran into is that at Helix TeamHub, internal hyperlinks with anchors do not currently work as they should (at least for hg-backed wikis). Following such a hyperlink, however, will cause the appropriate page to be displayed. The good people at Helix TeamHub are aware of the problem and fixing it is on the agenda.
@marmoute - heptapod looks quite reasonable, but is there some way to appeal to them to modify their anticipated pricing model so that they are at least competitive with Helix TeamHub (i.e. free for private repositories with very modest needs)?
right I support your proposal to marmoute, especially as I must add, given the fact that bitbucket was quite generous to the academic world,. They let me have quite a number of private repos, for collaboration for free.
I do, however, understand that heptapod is a sort of start up and cannot afford this sort of generous offer. This is a bit of a pity, because
I know that core mercurial developer are involved whose contributions I very much appreciate
Helix has a bit of a complicated interface compared to bitbucket: they distinguish projects from repositories, adding collaborators is not that straightforward, and receiving notifying message if someone is pushing is possible but not obvious at all
@kalthad Just one note about usage hg-git and versions
In order to use hg-git with fresh (5.3+) Mercurial|TortoiseHG without big troubles you have to have hg-got at least of tag 0.9.0a1, but your suggestion is only 0.8.13+18
I suppose, latest HG + any new hg-git + `branch_bookmark_suffix` is better, than lazy export and old (5.0.2) core
It looks like the hard part isn't conversion of the Mercurial history but rather conversion of the Jira history. There should be a guide provided for this.
No guidance, No help, Not even the simple list all mercurial repos function. I am stuck with bitbucket for now and it has been 4 days since I started trying to convert 4 pages of repos to git.
I am not expecting anything from you guys, you have shown over the months that you don't give a damn about your users. When I first came to bitbucket it was because bitbucket was the only decent mercurial hosting at the time. Now you are forcing me to switch to git or get deleted.
I wow here to switch to another repo/ticket/wiki system as soon as possible. My colleagues and myself thank you for the last 4 days of hell with our deepest vile feelings.
Jeff L wrote: "It looks like the hard part isn't conversion of the Mercurial history but rather conversion of the Jira history."
Ali Akdurak wrote: "Now you are forcing me to switch to git or get deleted."
Having followed this thread for a while, it seems to me that plenty of people in their fervour to adopt and promote the dominant Microsoft-owned repository hosting service will fall into precisely the same trap in the future: as they switch on all the supposedly convenient extras (issue tracking, continuous integration, the usual mediocre wiki solution), they will not consider issues of data portability or interoperability.
And that leads to a very unequal relationship between vendor and user, which would make me very worried if that vendor happened to be a habitual monopolist. So I would advise people to consider the broader issues (not just "it's popular and they give it us for free!") if only to avoid experiencing all of this again down the road.
FWIW the move to Heptapod went very well for my open source repositories: all the history, all the issues and all the PRs were properly imported. The guys have done a great job in adding Mercurial support to GitLab.
It's a pity there is no provision for private or even personal repositories, meaning we still have to decide what to do with these. But, as we have seen with BitBucket and other services, companies cannot afford to provide unlimited resources for free. Thanks to Atlassian for their services for all this time.
@Peter Koppstein We don't have a free tier, because neither development nor hosting is free. However we try to have a modest pricing for modest usage. In particular, the usage based billing aims at making it easy for people with many occasional collaborator, since they only get billed when active.
You're definitely right about those "unlimited resources for free": we prefer to provide a sustainable model rather than indirect returns based on the user being the product.
Looks like some people not getting this in time. They couldn't even get a list of their own Mercurial projects without Git projects and forks. I recommended to use https://github.com/philipstarkey/bitbucket-hg-exporter/ for issues and comments, but haven't used it myself.
531 comments