Hacker News new | past | comments | ask | show | jobs | submit login
Sunsetting Mercurial Support in Bitbucket (bitbucket.org)
357 points by ingve 32 days ago | hide | past | web | favorite | 355 comments



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.

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


git was deliberately designed around the "known fast" things in Linux.

One of those is that path name lookup for certain file attributes is dirt cheap because of the dentry cache.

Since Windows doesn't have an equivalent, git is going to be slower there.

Hopefully the Microsoft people working on this will find ways to make git on Windows faster, since even with a much smaller repo (LibreOffice), git is somewhat painful on Windows.


> Hopefully the Microsoft people working on this will find ways to make git on Windows faster

WSL2?


my takeaway of the demo I saw on WSL2 at the Microsoft conference was basically several hours of engineers salivating over how much faster git was on wsl2


>several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.

That one at least is fixed now, by having an option to disable it.

https://github.com/git/git/blob/v2.23.0/Documentation/config...


That git setting is for `git status`, but I think `git checkout branch` still doesn't have a comparable option either on the command line or in a git configuration file. The closest you can get is to turn off all output with `git checkout -q`.


Oh yes, I just tested it out and you're right. Bummer.


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?


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.


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


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


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


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.


The Windows tree is unlike the Linux tree in that the Windows tree is the entirety of Windows, not just the kernel. Not having to check out the entire tree is why GVFS was made.

https://github.com/Microsoft/WSL/issues/873#issuecomment-425... talks about why Windows I/O for multi-file operations is slow in general (as opposed to sustained I/O on a single file).


I read an article a while back about why git is slower on windows than on linux (probably linked from HN, but I can't find it just now) and the TLDR is that it's because the windows filesystem (not just NTFS, but everything around it) has many customization points, and for that reason git will always be slower on windows regardless of the particular underlying FS (as in, adding windows support for, say, ext4 wouldn't fix the problem).


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 started with CVS then moved to svn.

When I was your age we used RCS and SCCS, in the snow, up hill, in both directions. :)

Seriously, I have no doubt git has an awesome on-disk format, but whenever I use the git(1) command I want to slit my wrists. I'm sure if a developer uses it many times a day it's possible to get used to it, but as a sysadmin that only uses it sporadically, I basically do:

* git clone

* vi repo/some/file/blah

* git add/commit/push

* rm -rf repo/


I'm in the same camp of rm -rf'ing (and when I were a lad we did all our computing on relays...). A fun game to play when you have spare time is to Google for how to do some random thing with git then pour up a cup of coffee and read through the 17 contradictory answers on just one SO page...


As a sysadmin (as am I), you should know how git works so you can fix it when the devs break it. :)

What do you find difficult about it?


The format of a command is `git <action> <options>`, and the <action> is completely baffling to the RCS/CVS/SVN habits I've built up for the decades.

For the little while that I sometimes used Hg I found it much easier to get my head around.

It's mostly a lack of practice/use.


I just use a bunch of aliases to make sense of things. eg "new-branch = checkout -b" and "branches = branch".


Order of my exposure to SCM

  Shared windows mount
  Visual Source Safe
  CVS
  SVN
  Perforce
  ClearCase
  Git
  Team Foundation Server
Of those I still use Git and SVN. Aside from the shared network drive, VSS and ClearCase are in a dead heat for the worst SCM I have been exposed to.


Visual Sorta-Safe, we used to call it.


Tell bob he needs to check in the file so I can work on it.


Throw in SCCS, on SCO Unixware, and Darcs, and you match my exposure too, mostly. Now I remember what an abomination VSS was - with the mandatory locking behaviour.


It wasn't mandatory, actually. It was possible to turn off the locking. But that was like entering a whole new world of pain. So most people didn't dare turn it off.

They called it "multiple checkout", and the manual strongly recommended you do not turn it on.

The software had issues with corruption due to operations not being atomic.


The lack of atomic commits in VSS, CVS and ClearCase caused absolutely horrific problems, even on small teams.


I remember when you basically had to yell "Committing!" and "Done committing!" to the whole room. Woe be unto those companies that tried to use VSS or CVS with more than a roomful of developers.


I can live with the locking behavior, but VSS had a tendency of corrupting the entire repo ever few weeks that is hard to accept.


I could live with the locking or the corrupted repos if it was half decent at just sharing code, but daily we had problems where someone would check in code, VSS would say it was checked in but the person updating would get stale versions. Sometimes if you looked at the server version it be be correct but not what you would receive on a fresh checkout.

It was literally less functional than copying to a shared drive. Of course management and other developers refused to believe that OSS solutions were better, MS ecosystem developers were an extremely insular group.


Yes, there was that too. I've seen quite a few regressions caused by this.


I feel blessed to have started with SVN and Source Depot (msft) and only come across CVS and Perforce on rare occasions.


Source Depot is very similar to Perforce since sd started as a p4 fork.

