Show HN - Github competitor with free private repo(gitlab.io)
gitlab.io
Show HN - Github competitor with free private repo
http://gitlab.io/
60 comments
Thank you for the advice about the marketing message. Any idea's about a better point?
I wasn't aware that Bitbucket also offered merge requests, I've remove that sentence. Thank you for the correction.
I wasn't aware that Bitbucket also offered merge requests, I've remove that sentence. Thank you for the correction.
> Any idea's about a better point?
Gitlab.io provides commercial hosting for Gitlab, the free open source git management platform.
If the emphasis is on being free then strikethrough "commercial". Could be replaced with "official" but could sound over-promoting.
I think it's important not to hide the fact that hosting is based on open source gitlab project. In this case it's a good thing as gitlab.io owners are also the main developers of Gitlab.
What puzzles me a bit is that Gitlab tagline [1] says it's based on Gitolite. Gitolite license is GPL2 [2] while Gitlab is MIT [1]. How is Gitlab project maintaining license compatibility? The question does not necessarily affect Gitlab.io service.
EDIT: gitorius->gitolite, AGPL->GPL2. Messed up project name in initial comment..
[1] http://gitlabhq.com/ [2] https://github.com/sitaramc/gitolite/blob/master/COPYING
Gitlab.io provides commercial hosting for Gitlab, the free open source git management platform.
If the emphasis is on being free then strikethrough "commercial". Could be replaced with "official" but could sound over-promoting.
I think it's important not to hide the fact that hosting is based on open source gitlab project. In this case it's a good thing as gitlab.io owners are also the main developers of Gitlab.
What puzzles me a bit is that Gitlab tagline [1] says it's based on Gitolite. Gitolite license is GPL2 [2] while Gitlab is MIT [1]. How is Gitlab project maintaining license compatibility? The question does not necessarily affect Gitlab.io service.
EDIT: gitorius->gitolite, AGPL->GPL2. Messed up project name in initial comment..
[1] http://gitlabhq.com/ [2] https://github.com/sitaramc/gitolite/blob/master/COPYING
Thank you for the pointer. I modified the introduction to make it clear we run on Gitlab in the first sentence.
By the way, the Gitlab.io owner (me) is not the main developer of Gitlab (randx) https://github.com/randx He is also mentioned in the 'Thanks to' section.
We state this clearly on gitlab.io, the first sentence in the section 'About the Gitlab project' is: "Gitlab is a separate project and is not affiliated with Gitlab.io."
Which Gitlab tagline are you referring to?
By the way, the Gitlab.io owner (me) is not the main developer of Gitlab (randx) https://github.com/randx He is also mentioned in the 'Thanks to' section.
We state this clearly on gitlab.io, the first sentence in the section 'About the Gitlab project' is: "Gitlab is a separate project and is not affiliated with Gitlab.io."
Which Gitlab tagline are you referring to?
Sorry, I messed up. I misread gitorius instead of gitolite.
The tagline is from http://gitlabhq.com/
"Fast, secure and stable solution based on Ruby on Rails & Gitolite. Distributed under the MIT License."
Gitolite is GPL2 and Gitlabs MIT. I was just wondering how Gitolite project keeps the license compatibility.
Please ignore my previous comment on AGPL vs MIT, that was due to my misreading of Gitorius->Gitolite. This misreading was probably affected by the http://gitlab.io/ site where it's said that "Gitlab ... similar to ... and Gitorious".
The tagline is from http://gitlabhq.com/
"Fast, secure and stable solution based on Ruby on Rails & Gitolite. Distributed under the MIT License."
Gitolite is GPL2 and Gitlabs MIT. I was just wondering how Gitolite project keeps the license compatibility.
Please ignore my previous comment on AGPL vs MIT, that was due to my misreading of Gitorius->Gitolite. This misreading was probably affected by the http://gitlab.io/ site where it's said that "Gitlab ... similar to ... and Gitorious".
I'm not the author of Gitlab or a lawyer but I think Gitlab can use a different license than GPL2 because it is not a derivative work, see http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...
It's interesting, but I use https://bitbucket.org for any private repo that I need to share with other people and github for public code. I can't see anything additional that gitlab offers, maybe I'm wrong?
Agreed. This is what I am doing too. Especially because I do most of my git work on command line, it really doesn't make a difference where the host is as far as it is reliable. Github IMHO offers a much better interface than bitbucket, but unlimited private repo is unbeatable for bitbucket. They have the totally opposite business model that I wonder which one has a higher margin.
Github is on it's own, Bitbucket is part of a huge Atlassian's portfolio of apps, I guess the revenue from BB is less important than attracting customers to their other services. But maybe I'm wrong. (signed: Bitbucket devoted user)
Good point about combining Bitbucket and Github. The interesting thing is that Gitlab is build on open source software so it is easy to transition to your own host when you need custom functionality. But I'm open to suggestions how to formulate that.
I think it's ridiculous to charge so much for private repository hosting and even limiting the amount of repositories you can have. Github is great, but I despise their pricing scheme.
BitBucket lets you have unlimited private repo's for free and limit the amount of contributors you can have.
That's an option you should look into. Limit the amount of contributors, not repo's.
BitBucket lets you have unlimited private repo's for free and limit the amount of contributors you can have.
That's an option you should look into. Limit the amount of contributors, not repo's.
Great suggestion! I was thinking about charging per repo, but I agree that BitBucket's model is better. You want people to put as much projects in source control as possible and limiting repo's discourages that. Counting the contributors on private repo's probably correlate pretty well with company size which correlates with how much they can spend.
Another option is Repository Hosting, which offers unlimited repositories and users for a flat fee, and just limits your storage.
Well, i use Bitbucket with education license (simply register bitbucket with campus email) and i get unlimited repo with unlimited collaborator for free. This is more than enough for my private projects. But i hope Gitlab.io could give more than this so i may switch into.
what can gitlab give you to get yout o switch?
Do you know any major players that use this model?
I find github compelling enough to pay them for private repos. $84 a year gets me five private repos. If you want to win me (and others like me) over you'll have to sell me an improved experience.
I sort of understand why people like Github for public projects, but what's compelling for a private project?
It's a single, unified place to host code with a known-to-be-good experience.
hzy has it right on the money. It's rock solid and reliable. The built in issues/pull requests/wiki are fantastic. Adding in a collaborator is easy. It's credentials I already heavily use.
Plus, I like github tons so I'm happy to pay.
Plus, I like github tons so I'm happy to pay.
One of the most compelling feature of using GitHub for private repositories is developers already know how to use it, already have accounts etc. GitHub has a nice growing moat in that regard.
I find issues and the wiki to be the weak points of github. Fix those.
I find issues and the wiki to be the
weak points of github.
I recently evaluated wiki software that I could use with one of the teams I'm on, and I was surprised when I ended up choosing GitHub's wikis. I love that their wikis support Org Mode's syntax. The only other solution I could find that supports Git and Org Mode's syntax is Gitit, which was my second choice.
I was fully prepared to use Markdown, Textile, or some other lightweight markup language that I consider inferior to Org Mode's syntax, but no wiki solution was good enough to warrant that compromise.
Thank you for the suggestion.
That font is very difficult to read with OS X's font rendering[1]. I think it's too thin, causing strange antialiasing effects.
[1]: http://i.imgur.com/BkyPv.png
[1]: http://i.imgur.com/BkyPv.png
Thank you for informing me. I changed to font to Helvetica. I hope it's better now. (maybe need a hard refresh)
You may want to switch that to Helvetica Neue (or just add it to the top of the font stack), the subtle difference in this case is that it has a wider support for different font weights whereas Helvetica jumps from 100 to 400 to 600.
Great suggestion, I just added Helvetica Neue. Let me know if you have any other suggestions.
Be sure to take a closer look at the Gitlab source code. The last time I did, they still were vulnerable to exactly the same attacks that were also demonstrated to work on Github some time ago.
You mean the mass assignment hack mentioned here? https://github.com/blog/1068-public-key-security-vulnerabili...
Thank you for the hint, I will certainly have a look at the Gitlab source to check if the countermeasures are in place. http://guides.rubyonrails.org/security.html#countermeasures
Thank you for the hint, I will certainly have a look at the Gitlab source to check if the countermeasures are in place. http://guides.rubyonrails.org/security.html#countermeasures
Yes. Just check this model, for example: https://github.com/gitlabhq/gitlabhq/blob/master/app/models/...
I'm pretty sure it should have it's attributes protected.
Also, prepare to have to work with pretty confusing code. I don't want to belittle the work of the Gitlab authors and contributors, but the whole codebase is ignoring many Ruby, Rails, Webdevelopment and general programming best practices.
A short list of problems, at least in my eyes, and in no specific order: * Obtrusive JavaScript inside the erb templates, inline style definitions * Non-semantic css class names. * Highly confusing controller code (filters are used to set all kinds of instance variables, which makes it very hard to easily understand where the variable is coming from and what it's value is). * "Roles": Code that has been extracted into seperate modules, but for no real reason. E.g. the SshKey module is only included into the Key class, and is highly coupled with it. * Totally brittle test suite.
I'm pretty sure it should have it's attributes protected.
Also, prepare to have to work with pretty confusing code. I don't want to belittle the work of the Gitlab authors and contributors, but the whole codebase is ignoring many Ruby, Rails, Webdevelopment and general programming best practices.
A short list of problems, at least in my eyes, and in no specific order: * Obtrusive JavaScript inside the erb templates, inline style definitions * Non-semantic css class names. * Highly confusing controller code (filters are used to set all kinds of instance variables, which makes it very hard to easily understand where the variable is coming from and what it's value is). * "Roles": Code that has been extracted into seperate modules, but for no real reason. E.g. the SshKey module is only included into the Key class, and is highly coupled with it. * Totally brittle test suite.
Thank you for the heads up. I must say I've seen worse projects but I won't argue with the points you raised.
In general I think that compared to the alternatives Gitlab is the least complex to understand and install. Of course that doesn't mean it is perfect or easy. These two lines took us a few hours: https://github.com/gitlabhq/gitlabhq/pull/1263
I think the Gitlab author already did an awesome job and luckily there are many people sending in pull request, already more than 1200!
We try contribute our part. With the growth of Gitlab.io our contributions should grow as well.
In general I think that compared to the alternatives Gitlab is the least complex to understand and install. Of course that doesn't mean it is perfect or easy. These two lines took us a few hours: https://github.com/gitlabhq/gitlabhq/pull/1263
I think the Gitlab author already did an awesome job and luckily there are many people sending in pull request, already more than 1200!
We try contribute our part. With the growth of Gitlab.io our contributions should grow as well.
Hah! Your pull request actually introduces subtle bugs into the diff view. I had already submitted _exactly_ the same change some months ago, and after having it enabled for some time in our gitlab installation at work, I ran into some issues.
I can't remember the exact preconditions, but there were cases where this change would start showing changes that were not even part of the merge request at all, which was extremely confusing.
In the end, I went ahead and did some more low-level changes to gitlab, so it would not only save the branch for a merge request, but it would save the actual commit shas of the source revision. That was much more accurate and reflects the way pull requests work on Github.
I can't remember the exact preconditions, but there were cases where this change would start showing changes that were not even part of the merge request at all, which was extremely confusing.
In the end, I went ahead and did some more low-level changes to gitlab, so it would not only save the branch for a merge request, but it would save the actual commit shas of the source revision. That was much more accurate and reflects the way pull requests work on Github.
Thank you for the warning. Do you have a test case that reproduces the problem that you can share?
I also added a security check to the list of planned contributions on gitlab.io
I don't think I can make the jump. I'd rather pay my $7 or whatever it is than entrust my corporate secrets and repo stability to a new guy. Maybe in a few years.
I agree it takes time to build a reputation. I hope that people will start with hosting non-corporate projects. Many companies already use self-install Gitlab to host behind the firewall.
I'm glad to say that after 2,5 hours on HN we already got 160 signups for the beta, so some people want to give it a try. But there will be many others like you that want to see where it goes, I hope to convince them soon.
I'm glad to say that after 2,5 hours on HN we already got 160 signups for the beta, so some people want to give it a try. But there will be many others like you that want to see where it goes, I hope to convince them soon.
Or you could just use BitBucket.
BitBucket is a good alternative and I have deep respect for Atlassian team. But I also like to use open source where possible. Especially for as something as basic as code management. What do you think?
Why is bitbucket not open source?
Because Atlassian makes money on the self-install version called Stash http://www.atlassian.com/software/stash/overview
You get the source code when you buy a license but it is not open source.
You get the source code when you buy a license but it is not open source.
Bitbucket and Stash are different products with different codebases. Bitbucket is written in Python and Stash is written in Java.
This is not able to compete with Github or BitBucket... I actively work on GitLab and there are a ton of issues and missing features that are highly important, and will most likely turn away users.
Most of which won't be solved anytime soon.
But I wish you good luck.
Most of which won't be solved anytime soon.
But I wish you good luck.
I see that you had your share of issues with Gitlab. I agree that it will need a lot of work before being as fully featured as Github or BitBucket. But I believe it can grow quickly because of the community around it, there is an obvious need for an open source solution. And I hope I can pleasantly surprise the 350+ people that signed up for the beta program in the last 5 hours.
[deleted]
I'm all for an open source Git front-end, but the design of Gitlab is just too close to GitHub. Even things like "Network" have been replicated exactly. Anyone else see this as a problem?
What business model would sustain the cots?
There will be priced plans if you host more than 1 private repo.
Please let me know what you think about this, I'm open to feedback.
If you provide something that GitHub doesn't have it will make for a much more compelling sell.
Currently GitHub doesn't give you fine grain access controls, this is something you could capitalize on and provide for clients. Something they could go back and say as awesome as GitHub is, they can't do this so they have to choose you.
A few examples.
- I only want [release dude] to be able to push to any release/* branch.
- No one should be able to force push to master
- No one should be able to force push to release/*
- release/* branches must follow the regexp [...]
- The user bmeyer can only create branches in bmeyer/*
- The user bmeyer can only push commits to the branch master if the patches touch files in src/network
- Users that don't have a single commit in the repo can't push at all. (After analyzing an internal project this one rule would have caught most of our breakage and forced the first commit by a new user to be pushed by another developer who would be more likely to catch basic errors such as build.)
- Users in the group [foo] only have R access to the entire repo
Really go check out the rule support in gitolite which is a good model to start with as it is very expressive and allows for doing a lot of stuff. http://sitaramc.github.com/gitolite/rules.html
Disclaimer: Having made my own GitHub clone I have thought about this a fair bit. (GitHaven, which sadly was killed by my works legal dept before it could get off the ground.) If the feedback is about your UI or some minor feature that GitHub has that you don't, ignore them because if you solve that problem you are still in the same boat and they will go with GitHub. You need to solve an existing users problem so there is someone out there who will be shoving money at you to make their problem go away even if you made your UI ugly and barely working.
Currently GitHub doesn't give you fine grain access controls, this is something you could capitalize on and provide for clients. Something they could go back and say as awesome as GitHub is, they can't do this so they have to choose you.
A few examples.
- I only want [release dude] to be able to push to any release/* branch.
- No one should be able to force push to master
- No one should be able to force push to release/*
- release/* branches must follow the regexp [...]
- The user bmeyer can only create branches in bmeyer/*
- The user bmeyer can only push commits to the branch master if the patches touch files in src/network
- Users that don't have a single commit in the repo can't push at all. (After analyzing an internal project this one rule would have caught most of our breakage and forced the first commit by a new user to be pushed by another developer who would be more likely to catch basic errors such as build.)
- Users in the group [foo] only have R access to the entire repo
Really go check out the rule support in gitolite which is a good model to start with as it is very expressive and allows for doing a lot of stuff. http://sitaramc.github.com/gitolite/rules.html
Disclaimer: Having made my own GitHub clone I have thought about this a fair bit. (GitHaven, which sadly was killed by my works legal dept before it could get off the ground.) If the feedback is about your UI or some minor feature that GitHub has that you don't, ignore them because if you solve that problem you are still in the same boat and they will go with GitHub. You need to solve an existing users problem so there is someone out there who will be shoving money at you to make their problem go away even if you made your UI ugly and barely working.
I think you are right that Gitlab would be a more compelling alternative with some major unique features. You give great suggestions for better access controls.
Access control in Gitlab is currently done with the following roles: Guest / Reporter / Developer / Master. See http://imgur.com/yFkVb
Would that be a start? Which of your examples do you need most?
Access control in Gitlab is currently done with the following roles: Guest / Reporter / Developer / Master. See http://imgur.com/yFkVb
Would that be a start? Which of your examples do you need most?
A git server frontend is really about three things (I would say in this order)
1 Providing permissions to access the repository
2 Providing a visual way to browse the source code and link to the source code (sha X, file Y, line Z)
3 Slap features on top of the above two (bug management, code analysis, doc generation, auto publishing like gh_pages (awesome btw!), code review, task analysis, etc etc
Really checkout gitolites permissions. The ability to create devs into group (test/release/intern) and then on top of that apply 'R', 'W', '+', to any or specific branches and or files creates an expressive set of rules.
When I was working on GitHaven I also had a simplistic permissions model like GitHub has. But the more I talked with end users the more edge cases I found and the more I realized how the permissions is really a core bit of the thing I was building and if I were to hack on GitHaven again I would either built it on top of gitolite or build something just as expressive, if not more.
P.S. set your email in your HN account. As I have spent too much time thinking about this problem I would be happy to buy you a virtual beer on facetime or whatnot to share what I have learned about the problem if your interested.
Edit: from the description it sounds like it is already built on top of Gitolite :) So making a fully feature UI for their permissions should be easy.
Really checkout gitolites permissions. The ability to create devs into group (test/release/intern) and then on top of that apply 'R', 'W', '+', to any or specific branches and or files creates an expressive set of rules.
When I was working on GitHaven I also had a simplistic permissions model like GitHub has. But the more I talked with end users the more edge cases I found and the more I realized how the permissions is really a core bit of the thing I was building and if I were to hack on GitHaven again I would either built it on top of gitolite or build something just as expressive, if not more.
P.S. set your email in your HN account. As I have spent too much time thinking about this problem I would be happy to buy you a virtual beer on facetime or whatnot to share what I have learned about the problem if your interested.
Edit: from the description it sounds like it is already built on top of Gitolite :) So making a fully feature UI for their permissions should be easy.
Good insight about the functions of a web front-end. I totally agree. And I think the first two are a priority before slapping features on top.
Gitlab is build on top of Gitolite so setting granular permissions should be doable. I worry that the combination of groups and branch settings will be hard to maintain unless you name your branches consistently.
I'm very interested in talking to you to learn from your thinking. I've set my email on HN, my Skype handle is sytses and my contact info is on http://sytse.com/contact
Gitlab is build on top of Gitolite so setting granular permissions should be doable. I worry that the combination of groups and branch settings will be hard to maintain unless you name your branches consistently.
I'm very interested in talking to you to learn from your thinking. I've set my email on HN, my Skype handle is sytses and my contact info is on http://sytse.com/contact
I applaud the effort, but I guess I don't really understand what, exactly, it is. A GitHub clone? Hosted Git with no interface?
For example, take your first sentence: "Gitlab is an open source solution for version control of your coding projects." Doesn't that describe Git itself?
Assuming that Gitlab is an open source GitHub-alike, I'd make that clear right up top: "Gitlab is hosted Git with an open source web front-end." Then, if possible: screenshots.
I wouldn't make the one private repo your selling point, either, as others have pointed out. I would go with the open source angle -- that's your only real differentiating feature (that I know of), and the one that you should really emphasize.
For example, take your first sentence: "Gitlab is an open source solution for version control of your coding projects." Doesn't that describe Git itself?
Assuming that Gitlab is an open source GitHub-alike, I'd make that clear right up top: "Gitlab is hosted Git with an open source web front-end." Then, if possible: screenshots.
I wouldn't make the one private repo your selling point, either, as others have pointed out. I would go with the open source angle -- that's your only real differentiating feature (that I know of), and the one that you should really emphasize.
As you suspect Gitlab is hosted Git with an open source web front-end. I changed the first line of Gitlab.io to your exact quote, thank you for the suggestion.
I also linked to the Gitlab screenshots http://blog.gitlabhq.com/screenshots/ as you suggested, thanks again.
And I'll rewrite to make the open source angle the main point.
I also linked to the Gitlab screenshots http://blog.gitlabhq.com/screenshots/ as you suggested, thanks again.
And I'll rewrite to make the open source angle the main point.
I'm not sure what you mean by "there is no other service offering a free private repository that lets you work with merge requests." What about http://blog.bitbucket.org/2011/06/17/pull-request-revamp/ ?