Show HN - Github competitor with free private repo
gitlab.io
gitlab.io
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/ ?
I wasn't aware that Bitbucket also offered merge requests, I've remove that sentence. Thank you for the correction.
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
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?
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".
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.
Plus, I like github tons so I'm happy to pay.
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 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
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.
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.
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'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.
You get the source code when you buy a license but it is not open source.
Most of which won't be solved anytime soon.
But I wish you good luck.
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.
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.
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.
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?
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.
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