Incidentally, I remember one person at Microsoft who claimed to be involved in the decision to adopt sd circa 1999 saying that Microsoft has the right to turn sd into a product if it so chooses. (He/she was responding to contrary claims made on an internal email mailing list which was very widely read, so I assume if he/she was misremembering or lying he/she would have been called out.) Though ultimately MSFT made VSTS/TFS version control instead, which has striking resemblances in concepts to sd/p4.


Interesting. It wasn't a bad solution at the time, being able to pass around commits was nice and more straight forward than the patch mechanism on svn. Git and Mercurial were significantly superior solutions though.


Source Depot == Perforce


As a sysadmin, how do you version your infrastructure code (things like puppet or terraform)? If another VCS, cool. If not at all, try git for it!


Some people on the other side of the Unix/Microsoft tracks started out on sourcesafe.... shudder


raises hand

dunno, I like git better, but at the time it did what our small team needed. Granted, we always ran into issues with one of us having a file locked that someone else needed, but onboarding was a breeze.

I'm glad I use git now, but Sourcesafe was an okay introductory source control solution.


Do a shallow clone and you’ll save some time.


I started with CVS in HS on a couple SourceForge projects, but skipped svn for the same reasons I used CVS sparingly: setting up servers was too much effort, (especially for non-open source stuff), especially on Windows. Instead of svn I fell hard in love for darcs in college (after the usual college tale of losing source files the day before a project was due in a stupid unix tool mishap with a command line that was one letter off from what it should have been).

Watching hg and git grow up and compete as a darcs user was fascinating. Neither hg nor git had the elegance of the darcs UI (and arguably never will due to disparities in the underlying distributed code model), but it was clear from very early on that both hg and git were beating darcs on performance for large, active repositories. (Which was never a problem for a college student working on teams of maybe 1 to 3, but obviously a hard recommendation for the real world.) I experimented some with hg at the time because it had good Windows support, but had no reason to switch from darcs in college.

My first couple of jobs after college had me spending a lot of time in TFVC, and that eventually that lead to a much greater appreciation of git (and pushing teams to migrate from TFVC to git), and by that point TFS had already starting supporting git side-by-side TFVC, though ironically those same teams pushed hard for GitHub Enterprise. (Which does seem to underscore that git and GitHub really were so co-beneficial.)

By that point a lot of what hg had done right the git team was starting to pick up. At the very least, we should remember hg for pushing git to be better.

