Noticed the release notes mention a forced password reset for all users because of a hash change.
Couldn't that be avoided by storing the hash type/version, and silently upgrade on the next successful login (when the password is available briefly in plaintext in the login request)?
Besides the ease of installation, the thing that most impresses me is the very low resource usage and amazing responsiveness on even a tiny VPS.
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
31378 smw 20 0 262M 11516 5712 S 0.0 0.6 0:00.00 ./gogs web
11 MB of RSS? Quoting user 'pas' in an earlier comment, Gitlab wants about 2GB.
I have no idea how well it scales to a large user base, but I feel like this is going to become the go to option for side projects where you just want to share some private code with a friend or two.
If you insert three or more spaces at the left column of your submitted text, the columns will line up when the post is displayed in the HN interface, and you can have rows directly beneath each other with no intervening linefeed.
Serious question about Gitlab and something that has always scared me away: How does it perform on a resource-constrained system? A lot of the hardware requirements[1] are presented in terms of <x> users, but the "minimum" RAM requirement seems really high. If I wanted to use this with a small team (~20 users) in a resource constrained environment it seems like it'd be way overkill.
It needs disk space mostly, and you can run it with 2G RAM, so that's 20 USD/month on a VPS with SSDs with 40G space.
If that's still not cheap enough, then you can of course use it on a non-SSD VPS, configure it to use fewer Ruby worker processes and so on.
The only problem I (we) have with GitLab, is that it doesn't cache git trees, so it always fires off a git process to read the repository. (At least when this came up they wasn't open to caching it in Redis. Maybe this changed, or maybe it's available in their Enterprise offering...)
The ram usage is very high for an application of this type, if you compare it to something like Indefero [1]. The minimum requirements on the page you linked seem correct.
Second this. I use GitBlit with my team. It is a very good fit for Java teams new to git who can't let code out if the firewall especially if most of the admins are strong in Windows; specifically I mean it is good for small teams in big corps.
Somewhat off-topic, but I notice they are using xorm as their golang ORM. Anyone have experience with this? I use gorm, and I wonder how xorm compares.
On Debian-based systems you can install the gitolite package (from the repo) and then run: sudo dpkg-reconfigure gitolite. You can then start pushing and pulling.
I was actually just thinking about how this clone would make a good blog post pointing out the pain that hovers around many substantial ruby/rails projects versus other tool sets. To be able to download the binary and just run a web app ... amazing. Considering the last time I tried to run Gitlab all kinds of libraries didn't install properly and workers wouldn't come up when they were supposed to.
Its nothing big but basically amounts to adjusting how the source logic and defaults fits. The existing setup is a bit wonky and doesn't work in non bash very well.
That and I have been hacking the init script to not always use sudo. I generally prefer that root not use sudo, and where I work that bits enforced heavily. So there is a bit of logic there as well to allow for sudo as root or not.
Hopefully I get to it today but if not its not a big deal really.
Couldn't that be avoided by storing the hash type/version, and silently upgrade on the next successful login (when the password is available briefly in plaintext in the login request)?