We've been using https://rhodecode.com for internal repositories: it is also open source, yet has better interface and out-of-the-box LFS support.

The native subversion and mercurial support for the same repos is incredibly attractive. Any idea how it converts them to a shared format in real-time?

@mc42 They use a common layer called "VCS server". Here's how it looks like from the system architecture standpoint: https://docs.rhodecode.com/RhodeCode-Enterprise/admin/system...

Thanks, that's really cool.

Does it have repo mirroring? One of my favorite features of Gogs is the ability to mirror a remote repository with automatic updates.

I couldn't help noticing Gogs is hosted on GitHub...

  https://github.com/gogits/gogs

I don't know how to feel about that, on the one hand it's "not using the soap you're selling" and makes you seem disingenuous about the quality of your product.

However, it is the "home of developers" right now, and they probably would prefer a low barrier to entry for people to get involved.

Many large (or aspiring) open-source projects seek to create a community of users around it, and having a lower barrier of entry to create such a community only helps the project. As you've said, GitHub provides such a low barrier.

GitLab also started out on GitHub didn't it?

Yes we did. And we still have a non-canonical mirror there https://github.com/gitlabhq/gitlabhq#canonical-source

I totally understand why people host open source projects on GitHub.com, most open source developers have accounts there so it lowers the barrier to contributing.

BTW If you host it on GitLab.com people can login with their GitHub account.

We recommend Gogs for people that want to run on machines with little memory, it's great.

Yeah it runs great on an rPi. I doubt you can say that about Gitlab or RhodeCode.

I wish GitLab could be a bit lighter weight as well. I'd love to spin up the cheapest VM instance I can find on a cloud provider, pull a Docker container, and have a working GitLab instance up and running, but they "strongly advise against" running GitLab at the amount of memory those cheap VMs usually come with (usually around 512MB) [1].

[1] https://github.com/gitlabhq/gitlabhq/blob/master/doc/install...

Can't recommend gogs enough, slick/simple yet quite fast. Hassle free installation is a bonus.

I am using LFS on GitLab right now, works perfectly and I mention it in the article.

Wow, that UI is VERY similar to github: https://try.gogs.io/sigf/test

Interestingly, some of those features were introduced by gogs first, and then appeared at GitHub - like the tabs on top.

GitHub had tabs at the top, redesigned to use a sidebar, then went back to tabs at the top, I believe.

Last time our team tried gogs, it is unusable. Some very important features are missing:

- code review

- deployment key

And the builtin SSH server will randomly hang once or twice every day.

Gogs has had both those for quite some time now.

We did a comprehensive internal review of both gogs and gitlab. Gogs was a long way ahead of gitlab in terms of stability/speed and had pretty much all of the features developers tend to need.

Can we comment on a specific line in a merge request with gogs now?

I don't think that's quite moving the goal posts - it seems like he's asking about the quality of the code review portion.

That's an essential code review feature.

gogs is pretty slow as soon as your repository gets bigger. At least when I last tested and contributed to it a few months ago. IIRC gogs parses the whole "last commit to this file or directory" before sending the response which is pretty slow.

FWIW once you get past the initial install, updating GitLab with each release is very smooth.