(As one example, someone else pointed to `git stash` as something that they didn't think hg had, but as I recall `mercurial queues` [MQ] was one of the earliest hg plugins, and MQ influenced the designs of both `git rebase` and `git stash`, and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ.)


>and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ.

I believe those have been deprecated in favor of the evolve extension.

Mercurial is my goto for version control. However, in my experience, the information on the ideal tools/extensions is very scattered. The Mercurial book is 10 years old! For example, few mercurial users make use of branches for throwaway work - they use bookmarks. But how is a new user supposed to know that?


Neat. I was unaware of the evolve extension. It's interesting to see things continued to progress since I last read anything on the subject.

All the documentation I spotted currently still lists evolve as "experimental", and that doesn't help with any confidence of which tools/extensions to use in day-to-day operations, on top of how scattered the documentation is. It is interesting, perhaps how hg has a better UI, but git has always had arguably more consistent documentation.

(Similar too, both hg and git are built as sets of "plugins" to the core CLI but hg requires much more explicit installation and git just bundled a lot of them directly together and implicitly runs anything that even looks close [any script in the PATH that fits git-command may be run for git command], making it less clear which hg commands to use despite the better general UI, and easier to get started in git with a smorgasbord of commands.)

I somewhat remember the Named Branches versus Bookmarks discussion/confusion thing from the last time I attempted to use hg. It sounds unfortunate that it still doesn't seem very well documented or well explained this many years later.


>All the documentation I spotted currently still lists evolve as "experimental", and that doesn't help with any confidence of which tools/extensions to use in day-to-day operations

I believe it is bug free, and fit for real world usage, and has been for years. If you read the details, the issue is there is a chance for performance degradation, and they consider that as "backward incompatible".


Git was successful before github. I’d say Github was successful because of git!


I was going to write this exact comment. I'm sure the "marketing" of "Linus Made!" and "used for the Kernel!" did git some favors, but git is technically superior in my experience, despite UI short comings.

I'm sure it's changed now, but the lack of cheap fast branching was jarring.

I think many UI fetishists forget: Good UI helps begginer adoption but has to be incredibly way better to drive any readoption. But professionals will often have to suck it up and use a shitty UI if it means solving a technical shortcoming better.


And perhaps because there is no good offline ui for git

So you end up using github as ui, even if you do not want to use a webpage


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


I've been using hg since 2012 on a few decent sized repositories, and it has never been anything other than immediate.


I've got a 1.2 GB repository and it's pretty fast for that once you set Watchman up to cache tree changes. It's dog slow without that little added step though, mostly because there are a ton of small files.


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

[1]: https://en.wikipedia.org/wiki/Videotape_format_war


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


It does: change evolution. It's very good.


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


> Thats like saying McDonalds is the height of cuisine, because “Billions and Billions Served”.

Actually, it's like saying that those billions are comprised of a hefty number of people who tried both and the vast majority determined that overall git is an unquestionably superior tool due to a combination of the tool itself and it's ecosystem.


OP> The real lesson is that once a technology [loses], the people who invested in the [loser] will run around forever calling the [loser] better.

rumanator> [...] those billions are comprised of a hefty number of people who tried both and the vast majority determined that overall git is an unquestionably superior tool

The majority doesn’t determine every persons taste. Git is the dominant DSCM; it’s well represented. Why be so defensive if some minority likes hg semantics?


I'm sorry to be pedantic but you've used "loose" incorrectly 3 times in a row. It's "loses" and "loser"


Not pedantic. English may not be OP’s native language, so tips like yours can be helpful. I found the rest of the comment to be insightful and true!


100% native English speaker... And 100% dependent on modern spellcheckers.


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


Yeah, my experience fits. I spent about 6 months at my first job trying to understand and use Git with AOSP. In contrast, my second job used Mercurial and I learned how to do everything Git could do in about 2 weeks, then never looked back. I always groan when someone has to use Git.

I think people tolerate Git because they really like Github.


> I think people tolerate Git because they really like Github.

I mean, I'll add to the pile of anecdotes this thread is accumulating but I don't know if it'll convince you that people are genuine:

I struggled to learn git, but it was also my first VCS. I've needed to muck with hg a few times and vastly prefer git. Hg was fine. It didn't win my heart or anything. But it also didn't let me (at the time) branch as quickly and trivially and it was slow as hell.

Sure, that need/want may not win a hg user to git, but I'd hardly call that tolerating git.


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.


Are you working on a Linux system? I have the opposite experience with Sourcetree and Gitkraken on Windows -- git is the least responsive tool I use.


Git is the only fast tool in that stack, it's slow because of the trinity of ntfs, electron and c# that those tools are built with. When you've got slow tools on a slow file system you're going to have a slow time.


If performance mattered, people would not have adapted electron


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


Mercurial works correctly but is unbelievably slow compared to git.

If you don't think about performance ahead of time (preferably at the algorithm level) then you will build something correct but slow and it'll be very hard to make it fast without redesigning major parts of it. It's possible to make design choices that paint you into a performance corner very easily, especially with something designed to work on a lot of data. O(n^2) might look like O(log n) for small data and in testing.


From the Knuth paper:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

It means make it fast in the code that matters, do not try to make it fast in every single line.

To say the quote is often misunderstood is the biggest understatement in modern computer science.


I think any good advice in software development will be widely misunderstood. At lest, I haven't seen any that wasn't.


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

https://www.youtube.com/watch?v=ddYZITaxlTQ


There's also Phabricator as a self-hosted (and open source) solution for Mercurial (and Git and SVN) repositories.

https://phacility.com/


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.


> technically better architecture and user interface

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


Things like interactive rebase in Git are revision control UI innovations with a massive impact on my ability to deliver quality PRs.

Git feels like a tool I can use to create and mould meaningful commits that best convey intent. Mercurial feels like it wants to just make a literal log of what I've done, which is a bit simplistic and isn't the same as what I want to present when my code is ready.

I also find the model of Git much easier to understand and explain to others.


Mercurial copied interactive rebase from Git a long time ago and refined it with phases[1].

What do you find easier to understand and explain about Git's model?

[1] https://www.mercurial-scm.org/wiki/Phases


Yeah they copied it. They copied it because it was better. Do you think that they copied it because it was a bad UI idea? Not sure what your point is.

And great question about the Git model, after mentioning 'phases'! Mercurial has about a billion concepts and nouns for different random things like that. It takes forever to explain all the random ideas they've piled into it in an attempt to keep up with Git.

Mercurial think they can fix everything with yet another plugin and new concepts and nouns. Git built a cleaner model where you don’t need these plugins and abstractions.


How does Mercurial feel like "it wants to just make a literal log of what I've done"? It has a UI very similar to Git's for rewriting history and a feature specifically to help do it safely.

Git copied things from Mercurial too. I don't think Git having a feature Mercurial didn't in 2007 means "Git turned out to have the better UI and architecture".

Git still has the problem Mercurial phases address.

A lot of Git users are annoyed that Mercurial branches work like other systems instead of Git and that it calls Git branches "bookmarks". New users understand Mercurial branches much more easily in my experience.

Mercurial queues are complex but only needed for workflows Git doesn't support. They're an extension so that most people don't even need to know they exist.

Do you have any other examples?


> How does Mercurial feel like "it wants to just make a literal log of what I've done"?

Because rebasing was literally an afterthought - a plugin. I don't think I ever push commits without rebasing them a few times. There's also now about six different ways to rewrite your history in Mercurial. It's a mess. Git has one way to do it and it's a normal part of the system.

If a Mercurial user asks me how to tidy up their history my answer is 'er... well there's rebase, mq, histedit, evolve...' that's a lot of options to teach people. In Git I just show them rebase.

It's all subjective isn't it? For me, less concepts, nouns, and plugins adds up to a simpler and so better architecture and UI. Maybe the extra concepts are what floats your boat and that's fine.


> Because rebasing was literally an afterthought - a plugin

Hg extensions are just as much part of hg as the core functionality. It's just that they're opt-in parts many users don't need and thus don't have to see. If your workflow requires history editing, then fine, enable rebase and histedit.

As for mq, I think I've only used it in a script where I converted an ancient CVS repo and rewrote entire parts of the history to remove stuff that should never have been in there to begin with. It's powerful, but rarely required by anyone, and thus is opt-in as well.


I like git’s architecture better — hg’s exposure of revision numbers needlessly tangles branches together and makes anything that creates throwaway commits messy.

But git’s user experience is IMO gratuitously awful. Trying to keep track of all the various things that checkout and reset do leads mainly to frustration at the design. And I see no reason that use of the index should ever be required.


Good news, in the latest git release checkout has two new friends that split checkout's functionality: switch and restore. Plus, they have much friendlier flags for knowing if they are affecting the index, the working tree, or both.


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.


Linus (and linux) was the key marketing; github and MS followed.

Again due to linus/linux community, git has amazing polish (efficiency, error messages, docs) of a superb data model and brepus user interface.


Google contributes to Mercurial as well.


As do Facebook, if I recall correctly:

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


Piper still exists, but Mercurial is a viable client tool to interact with Piper's version history.


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.


Another way to host Git code using 100% FOSS software is with https://sourcehut.org/ and of course it’s possible to host your own GitLab community edition server as per https://about.gitlab.com/install/


Sourcehut supports mercurial, too!


The UI is a hot mess though. Every time I try out their Mercurial site (it's actually a separate site, not just a feature of the main site) I always somehow end up on the Git part of the site and there's no obvious way back.


Moreover, SourceHut also is the only system that supports[1] both FreeBSD and OpenBSD as CI platforms. NetBSD is coming soon too.

[1] https://man.sr.ht/builds.sr.ht/compatibility.md


Another happy user of Kallithea here!

I used to run Rhodecode some years ago, and switched to Kal when they forked. At this point I wouldn't be without it.


Kallithea was an option 2 years ago, now the development of it is basically dead. Rhodecode is still releasing regularly. Just check the feature differences: https://rhodecode.com/blog/133/rhodecode-vs-kallithea-compar...


Who says development is dead. Please check the changelog.

https://kallithea-scm.org/repos/kallithea/changelog

Now lets look at Rhodecode. https://code.rhodecode.com/rhodecode-enterprise-ce

You will notice that Kallithea has been consistently updated regularly. Besides user like me its also used internally at Unity Engine.

Also the features you mentioned not all are in Rhodecode open source edition.


I'm not really following the "commits" but rather following releases. In the last 2 Years Kallithea had only 1 minor release (https://pypi.org/project/Kallithea/#history) 0.3 -> 0.4 without many new features. RhodeCode had 5 minor releases (https://docs.rhodecode.com/RhodeCode-Enterprise/release-note...) and multiple bugfix releases. I'm aware not all features in comparison are free, but we use the CE free version and it's enough for us at this point.


Actually 0.3 to 0.4.1 is a major release with many changes including new mercurial versions and better git support with updated UI and celery for background tasks. If you see a new ssh feature is just added with documentation.

Kallithea is pretty easy to work with and extend. We recently updated and built a CI using buildbot. Rhodecode and Kallithea have diverged enough and are moving differently. Also its a Software freedom conservancy project so it will be supported, hopefully it can attract bit larger community.


On a side note on this. I think Unity had their own fork of Kallithea with some changes that aren't in the official version ? Or those features are backported later from the Unity release


I believe some of the unity developers are constantly creating pull request to update Kallithea and are core developers.

Can't say for sure but I think Unity's system Ono is using Kallithea as core with additional plugins developed for their own use.


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
(Replace foo, bar, and baz with real names)


One-liner to change the URL of the upstream repo:

    git remote set-url origin <new URL>


    # Add new remote location
    cd bar
    git remote add neworigin https://newserver.com/foo/bar
    git push --set-upstream neworigin master


And what about the issue tracker? Issues and discussions of pull requests would be lost by merely moving the code.


I'm working on this, have a look at https://github.com/MichaelMure/git-bug


you can import github projects including issues and stuff into gitlab

https://docs.gitlab.com/ee/user/project/import/github.html


Some thing would be lost, yes [1] but the core code and commit history would be preserved. Issues can still be re-opened if still relevant, and pull requests can still be seen in the commit history. Comments on pull requests, if not approving a pull, will result in additional commits to the code which will be preserved.

Whether this is OK for a given use case depends on how important ticket and pull request comment history is. For open source projects, I don’t consider that kind of history nearly as important as the code itself, since a lot of issues are wishlist requests, support requests, or downright spam.

[1] Including branches unless one runs a script to go to and clone each branch to the new repo


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.


I still write my software in Pascal and store it an Mercurial repo on Sourceforge

It was just the best development environment on windows


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.


Mercurial lets you pull and even update with outstanding changes.


This is one of my biggest pain points with hg vs git: Git is actually the one that flat-out prevents me from rebasing most of the time, usually for the most spurious of reasons, whereas hg just lets me choose to auto-rebase most files and pick the ones I'm interested in to manually merge.


And makes a mess of conflicts. I would rather not be able to do those things than to fix a conflict of a head with the working files on HG.


> doesn't let me pull or do other stuff

Not sure what that means?


It just doesn't let me do things with changes in the working copy sometimes where git does. It's really annoying.


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.


I've lost a day's work to a mistyped "git revert HEAD~n"; my colleague blew away his month's work with a mistyped attempt at a squashed commit.

Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try.

Management asked "what if you do that with Mercurial?"

Answer is, well, it won't let you do it without installing an extension. And the Wiki page for that extension contains a bunch of warnings about how you really should think long and hard about what you're trying to achieve -- and make as many backups as you can.

TRWTF of course is that my colleague hadn't pushed upstream for a month. Like I said -- former Subversion user. He didn't want his commit to mean someone else had to do a merge, and he didn't want anyone to see it until it was done.


> Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try.

Was "asking someone who knows how git works" on your list of things to try?

What about "learning how git works"? Was that on your list?

Frankly, you don't seem to have been trying very hard to get this work back.


> Was "asking someone who knows how git works" on your list of things to try?

If I can make an analogy.

There's little love lost on HN for C++. Anytime people mention C++ (possibly even here in this thread) people come out of the woodwork to talk about how hard it is to use, how it has too many features, blah blah.

I work in C++ every day. I don't think it's that hard.

When I have a question, I walk over and ask Chandler Carruth and Richard Smith. They are happy to help me debug my templates. Richard is the editor of the C++ spec, and Chandler is a well-known speaker, look him up on YouTube.

Over lunch we talk about new features of C++, we rant and gripe, and I learn.

Most people do not have Chandler and Richard in their life. Knowing them and the other experts on my team is a huge privilege. So when someone complains that C++ is too hard (wait for it, someone is going to do it here in this very thread...), it would be pretty insensitive of me to tell them that they should just ask someone who knows how C++ works.

Most of us in this thread do have someone in our life who is good at git, who helped us get started, and who saved our asses when we initially got stuck. Maybe that person isn't with us IRL, maybe that person is "just" a message board or IRC channel where we know we're welcome. But this too is a privilege.

If you've ever had trouble with anything and not had someone you could ask -- be it with C++, or real analysis, or whatever -- then I'd say you shouldn't throw stones at someone whose "whatever" happens to be git.


Ok, then I'll give you an analogy in return:

Someone posts that they'd tried to join two strings in C++ and print the result. And they couldn't figure out how to do it; they would keep losing the second string. So, they gave up and changed languages, losing a month's worth of work.

Would you think that was reasonable, because they didn't have Chandler Carruth and Richard Smith available to help?


> Would you think that was reasonable

The thing I object to is judging them at all.

They're not my coworker, someone I have to rely on and therefore might be annoyed if they're unproductive or whatever. They're a random person on the Internet who rather humbly admitted to making a mistake out of ignorance.


Completely agree. Furthermore, I'm able to keep C and Common Lisp and most of Javascript and a bunch of other languages and Mercurial in my head (brain cache) so I rarely have to ask somebody how to use them.

But try as I might, I cannot do so with C++ and git. They just make no logical sense to me.


To be frank, your sales technique needs work.


To be frank, I've no interest in selling anything so don't need a sales technique. To be franker, I think the OP was talking crap. No-one loses a month of work and doesn't think to get advice on how to fix it. It's just a stupid "git is bad" story.


That's not the point, the point is that Git is a really bad interface to a really powerful system.


Have you tried to operate an excavator? That thing is complicated compared to a car... But you know what? That is specialist tool. If you cannot operate with specialist tools you should not get a job of a specialist.

I just had to write that rant out: https://wordpress.com/post/squarebits.wordpress.com/76


I'm quite adept at driving an excavator. I can pour wine out of the bucket of an excavator. It's quite easy with practice because muscle memory kicks in.

But if excavators were as hard to use as git, I'd never have mastered them.


I wouldn't say "programmers who use version control" are a group of people who would qualify as "specialists". Especially since all programmers should be using version control. It should be a fundamental skill necessary to entering the field.


This was years ago, when Git was relatively new (around the time Mercurial was at v0.8-0.9).

Our "Git expert" was the one who blew away a month of work.


> I've lost a day's work to a mistyped "git revert HEAD~n"

Mistyped as "git reset --hard HEAD~n"? git-revert is usually pretty nondestructive…


> I've lost a day's work to a mistyped "git revert HEAD~n"; my colleague blew away his month's work with a mistyped attempt at a squashed commit.

Don't you have backups? The companies I worked for had backups for all the home directories, so if I deleted something I could ask the admins to restore it.

If there are no central backups I would sure as hell set up a local backup, so there are more than one copies of my work in case something goes bad.


You know that you can revert a revert, right?


Fuck that guy. Seriously if someone is in silo mode for a month I am going to fire that guy.

He is doing either some dangerous changes, which is not acceptable OR he is doing something that could be walled off by feature switch and integrated with at least weekly commits.

If it was some manager that told him to do that, fire that manager too!


> Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try.

...so you thought you lost a day's or a month's work, you didn't actually lose it.


No, we lost it after he tried to "fix" it when the commits disappeared...


> git revert HEAD~n

You could just revert your revert commit, or check out an earlier revision.


> While it's easy to blow away work you haven't committed

This is bad enough. Git treats your workspace as trivial that can be replaced willy nilly.


I don't believe hg is any better in this respect.


I can tell you that it is in at least one use case that I've hit. If you have local uncommitted changes to a file, and then run `hg revert file` to undo your changes, it creates (by default) a ".orig" backup. The equivalent git command (`git checkout --hard` or something?) will just throw out local changes with no takebacks.


I would absolutely love it if Git had this feature. Having it on Hg has saved me so many times.


> every commit you've made in the past month is saved in the reflog

I've heard this before. But since I seem completely unable to remember what a "reflog" is or how to use it, I always just copy my entire repo to another part of my disk before I do anything dicey with git (like rebase). This is of course ridiculous, but for me it's an easier workflow than "oh shit, I screwed up. Now I have to spend 2 hours on Google and SO trying to figure out how to get it all back."


Just in the case you didn't know, you can view the reflog with `git reflog`

From there you can grab the commit SHA1s and view their changes with `git show ${SHA1}`, cherry-pick them to your working branch, or whatever else you want to do to recover them.


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


I've never worked at a company with protected branches... even though it's best-practice. "Because some day someone might need to push to master to do a hotfix".

So I have a local git push hook which blocks master pushes :)


> Git will let you blow away a month's work if you mistype a command.

Fortunately, that can always be undone with another command


How to undo

    git checkout .

?


The only way for `git checkout .` to blow away an entire month of work is if you didn't add or commit anything for an entire month.


Fair enough ;)


