
Sunsetting Mercurial Support in Bitbucket - ingve
https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
======
dragonsh
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](https://kallithea-scm.org)) or Rhodecode open
source edition. Kallithea is used by Unity engine to manage their source code
internally with mercurial.

~~~
jjoonathan
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.

~~~
hyperrail
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.

[1] since [https://devblogs.microsoft.com/bharry/the-largest-git-
repo-o...](https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-
planet/)

~~~
Someone1234
Definitely sounds like a problem. Do you think an alternative source control
solution would handle that situation better? At some point huge with a large
number of small files takes its toll.

It would be interesting for someone inside Microsoft to write a blog
describing why Git works well for the Linux Kernel but not for the Windows
Kernel. They cannot be that different from a layout perspective, can they?

~~~
ldrndll
I believe the difference is that the Linux kernel itself is not _that_ big a
project. Windows is a lot more than just a kernel; it’s more akin to having
the source code for an entire Linux distribution in one repo.

~~~
vquemener
You mean like Gentoo
([https://github.com/gentoo/gentoo](https://github.com/gentoo/gentoo)) ? It's
not that big either (around 700MB).

~~~
webstrand
That only includes the ebuilds, which are instructions for how to build from
source, not the sources themselves.

~~~
vquemener
So the sources for, say, Paint or Edge are versioned within the Windows
repository?

~~~
hyperrail
Yes, most of the components and files in a default Windows installation are
built from sources in the main Windows OS git repo.

Some parts of Windows have split out into their own repos and CI build and
test pipelines, but splitting is a process that takes people's time and has
pros and cons, especially when changes in the main OS repo are needed to give
the separated components a complete, coherent API surface.

------
garganzol
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.

~~~
ChrisSD
And yet people overwhelmingly chose Git. Why is that?

~~~
libria
No clue. I thought for sure Mercurial would come out ahead, it had some
proponents:

* 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...](http://www.saturngod.net/articles/dvcsanalysis-support-analysis-of-git-and-mercurial-project-hosting-on-google-code/).

* 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

~~~
jhasse
> * 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

Maybe because it was bought by Atlassian.

~~~
chipotle_coyote
> Maybe because it was bought by Atlassian.

Nope! Bitbucket had the "free private, paid public" model from the start.
IIRC, Atlassian actually changed the model to allow unlimited public
repositories after they purchased Bitbucket. It's possible that if BB had
started with this model, they'd have been a much stronger competitor.

------
mcbits
> 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.

~~~
dreamcompiler
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?

~~~
jobigoud
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.

------
throw0101a
They link to an SO survey:

* [https://insights.stackoverflow.com/survey/2018#work-_-versio...](https://insights.stackoverflow.com/survey/2018#work-_-version-control)

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.

~~~
doubleunplussed
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.

~~~
emilycook
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/](https://heptapod.net/)

------
tecleandor
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:

[https://gitlab.com/gitlab-org/gitlab-
ce/issues/31600#note_19...](https://gitlab.com/gitlab-org/gitlab-
ce/issues/31600#note_198825557)

~~~
vladsanchez
Thanks for sharing, ppl may be headed to Gitlab then.

------
ddevault
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:

[https://hg.sr.ht/~sircmpwn/invertbucket](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 :)

~~~
bumbledraven
Thanks for making `invertbucket`! I used it to import my bitbucket
repositories and ran into a few issues:

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](https://hg.sr.ht/srht_owner/abc)

That URL 404s. It would be an improvement if `invertbucket` replaced
"srht_owner" with "~thegreengiant".

~~~
Sir_Cmpwn
Thanks for the feedback! Fixed on both counts.

~~~
bumbledraven
What sr.ht URL path would I use to get a page to render as markdown?
hg.sr.ht/~thegreengiant/raw/default/foo.md renders as text.

~~~
Sir_Cmpwn
Only the readme is rendered as markdown right now.

~~~
bumbledraven
Thanks.

------
ryebit
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.

~~~
McP
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.

[1] [https://www.syntevo.com/smartgit/](https://www.syntevo.com/smartgit/)

~~~
ntobjx
Thanks for the pointer. I'll see if my company will "sponsor" me a copy. Looks
nice indeed.

------
SpartanJ
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.

~~~
altano
Move your repos to hg.sr.ht:
[https://hg.sr.ht/~sircmpwn/invertbucket](https://hg.sr.ht/~sircmpwn/invertbucket)

~~~
SpartanJ
I'll consider it, thanks for sharing.

------
mamcx
This suck big time.

HG is by far the best UX of all SCM I have used. Without bitbucket I think
usage of hg will drop even faster.

The sad thing is that git requiere so much arcane usage that hg have spared me
for so much time.

I wonder why the worst always win? C, C++, JS, MySql.

Don't tell me is for "speed" or "features". Is incredible how much stupid
effort and money go in put a lipsick on top of that when nicer ways exists...
and are know... and have proved to work... and even faster (look at you, C/C++
build times)...

Even MORE bizarre is why not improve the tools coping what is good from others
AND cleaning the usage of them?

Probably only python of the "good" side have critical mass...

~~~
carapace
I'd like git internals (merkle-tree etc.) with Mercurial's CLI UI, I think.

~~~
nemetroid
It's quite possible to write your own Git CLI, the fundamentals are well
exposed.

~~~
ntobjx
It works until it doesn't. One of the biggest problems with Git IMO is that it
always exposed a plethora of internals which therefore have become public
interfaces. One is to be expected to know the guts of .git as an
intermediate/advanced user. And because those are interfaces, it's _always_
going to be very difficult to fix issues arising from previous wrong design
decisions.

Fundamentals in Git aren't necessarily easy to use from the CLI, but you'll
get by with a dozen or so command line invocations overall. And I found it
astonishing and disheartening how so many people were able to make do with
completely illogical commands like "git checkout -b" ...

But once Git sticks you the finger and you _need_ to delve down into its guts,
you often have a problem.

Now don't get me wrong, the amount of GUI tools hiding Git's intricacies and
web interfaces like GitHub glossing over numerous shortcomings of Git have
certainly helped the UX and the popularity. But once you _have to_ delve down
to CLI usage because you ran into an issue that your tool tries to gloss over,
most people are at a loss. And most people will opt to scrap the current
clone+worktree and clone anew. That doesn't really sound to me like people are
in command of their tool of choice (Git), though.

And at this point we haven't even touched stuff like refs which only differ in
case. It's all fine until Git starts unpacking the refs. Which can be fun on
systems like macOS and Windows which have support for case-sensitivity in the
file system, but who opted to forgo that via a setting.

------
vnorilo
I will be affected. I think I will take a serious look at sourcehut[1] now. I
get a good vibe, but the bus factor scared me away before.

[1] [https://hg.sr.ht/](https://hg.sr.ht/)

~~~
Sir_Cmpwn
Don't worry, in the event of my untimely demise there are trusted people with
access to the servers to pick up the mantle.

~~~
vnorilo
Sir, I wish you long life and godspeed, but my threat model includes acquihire
and lost interest ;)

However, I keep talking how we need to avoid monocultures, so I guess it is
about time I assume some minor risk.

~~~
Sir_Cmpwn
[https://man.sr.ht/billing-faq.md](https://man.sr.ht/billing-faq.md)

Sourcehut has accepted no external funding and once the alpha period ends, all
accounts must be paid. Even with optional payment, it already turns a profit.
I'm pretty confident in the sustainability of the service.

As for me losing interest, the good news is that I need software hosting no
matter what I'm working on, so I'll always be working on it. And, since it's
open source and patches are welcome, so could you add anything you need.

------
pgt
It would be interesting to read a breakdown of why Mercurial failed against
Git. It is superior to Git in every way except performance and adoption. Git
won because GitHub won, and I bet GitHub chose Git over Hg's Python
implementation because it was too slow.

I wonder if Mercurial would have won if it was implemented in C or Rust (had
it existed then).

~~~
jlebar
> It is superior to Git in every way except performance and adoption.

Performance is _such an important advantage_ , though.

I type git diff hundreds of times a day, and when I switched from hg to git at
Mozilla, this made such a big difference in my life.

These days I type hg histedit maybe fifty times a day at Google, and I cry
every time because it is so. glacially. slow. hg diff too. And I'm working
with a relatively small repository.

Speed matters for tools we use all the time.

I'd also posit that the process of writing "plugins" for git is much easier
than writing hg plugins. A git "plugin" is just a shell script that uses git.
If you can use git, you can write a shell script that uses it. An hg
plugin...whoaboy.

~~~
durin42
Please feel encouraged to report a bug about histedit slowness with some
details so we can try and reproduce and consider a fix.

~~~
jlebar
I'll see what I can do. Because it's Google code, it may not be feasible. But
we have a whole team of hg developers ourselves, maybe I should bug them
before putting it on you. :)

~~~
mambru
Including durin42 himself ;)

------
ldng
Over the year I've used CVS, SVN, bazaar, Mercurial and Git. Mercurial has
always been the one I struggled the most with. It never clicked with me. Just
to respond to some arguments I see floating around.

In my last team we switched from Hg to Git and absolutely everyone but the CTO
felt more comfortable with it. including the data scientists.

To me, Mercurial UI might be friendlier than Git's but it's really a moot
point if it does not fit with the way people actually think/work.

Also, I sincerely think Git was getting more popular _before_ Github. Granted,
it massified the adoption.

------
twic
I and the _dozens_ of other remaining Mercurial users will be severely
inconvenienced by this.

Still, at least SourceForge still has Mercurial support!

~~~
mort96
I wouldn't trust SourceForge at all after all the horrible stuff they've done.
I know they have allegedly improved after new owners and a come-to-jesus
moment, but damn, that was some shady shit.

~~~
srean
I think you are thinking about the old and nasty sourceforge. They have since
been bought and the new owners have changed what nasty old sourceforge used to
be

~~~
mort96
> I know they have allegedly improved after new owners and a come-to-jesus
> moment, but damn, that was some shady shit.

If Facebook tomorrow started saying they're totally going to stop being creepy
and got a new CEO, I wouldn't suddenly start trusting them either.

~~~
loganabbott
We're a small independently owned private company, and not a single person
responsible for those decisions made years ago is still involved with the
company. It's been over 3 years since we bought SourceForge and we reversed
all the bad decisions on day 1 and never looked back. We still support
Mercurial
[https://sourceforge.net/p/forge/documentation/Mercurial/#pub...](https://sourceforge.net/p/forge/documentation/Mercurial/#publishing-
an-existing-repository)

~~~
mort96
But why buy such a tarnished trademark which has garnered so much ill will
over the years for horrible practices? Is it a form of "all PR is good PR",
that it's better to have a recognized but hated name than to have a name
nobody knows of?

~~~
loganabbott
Most people have gotten the message that things have changed at SourceForge.
We bought it to redeem the name and protect free open source software.

------
jzwinck
Doesn't this mean BitBucket will die? Slowly, sure, but Mercurial support
seemed like a key differentiator relative to GitHub.

~~~
Sean1708
As a data point, our company that only uses git moved from GitLab to BitBucket
literally about two months ago. No idea why (waaaay to low on the food chain)
but I'm guessing it must have some advantages at least.

~~~
vidanay
Most likely you will also see a Jira roll-out soon (unless that preceded the
move to BitBucket)

------
barseghyanartur
This is terrible news.

I prefer Mercurial to Git. I intensively used both for years and I can't say
that Git is any better than Mercurial.

I do think they should at least come up with a plan to seamlessly migrate
existing repositories to Git. Still, shocking.

------
antonyme
What a damn shame. I use git when I have to, hg when I get to choose. The
usability and ergonomics are just so much better. I've never had any
performance complaints. I chose Bitbucket over Github specifically because of
Mercurial support. Unfortunately it's a business decision and they had to make
a tough call.

------
dylanz
I remember playing pool with Chris Wanstrath back in the day and he was
telling me how he just started a product based on Git. I told him to bail on
it and use Mercurial instead! I listed a bunch of reasons why I thought it was
the best distributed VCS. I remember shaking my head a bit thinking: "Whelp...
good luck with that". I probably lost that game of pool too.

------
dogweather
OMG, sad. And I'm part of the problem:

I've always wanted to use Mercurial; I'd always found its user interface to be
an improvement over git; as if it shipped with a great "porcelain" by default.
I respect its ability to leak fewer implementation details while still
offering plenty of power.

But I kept using git for all my projects, and GitHub with it.

------
caiocaiocaio
I feel old. I can literally remember dozens of silver bullet technologies I
was told were necessary to know ("you're not a real professional if you
don't..."), and then forgotten by nearly everyone. All of these were supposed
to save the world and most of these were cutting edge less than ten years ago.

------
gumby
I'm astonished, just because hg _defined_ bitbucket for me. Else its other
features were just OK.

Also, though I never found a reason to choose hg I had been told that it fit
the Windows file system better than git. If so that wasn't enough.

------
burner6565
Since this is likely to attract bitbucket users, I’ll toss out a question in
hope someone knows:

It appears that in bitbucket enterprise cloud, there is no way for me as an
administrator to prevent members of my team from making repositories public to
the Internet. Is that true? If so I may need to look to on prem options, or
perhaps GitHub enterprise cloud which seems to support better permissions. We
deal in sensitive data so can’t risk an analyst publishing them to the net
accidentally.

------
_pmf_
Strange. I would have thought that serving more niche customers would be a
more sustainable business model than competing against GitHub and GitLab on
their home turf.

Is Bitbucket profitable?

~~~
nixgeek
It’s owned by Atlassian but who knows if revenue generated exceeds costs
incurred for that specific product. Somehow doubt they’re going to disclose
that.

Would be nice if companies were transparent about which products and services
made the most money, rather than (best case, public companies) stating
earnings for the whole company and breaking it out fairly opaquely through
categorizations.

On the flipside I could see this being useful information to competitors, and
instructive on which parts of your business to attack.

------
errnoh
The Software Heritage [1] was mentioned in another thread today. They seem to
archive source code from most of the popular locations, but Bitbucket doesn't
seem to be on the list?

If Bitbucket is planning on actually removing Mercurial repos it seems like a
good idea to crawl and archive those before that happens.

[1]
[https://www.softwareheritage.org/archive/](https://www.softwareheritage.org/archive/)

------
thieving_magpie
I have 92 mercurial repositories at my company that I'll need to convert.

------
dreamcompiler
All my software is in Bitbucket for two reasons: Free private repos and
Mercurial. Now that Github has free private repos and Atlassian is removing
support for Mercurial, I have no remaining reason to keep my repos in
Bitbucket. Sayonara, Bitbucket. You just created a Github customer.

------
wooptoo
When I picked up a DVCS years ago I initially went for Mercurial for its ease
of use. It had a clean command line interface and it just clicked with me (Git
still had some bits written in Perl). It worked very well for my small
projects. Its hgweb worked without fuss on top of Apache (which was still
popular). Bitbucket was a small time site back then (about 2008) and I mainly
hosted the projects locally on a web server.

However the industry has voted by putting its weight behind Git and Git has
won. It has caught up usability-wise. Its performance is miles ahead of
Mercurial. While its underlying model is not straightforward to grok it
enables great work flows.

Honestly I'm happy with Git and never looked back.

------
z3t4
Only reason I use Bitbucket is because of Mercurial. I guess that's what you
get for using centralized services. The funny thing is that both Git and
Mercurial was designed to be decentralized! But we humans are social
creatures, and Github is like Facebook for invert's - instead of posting
pictures of your acquaintance you post your software projects. Stars are the
likes ... So in order to fully decentralize, the human/social bit also need to
be decentralized. But there is also the convenience, while setting up Git and
Mercurial hosted repositories is straightforward, I can understand why dev's
choose to use a service instead, especially when it's free.

------
irishsultan
When clicking on the link to "A Community thread to discuss conversion tools,
migration, tips, and offer troubleshooting help", I see:

Article not found

The article you are trying to access is not available.

It may have been deleted or marked as spam.

------
gitbucket
I am annoyed at this news. v1. Bitbucket == Mercurial v2. Bitbucket ==
Mercurial|git v3. Bitbucket == git However, GitHub is better at git, so now
GitHub > Bitbucket

May bitbucket and it's management forever have it sheets and stocks shorted.
They deserve it.

Since I want my repos' outsourced and I'm being forced to use git, I am moving
to GitHub.

Define: git -
[https://www.google.com/search?q=what+is+a+git](https://www.google.com/search?q=what+is+a+git)

------
DenisM
Guess I'm taking my money and going elsewhere, then.

Several things seem really odd to me:

    
    
      - They are ditching one thing that was a safe harbor from github.
      - No migration path to Git inside bb service. 
        If I am going to migrate outside bb I might as well move away completely.
      - Armageddon-style wholesale destruction of the old repos.
        Could have left the read-only repos on a separate server. Or even just a tarball.
    

It just looks so disorderly and thoughtless...

------
fredcy
Damn, this is disappointing. I've long preferred hg over git but developer
preference has clearly moved to favor git. I like using mercurial queues for
managing local config changes but I guess I'll have to get better using `git
stash`. I hope bitbucket provides some tools to easily convert repos from hg
to git. Frankly, though, I'll likely just move from bitbucket now.

------
cosmojg
For anyone looking to jump ship, check out invertbucket
([https://hg.sr.ht/~sircmpwn/invertbucket](https://hg.sr.ht/~sircmpwn/invertbucket)),
a script which automates the transfer of mercurial repos from Bitbucket to
Sourcehut. Support for transferring tickets and pull requests should be coming
soon as well.

------
bovermyer
A friend of mine is a core contributor to Mercurial. He is... well, I suppose
"livid" is as close a descriptor as any.

------
scblock
Enjoy your monoculture.

------
loganabbott
SourceForge still supports Mercurial
[https://sourceforge.net/p/forge/documentation/Mercurial/#pub...](https://sourceforge.net/p/forge/documentation/Mercurial/#publishing-
an-existing-repository)

------
hiccuphippo
Is there any feature in mercurial that git doesn't have? Is there some plugin
to allow mercurial users keep using the client with a git remote repository
(like the one for using git with svn)?

~~~
durin42
1) hg absorb

2) hg-git exists, and there's other things afoot that should be better

~~~
Mindless2112
As a daily hg-git user, could you elaborate on (2)?

~~~
1wd
Hopefully this: [https://www.mercurial-scm.org/pipermail/mercurial-
devel/2019...](https://www.mercurial-scm.org/pipermail/mercurial-
devel/2019-August/132993.html)

~~~
benibela
That would be helpful

I use hg-git to put all my Mercurial based projects on Github.

But the last OpenSUSE update installed Mercurial 5, but left the old hg-git
for Mercurial 4. Now it does not work anymore.

~~~
1wd
On Windows it is broken since TortoiseHG 4.5.2

~~~
benibela
TortoiseHG is really cool

I used to use it all the time on linux.

Unfortunately the OpenSUSE update also removed it. Completely, it is not even
listed in the package management anymore.

No one wants to maintain non-mainstream software

------
mixmastamyk
A disaster for me, I've got dozens of hg repos over there. Do they support an
automated conversion? If not, probably no reason to use bitbucket any longer.

~~~
jobigoud
I'm in the same boat. And Mercurial support was the key differentiator for me,
I'll probably convert the repos to git (hg is almost sure to die after this)
and move to GitHub in the process, including the git repos I have on
Bitbucket.

------
Bellyache5
It seems that Bitbucket and GitHub are trying to emulate GitLab’s strategy of
being a one-stop tool rather than just version control.

~~~
nathancahill
The opposite is true actually, Bitbucket was bought by Atlassian in 2010 to
make Atlassian the one-stop shop, a strategy GitHub and GitLab are emulating
(GitLab launched in 2011).

~~~
dochtman
Seems to me that one-stop shop is very different from one-stop tool. GitLab is
aiming for the latter, whereas Atlassian (at least when I was using those
tools) seems much less integrated.

Jira may be the most comprehensive issue tracker (which isn't necessarily
attractive -- but then they have Trello now, too), but on the version control
and CI front I don't think Atlassian will have an easy time competing against
Azure/GitHub/GitLab.

------
srean
Anyone knows what happened to Spolky's hginit.com ? It used to be one of the
most accessible Hg tutorials out there.

~~~
epalm
I also miss hginit.com. I've been referring new devs to
[https://web.archive.org/web/20180924182907/http://hginit.com...](https://web.archive.org/web/20180924182907/http://hginit.com/)

I guess hginit.com disappearing was a signal of things to come.

------
kissgyorgy
Mercurial is officially dead.

------
j0ba
This is disappointing. Bitbucket is _the_ premier place to host free private
mercurial repos. Just look at the hosting page on the mercurial website. There
is literally not a single other place for free private hosting. There may be
some smaller ones out there I'm not aware of.

Hacker news, question: Have you ever tried mercurial? Don't you like to save
keystrokes? Isn't `hg com` easier than `git commit`? Isn't `hg pul` easier
than `git pull`?

Is there any way to shorten the amount of keystrokes to use git?

~~~
chronial
> Is there any way to shorten the amount of keystrokes to use git?

Sure, you can just set up aliases in your shell and in git. Set an alias in
your shell for git → g and in git for commit → c and you can commit with `g
c`.

~~~
j0ba
Awesome, wasn't aware of git aliases. Thank you.

~~~
Arnavion
Just be careful that if you define an alias that shadows a built-in command,
your alias will be (silently?) ignored. Mostly a problem if a future version
of git adds a command and clobbers an alias that used to work.

