I like the idea of having your private Github. Relying on some company far away to keep their servers running (while having a bullseye for DDoS painted on itself it seems) for larger commercial projects always turned me off a bit.
I love GitLab but it is too time consuming to maintain. Once a month you have to manually update it and you can't skip updates. The update process can take from 15 minutes to hours should any problem arise. I know since I have performed all updates from 2.3 to current version.
It is great but due to the update situation and the resources it needs (amount of RAM), I think it targets mainly groups and not individuals.
Give me a lightweight, one command, free software alternative with 60% of GitLab's feature set and I will be a happy man.
I'd like to offer a counter experience where the upgrades are pretty simple: stop, git pull, rake a bit, update a few configs (maybe), start. It's certainly not trivial or painless, but it isn't that bad and it's nice that they're releasing regularly (22nd of each month, I believe).
I agree that it is absolutely meant for groups more than individuals. We use GitLab like crazy in the office, but we also have GitHub accounts for community contributions and BitBucket accounts for private/personal stuff.
Most of the updates aren't bad, indeed. But there are issues.
For example at first we had to install gitolite as well and update it. Then we switched to gitlab-shell, so we had to make the switch and now update this as well. There was resque and then there was sidekiq. There was unicorn and then it was replaced by puma and now it is replaced once again by unicorn. At some point those of us who used sqlite could not migrate to mysql when sqlite was dropped. Also more than once, when I was quick to update I ran into problems and had to spend hours in search of a solution. Nowadays I update near the end of the release cycle to avoid such issues.
I am on gentoo, so I have to create and adjust my own init scripts. I use apache, so I have to figure that out as well.
All these I guess can take anywhere from 10-24 hours per year, which can't be justified for one person. For a team it is ok.
As for gitbucket, I gave it a try and it only supports git access through http and even there it can't give read only acces to private repos. Any account that has read access, has also write access to a private repo, which makes it useless for deployment.
GitLab co-founder here. Thanks for commenting and informing people.
For those interested a bit of background. Replacing gitolite with gitlab-shell in GitLab 5.0 was a painful step that we did not take lightly. It enabled GitLab to perform much better (100x faster on some operations) in larger installations (1000+ repo's). It also greatly reduced the moving parts and installation problems people experienced.
We tested Puma on GitLab cloud for weeks to see if there where issues but after the switch we ran into big problems so we had to go back to unicorn. The other transitions have similar stories. We try to be careful but we want to end up with a great solution so sometimes we have to make hard choices.
He said 'alternative', meaning something that will provide UI to Git. Proposing solution based on another SCM is not really an alternative, it's a completely different thing.
I installed that about a month ago as I was having issues installing GitLab on a fresh Ubuntu installation. Trying to upgrade to the latest version is a massive ball ache. It completely messed up.
Eventually I installed myself. Everything works great now, although I had a couple of hiccups when trying to upgrade to a beta (that'll teach me).
I like stash and have been a paying customer since last year. As far as I know, it is written in Scala too (the plugin API docs had a Scala flavour when I last looked at them).
I especially like its Pull Request interface. It separates out the changes into a file tree, which appears as a pane on the left. Makes it much easier to review large PRs.
The only hitch is, Atlassian has very opinionated product managers. I (and a bunch of other users) had to convince them to support "forks" over a long JIRA thread!
> As far as I know, it is written in Scala too (the plugin API docs had a Scala flavour when I last looked at them).
?? Their source code is downloadable to us since we have a license, but I've not checked. Everything else Atlassian purchased has been Java, afaik.
And Atlassian's only opinionated project manager I know about is Jens who does Stash, so I think you are generalizing to apply that to all of Atlassian. I've been using their products a long time now and he is the first that has been like that, but I know what you mean. He doesn't really meet up with Atlassian's typical level of customer service because of his attitude, but maybe he's a "rockstar" that deserves respect.
I would like to clarify that support for Forks was on our roadmap from day one. It was merely a matter of time and priorities to get it implemented as can be seen on the issue discussion: https://jira.atlassian.com/browse/STASH-2495
The core of Stash is actually written in JAVA, with only few plugins being implemented in Scala. But that number will likely grow going forward.
You are probably right that some of us are slightly opinionated. But as was pointed out before, I believe product managers should be opinionated as long as the opinions are formed by knowing your customers and market extremely well.
I'd say that's a good thing. A product can't be all things to all people and when it tries it ends up as a big hogde-podge of compromises that make no-one happy (either that, or being a beast to configure, thus making support painful).
Now, I don't know what the particular issue over forks are (related to branches?) and whether it's reasonable, but the fact that they were eventually convincible only makes it seem better.
In general I agree, but "forking" would be considered as a very essential feature by many in a product like Stash. I don't think dozens of users were needed to argue that it be included.
After yesterday, installing Satis (server for composer packages) jumped almost to the top of my list, been unable to access composer for a big chunk of the day could have been a real problem on the wrong day.
I use Bitbucket for my repo's (with mirrors on my servers) as I actually prefer it (and you can have unlimited repo's < 5 users) so it was a pain to have a dependency on github as well.
Yeah, I get that a lot. Theoretically, this is possible by supporting Mono and switching to PostgreSQL/MySQL. Practically, given my limited resources, this is not something I will be able to do in the nearest future.
Can't you just add a new remote, push and bang, your code is now there? You should always have a full (hopefully up to date) source somewhere so incase github/bitbucket/remote provider - even your server if you host locally on gitlab etc - catches on fire you always have a spare.