That's like asking how to undo `rm -rf`


It really is. Sure, it is an issue that it's the same subcommand as you use for many other things (which is being worked on with git switch/restore), but there is no other context where you'd do `git checkout .` if it wasn't your direct intention to get rid of changes in your workspace.


Mercurial creates backup files though.


> Git will let you blow away a month's work if you mistype a command

What's the command to mistype?


Maybe git push -f my-branch

I can't imagine having a month of work on a local machine that hasn't been pushed anywhere so it has to be something about pushing.


One thing I love about git is how it makes it almost impossible to lose work once it's committed. That's why I commit early and often.


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.


The problem, as I understand it, was filenames were read and written as bytes. That's fine if everybody is on the same platform but it doesn't always work when moving between, for example, Linux (UTF-8) and Windows (UTF-16).

I don't know if that's still an issue.


Hm, the Mercurial wiki does mention that's it was/is a problem on Windows.

I was surprised because we've been using it for years at work, sharing repositories between Linux and Windows, and we have never been bitten by this. Maybe the latin-1 subset of Unicode works? Or all the files we worked on just happened to have ASCII names (despite us being mostly non-Americans).


Unfortunately, on Linux, filenames are actually bytes, not utf-8.


Well yes and on Windows they are a sequence of 16bit values, not utf-16. My point was the encoding of filenames differ. So you can't do a byte-for-byte copy and expect the same results across platforms.

