Hacker News Reader

Comment by dragonsh | Hacker News Reader

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.

View on HN

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.

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/

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.

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.

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

Source Depot == Perforce

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.

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.

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

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

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!

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

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

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

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

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

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

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

>I'll give hg the benefit of the doubt that it eventually got better

It did not. We had a giant hg monorepo at Yandex, and even mere "hg id" took ages (and required net access to source repository for some reason). The plan was to eventually switch to it from SVN, not sure if they eventually did because I left the company.

> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use.

Marketing is often necessary to get a start, but it is rarely sufficient for a long-lasting success. The claim that "it's all marketing" is usually made by those who look at one aspect of the technical merits and miss others that turn out to be more important. Just as in the actual VHS vs. Betamax story [1]. Betamax had a slightly, almost imperceptibly better picture quality, while VHS had double the recording time of Betamax. VHS won on the technical merits as they mattered to users.

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

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.

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

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

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

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

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

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.

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

https://phacility.com/

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

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.

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.

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.

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.

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

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.

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.

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.

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)

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

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

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

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.

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

Mercurial lets you pull and even update with outstanding changes.

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.

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.

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

Reply on news.ycombinator.com