> Lots of reasons. I'd rather not go into an argument about it. It's not something that can be fixed: git is a no-go for us.

I'm not interested in getting into an argument, but I'm genuinely curious what reasons remain for people preferring mercurial. At the moment, apart from "got used to the UI", the main one I know of is more "native" Windows support (without needing a Cygwin-like environment to work in). I don't know if that's an issue for your project.

> I'd rather break free, not change masters.

Fair enough. In terms of repository hosting, moving to Savannah seems like the obvious choice there then. And assuming you have people available to do the work, you could always move to gnu.org or nongnu.org, depending on your tastes and the nature of the software your directory links to.

> I'm genuinely curious what reasons remain for people preferring mercurial

Top-level answers here:

https://news.ycombinator.com/item?id=9467096

> moving to Savannah seems like the obvious choice there then.

The only issue is that Savannah is static hosting. We have a bit of PHP that generates one page. We might be able to replace that with Jekyll, though.

> The only issue is that Savannah is static hosting. We have a bit of PHP that generates one page. We might be able to replace that with Jekyll, though.

Does it do so from dynamic server-side data, or could you run it on each new commit and serve the result as a static page?

Yeah, we can probably do some sort of commit hook. It's not an impossible problem, just annoying.

Can't speak for anyone else but I use Mercurial because it's fast, user friendly and easy to extend with your own plugins.

> I'd rather break free, not change masters.

Unless you have the volunteer army necessary to run the hosting yourself, you're going to be changing to a new master anyway. You just need to make sure it's a master you can leave at any moment.

So get a domain name and point it at GitHub Pages, and deal with git for the timebeing. At any point (either if GitHub goes bad, or someone's enthusiastic about setting up something else), you can repoint that domain name to another host, far more easily than you can change octave.sf.net to point somewhere else.

I agree that switching to octave.github.io would not actually help anything other than the immediate problem.

> Unless you have the volunteer army necessary to run the hosting yourself

You don't need an army (depending on the solution). But setting up gitlab/rhodecode/indefero/srchub/Gitolite/custom scripts for a single project is kind of overkill. I've used rhodecode and whenever they released an update it would take me hours to update it. I've never been happier to fork indefero and get off of google code.

RhodeCode CTO, thanks for mentioning us. With our new cross-platform installer, it takes just few minutes to update running instances, and it's actually a one-liner to run the upgrade. Thanks for providing feedback !

GitLab CEO here, thanks for mentioning us. We care deeply about making updating fast. Our Omnibus packages should install in 2 minutes and we recently introduced a package server to make updates just as snappy.

Well, we do have those volunteers/employees on the GNU servers. We also can pay for our own hosting. We'll probably go one of those routes.

I'm actually curious -- I understand that you have tech debt that prevents you from moving to Git, and I'm not here to tell you your concerns are irrelevant. At what point do the compromises that tech debt forces you into hamper the visibility of the project?

This seems to be a continuous problem in the open source community. As tools, maintainers, and support platforms age, how do you deal with the tech debt of keeping them supported? It's an easier calculation for a business; I'm just curious how various open source projects make these kinds of choices absent a corporate benefactor that sets direction.

So host your own Mercurial and HTTP servers?

Because that's about the only way to genuinely "break free".