As an aside, it'd be perfectly legitimate for Mercurial (and git) to reject filenames that aren't representable in unicode.


Various languages mean letters other than ASCII. They don't on Windows.


And yet people overwhelmingly chose Git. Why is that?


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 ;)


It’s even more specific than that. GitHub chose “free public repos, paid private repos” as their business model and git as their DVC. Bitbucket chose the opposite.

GitHubs model is incredibly more viral and thus git won (sadly IMO).


Bitbucket had free private repos and free public repos.


Interesting, would like to hear more about why that is?


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

* 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


> Github had a stronger association with open source than Bitbucket (dunno why though).

Early on GitHub gave out free public repositories, but Bitbucket gave our free private repositories. Working in public is aligned much more closely with open source than working in private is.


As others have mentioned before, one possible reason could be performance, git commands work near instantaneously even for very large repos, perhaps mercurial was not able to offer a similar experience.


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


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


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.


git was faster.

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.


At this point, network effect


Network effect and first mover advantage.


But they were both released at around the same time. Or at least near enough that they were both serious contenders for awhile.


Mercurial was a bit slow in the first years.

It's still probably slower for huge repos (I havn't checked), but I doubt it will bother you much nowadays.

I used Hg before Git professionally, because when they were both new, Hg had _much_ better Windows support.


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.


This reminds me of patio11's analysis of tarsnap from a few years back: https://news.ycombinator.com/item?id=7523953

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


That's especially weird since serving Mercurial repositories in read only mode doesn't require any infrastructure apart from a static HTTP server.


Full bullet text:

"""

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


I don't think it's about disk space at all.

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 don't need to allow browsing it; but at least have a minimal page which shows the presence of the repository, and allow cloning it.


Or just provide a link to a tarball download.


Cloning it still runs code they don't want to run on their servers.


No. You just need a dumb webserver, no extra code needed.


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.


The Mercurial data model is a superset of git's. A lossless conversion is simply not possible in that direction.


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.


They link to an SO survey:

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


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:

https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_19...


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


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

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


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


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

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


Thanks for the feedback! Fixed on both counts.


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.


Only the readme is rendered as markdown right now.


Thanks.


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!


man.sr.ht has an API which is equivalent to git.sr.ht's API except for the portions which deal with querying git data:

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.


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.

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


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


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.


Move your repos to hg.sr.ht: https://hg.sr.ht/~sircmpwn/invertbucket


I'll consider it, thanks for sharing.


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.


Yep, wholeheartedly agree that it will have a bad impact. However, to me Git is nothing I would use voluntarily in my spare time as it is so hostile to its users (not to mention the conceptual shortcomings and outright questionable "features"). So for me it will be Mercurial and if that means helping out with Heptapod and/or other projects, so be it.


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


The buzzwordiest always win because managers seem to rely on whatever comes up first in a web search. And that's typically Scrum, not Kanban. It's Git, not Mercurial.

Managers won't have to work with the tools they impose on their subordinates. It's the subordinates who have to. But I have also noticed how a lot of people profess to "like" Git for spurious reasons like because it's (allegedly) "so powerful", but then they stick to the simplest workflow possible, because they don't have a clue about intermediate or advanced uses. But that same logic can seemingly also be applied to why C++ "won" (not that I dislike C++ as much as Git, though). The charm is in how powerful it seems to be, but then you use loads of third-party abstractions and throw the alleged performance benefits out of the window.

For an SCM tool I want it to stay out of my way. It's meant to assist me in doing my main job. An SCM should not require my attention all the time because of the shitty CLI, inconsistent subcommands, horrible and incomplete documentation seeping with tool-specific terminology (see man gitglossary) and incomplete (or unidirectional) support for important features (git clone [here] [there], git push to remote with worktree).

Git manages to always require ones attention, and typically in the worst way possible.


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

Like what? I've been using git for 5 years and I hardly ever stray from the set {push, pull, reset, checkout, rebase}. I use VSCode for staging, committing, diffing, etc. though, so that probably spares me some commands, but I rarely (if ever?) have had to do what I would consider an "arcane" command.

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

Git has improved over time. Why, in the latest release they improved UX for the "checkout" command. Before it could mean "switch branch" or "restore file" but now there are 2 explicit commands: "git switch" (for switching branches) and "git restore" (for restoring files).


How do you create a new branch? Still git checkout -b?


Under the new commands you would either do:

`git branch <branch name> && git switch <branch name>`

or

`git switch -c <branch name>` (create and switch)


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


You may be interested in OpenBSD’s front end *(uses the git on-disk format, apparently)

https://gameoftrees.org/


Trippy, it seems like advancing sideways...


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


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.


That's a good point. I could probably strap together click and Dulwich and bang out something in a day or two.

https://palletsprojects.com/p/click/

https://click.palletsprojects.com/en/7.x/

https://www.dulwich.io/


> Don't tell me is for "speed" or "features"

In this case it was speed. Git respected the time of it's users and hg respected the time of it's developers more, it's in no way surprising that users picked git.

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

IME the only people that struggle with git are people that refuse to learn it, properly learn it and not "pick it up as you go". It's such a small time investment that pays off for any professional.


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/


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


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.


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.


You just got another paid user. I am very much in the amateur hacker camp, so I might not add much revenue. Anyway, thanks for sourcehut. Mercurial is my preferred way. I have managed to shoot myself in the foot so many times with git that I just gave up on it and since it is my hobby I don't want to spend much time with git.


Welcome to sourcehut!


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


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


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


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. :)


Including durin42 himself ;)


well, you just addressed this message to the current lead maintainer of Mercurial, who happens to be a fellow co-worker of yours ;)


Please correct me if I'm wrong, but I think it was in "The Hundred-Year Language" [^1] where @pg argued for performance as a language design feature. He could have meant a different kind of performance though.

- [^1]: http://www.paulgraham.com/hundred.html


Have you aliased `hg` to `chg` (built-in I believe). That solved things for me.


I hadn't heard of this! It definitely helps with startup time.

    $ time hg help > /dev/null

    real 0m0.232s
    user 0m0.196s
    sys 0m0.033s
    $ time chg help > /dev/null

    real 0m0.081s
    user 0m0.003s
    sys 0m0.000s
But because an empty `hg diff` takes 1.3s for me, taking 150ms off the top isn't a big help.

    $ time hg diff

    real 0m1.383s
    user 0m0.558s
    sys 0m0.333s
    $ time chg diff

    real 0m1.224s
    user 0m0.003s
    sys 0m0.007s


Part of git's success might be due to its initial association with Linus.

Which I would find mildly ironic, because Linus initially was one of the last prominent holdouts against version control systems, and then made (in my opinion) a very ill-conceived decision to go with a commercial version control system that effectively made it harder for non-prominent, non-paying developers to contribute.

So when he decided to build his own version control system, I'd say it was not a foregone conclusion that he was a particularly qualified expert in the field. But in retrospect, the technical architecture underlying git has held up well (the UI maybe not so much).


I'm reminded of that article I read on HN a few months ago about how "you're not Google/Amazon/Facebook" and you probably shouldn't base your technical choices on what these companies are doing because chances are that you have a massively different usage profile and very different priorities. Still, everybody wants to be like the big guys (dress for the job you want, not the one you have) so you still often seen small-ish websites using a ridiculously overpowered and over-architectured backend.

I think there's a bit of that in Git vs. Mercurial. Git was built specifically for the Linux kernel and it shows. Most of its quicks and features make sense in that context. But the thing is, the overwhelming majority of projects out there are not anywhere similar to the kernel. They have fewer contributors, there are generally much more centralized, they don't use 90's style mailing lists, they don't deal with dozens of millions of lines of code etc...

I think for that "silent majority" of projects Mercurial was a much better choice indeed. It's simpler, for a long time it was much better documented, it was also easier to migrate from SVN and other centralized version control systems. But Git was cooler, it's what the kernel used, and if it's good enough for the kernel then it's good enough for me!

That being said at this point it's clear that Git has won. I've been slowly migrating my (active) projects to Git over the past couple of years. I'll have to use Git one way or the other anyway, I might as well try to uniformize my workflow. RIP Mercurial, you deserved better.


There are similar patterns in other industries. Manufacturing tends to fetishise the automotive industry -- so an absolute mountain of changes come from "well Toyota's doing it" or "well BMW is doing it". Of course, they're great solutions for building cars, but not so great when you're building TV remote controls.

I wouldn't say Git has "won" or Mercurial has "lost". Hg still sees a lot of active development from the maintainers. As do Subversion, Perforce, and so on. Heck, ClearCase is as old as the hills and even that still has an active user community.


Use everyone's favorite Sourcehut, which works with (not against) the mail-centric workflow of Git. (Or use Mercurial on Sourcehut.)


On the other hand, the software development version of the maxim "dress for the job you want, not the job you have" could easily be "use the tools the job you want uses, not just what you can get away with".


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

For me, and I suspect for a lot of developers, the single biggest advantage of git is that it is fast.


I'm not so sure really, in my experience the performance difference only becomes noticeable if you have a very large repository. For the Linux kernel I'm sure it matters, for "my library with 100 commits and 10k lines of code" it won't make a significant difference.


Most commercial projects are orders of magnitude more complex than that, and the performance differences are stark.


I have worked on many projects where I have wished that git was faster. It doesn't take a very big repository for performance to become an issue.


People are going to go for something that runs in 0.1 seconds as opposed to 1 second, most things being the same.


Performance is not the reason GitHub chose git over mercurial. They chose git because their core developers understand internal architecture of git better. They were more proficient in Ruby and C than Python, so git was a natural choice for GitHub.

Python language used mercurial for quite sometime to manage all it's repository, they moved to GitHub not for performance but for inertia of mass adoption, knowing very well that git has inferior user interface and they need to rely on GitHub to make it work for them. Facebook, Unity engine still use mercurial.


> except performance

That's a big except. Mercurial was far too slow. Not sure if that's still the case; I haven't used it in years. But it was slow when the field was still open to competition.


I have no idea how good mercurial is now, but I think back in the days when git started to get ahead it was superior to mercurial in more than one way.


In my understanding it's the opposite, that Mercurial is effectively a subset of Git. But I was never a Hg user.


Well, you can express any Git repository in Mercurial terms, but not otherwise.


Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: