A feature I miss in GitLab and Github is an issue tracker across multiple repos. For example, our project has 5-10 repos but they are all part of single release/milestone.
Currently, we have to create milestones in each of the repos and assign issues to those milestones. It's really a hassle. We cross reference commits a lot in the issues and this is the reason why we don't create a "empty" repo simple for common issues. Unless there is some way to say something like "Fixes commonissuetracker#43".
We do the same thing as you, create the same milestone in each of the repo's and then use the group milestone view to see an overview.
It would be nice to have a create milestone at the group level that creates the milestone in all projects, would you be willing to contribute that?
Mentioning issues or merge requests in other projects can be done with the cross project reference, found in the right hand side of every issue and merge request, for example gitlab/organization#260
I just looked at the pricing page on Gitlab.com and was genuinely interested in trying it out. But the pricing language and structure on the page turned me off instantly.
I thought to myself: "$3.25 per user per month? Sweet! I can throw $6.5 to try it out without the hassle of setting up yet another VM. Charged yearly? Eh, seems to be a bit of a commitment. Oh wait, in multiples of 10? that's $390 upfront with 8 extra licenses for a year!"
They list the monthly price first but they actually bill hourly. It seems more honest and upfront to tell me what I'm in for.
I understand that you're competitive compared to Github enterprise, but I think that page needs some work to make it more trustworthy and less salesman-pitch-y. Even Github lists that they start from $2500 upfront, not $3.25 + read the fine print.
Best of luck to you and congratulations on the funding.
Edit: And I just noticed that's actually for the on-site EE and that Gitlab.com is free. Oy vey.
Thanks for your thoughtful comment. We had yearly prices before but most people expect a price per month (our prices are pretty low so many people assumed our yearly price was our monthly one). I agree that now it is hard to make out the minimum order size, you need to do x10x12. Would it be an improvement if we add '$390 per user pack' to the list of items below the price to save you this calculation? BTW If you want to try it out we do have a money back guaranty.
Thanks for your reply. Price x12 like you said is standard, it's the x10x12 that caught me off guard.
I think some language and price listing adjustments like you suggested would be a great improvement. Even if it's as simple as $32.5 per user pack per month (charged yearly).
But you _charge_ per user pack, do you not? Can we purchase 17 licenses? How about 23?
We have around 20 Backblaze licenses that we pay a bit over $1000 per year for. It makes sense for them to advertise the price per user because they charge us that way.
This is akin to Pepsi sticking a huge sign over their 24 pack at the department store saying "NOW ONLY 99 CENTS PER CAN!" minimum 24, in increments of 24.
Anyway, like I said, the way the pricing is advertised turned an interested/potential customer away.
it would be great if you would change it to something like "monthly subscription" "per user pricing". Which means I could start with 2 users, add 10 and pay for them and maybe then I will kick two in the next month and will pay for 10. Paying on demand is something that I think would be really really good. AWS style.
Your current pricing model is fine. If someone needs GitLab, they'll pay for it. If they don't pay for it, they don't need it. $30-60/year is cheap, even for a hobbyist project.
I think you may have validated what the OP was saying :-) It's $3.25 per user per month, but the minimum order is 10 users. So the minimum price is $390 per year.
We aren't hobbyists, we are just a small company 5+-1.
And sometimes we hire people for a small amount of time, which could exceed 10. So for that time we would need to have a bigger license?!
If you exceed 10 non-blocked users you would need a bigger license. If you can block certain users at certain times you would be able to use 1 user pack (the users are not named).
I think the real angle of this feature should be to abstract the concept of "project" so that it is no longer synonymous with "git repository". And the migration path is pretty straightforward: every repo becomes a project containing a single repo, and then users can merge existing projects to create multi-repo projects (at which point you'd probably have to re-number every issue, pull request, etc. to avoid collisions).
We use gitlab at PacketZoom too and are mostly happy with this. But yes, I second the request for either:
a) Creation of a project independent of git repos.
OR
b) At least a way to attach issues across projects. Issue management is probably the weakest part of gitlab and one of the big reasons is this fragmentation of issues across git repos. It's trivial to see that issues can and will cut across git repos in any reasonably complex product. Another "nice to have" feature would be an ability to create "dependent" issues.
That seems pretty reasonable, maybe even preferable. Having issues attached to specific repos but synchronized to cross-repo common milestones sounds like it would work well.
I like this way of organizing. At my last company we had a very, vary large project that had about 70 git repos (and that was after combining quite a few of them). A project view would have made that so much easier to manage.
This is a feature of ZenHub (zenhub.io). I'm not a customer, though I may sign up in order to be able to get a 'dashboard-like' project management overview of issues across client projects.
You can do exactly that with github. org/app PR with the first line "Fixes org/tracking#43" will link the PR to the tracking repo's issue. Merging the PR closes the issue.
Firstly, a major congratulations to the gang at GitLab - well deserved!
We'd used GitLab for over a year internally, but as I've mentioned previously, it became a pain to maintain. So we switched to GitHub for our private "important" projects and turned off our GitLab instance (other reasons caused this too mind). Our version was 6.7 or something up until today.
Today we realised we should run GitLab internally again for non-critical repositories - since our networking is a pain to give external access to servers - we can't access it out of the office. I updated us to 7.12 CE and I kind of regret it.
The UI is so complicated now. Whilst there are good features that we like, it's so hard to navigate to where you want to be. I think this is down to the "contextual" sidebar. I really do prefer GitHub's UI for repo administration and usage, which is a shame.
Sure, the colours are nice in GitLab but it's far from functional. My colleagues felt the same way too.
Also (for those at GitLab) your Markdown renderer is still not rendering Markdown correctly in all cases...
Anyway, not to take away from the funding - it's excellent news!
It's very, very difficult to do what GitHub did. They combined a great sense of UX design with an extremely powerful and necessary backend product, and they figured out a way to make money doing it. GitHub's large bank account and horde of developers allows it to quickly take charge of high-stakes situations and come out on top. (This, of course, is not implying that simply throwing money at the problem will solve it...look at Atlassian Stash, a great product but pales in comparison to GitHub) Open-source projects need money and time too, but most of us don't get paid to work on open-source software, so GitLab suffers from the fact that it's no one's job to create it.
Now that GitLab is getting some funding, it will at least level the playing field somewhat.
I'm a product manager for Stash. I'd love to know more about what you find lacking in Stash. We've got a bumper crop of improvements in the works that we think are useful, but the more feedback to guide us, the better.
Stash, in my opinion, is the best git tool out there. Sadly it's sometimes tough to convince people to switch when Github is 'good enough'. Anyway, keep up the good work!
Agreed. If you are copying a successful web product you may as well take it to 100% and then try to improve upon it. Making changes just to look like you're not copying it forces your product to be inferior.
The hierarchy is actually the same, we just moved what was on top - to the side.
That said, it is a work in progress and with every release so far we have made significant changes to the UI to make it easier to work with and continue to do so.
I understand that the contextual sidebar can be confusing. One way I'm thinking we can improve it, is to make it more clear where you are, so that the context is clear from the start.
Do you think that would make a difference for you?
We're very happy to hear suggestions for improvements in this area -or even better, receive contributions in the form of pull requests.
I tried contributing a nav change in the past (https://github.com/gitlabhq/gitlabhq/pull/6287) and it was closed because the CEO doesn't want it like that. That's one, limited example, but with the size of the change required to make the sidebar better, it could end up being a massive waste of time.
Still, I'll be closely watching GitLab and upgrading every few releases.
I understand that it's disappointing if your PR doesn't gets merged.
If you want to do something big, you should consider writing a proposal first in one of our issue trackers or on feedback.gitlab.com.
In the same line, consider just creating a prototype / proposal or MVP of whatever you're building first. There are many people at GitLab happy to help you get rolling and get the PR merged. At the same time, if you're completely off-track, we'll also tell you that.
The best way to not waste time is to communicate before, during and after any effort.
Thanks for the link to the pull request. The benefit you stated was "I find this most useful since I can quickly jump back to a namespace, or search etc.". I think that 7.12 allows this by always showing the namespace and search on top. Please let me know if I misunderstand.
Thanks for your remark. I just discussed it with Dmitriy (CTO) to understand what you mean with the "contextual" sidebar. Compared to GitHub we don't see how the contextual part is more confusing. On GitHub the sidebar is to the right instead of to the left, but it is also contextual.
One thing that might be confusing is that our sidebar is separated more from the page content (different color, out of the way). Maybe that is why you expect it to be static instead of contextual?
When I visit a project page I usually do it for one of these reason:
* learn about what the project is, a short description on what it is, how to install, where to find more documentation
* look at / search the files or clone the repo
* search bugreports or create a new bugreport
Your default project page looks quite similar to gitorious, which looks more like a place to just host your repository and not a place to interact with the project.
Bitbucket's default looks way better for example, and github's is quite good too.
My suggestion to make Gitlab fit better into my workflow:
* default page/tab for project root should be configurable, either on per project or per user basis: I'd like to have the README as default for example, the Activity page by default interests me less.
* there should be a tab for issues on the default page, its more important than to see the activity IMHO
* you've got the clone URL in an easily accessible place, good!
* the Files view is quite similar to Github's (good!), but I can't figure out how to search (either fulltext or filename)
* I don't see a button to create a new issue (I'm not logged in, should I login first? Github has a new issue button that takes you to login)
* how do I search in issues (fulltext?)
* how do I search for project names, or inside projects/issues globally?
* the default project page should somehow highlight or focus on making it easy and obvious the main aspects on how you'd interact with the project, if all features are shown in equal style it feels somewhat cluttered and overloaded.
P.S.: should I open a feature request about these on the gitlab site?
Thanks for your feedback, nice of you to submit this.
We've merged a completely new project homepage for 7.13 (out on the 22nd) that addresses some of the things you mentioned. It will not be configurable however.
Create issue is indeed only visible when logged in, makes sense to always show it, feel free to submit to feedback.gitlab.com
When you view a repo if you click the readme tab then come back later, the readme tab is the default. I'm not sure if this is stored short term or long-term but it was a featured added in the last 3-4 releases iirc.
Seems like a small amount to raise from a heavyweight VC like Khosla and super angel Ashton Kutcher. I would imagine trying to compete against GitHub and GitHub enterprise would be a capital intensive thing.
Thanks for your remark. GitLab is a work of love for more than 800 contributors. That is why we've been able to bootstrap the company. Most of the time we're around cash flow breakeven. We plan to hire expensive sales and marketing people in SF so we need a bit of cash. But after 3-6 months they help to generate more revenue. This allows us to raise relatively little capital so we have more control of our destiny. We don't need to raise more than our competitors to win because of our open source model.
I am using a gitlab instance for about 2 years on my personal server and have been very happy with it.
Recently, (finally!) we switched our research group over from (a very very old version of) redmine and you can't imagine my joy when that happended! I think never before in my life migrating wiki pages and issues felt so good.
Last but not least it is encouraging to see a European software startup thriving and growing like you do. Nothing against the great products from SV but a little geographical competition never hurt nobody. Right? ;)
Keep up the great work.
Grüße aus Deutschland / Greetings from Germany
I used GitLab at my last company. It was one of the earlier versions before they went to YCombinator. At the time I wasn't a fan; I ran into bugs and just had odd persistence issues.
But I've got to say GitLab is just incredible to use now. It's really nice and I now use it over BitBucket for my private repositories. I still use GitHub for OpenSource (that's going to be a hard barrier to get through if they really want to) but I'm a big fan.
So congrats on the round! This is technically the second seed round, right? Or does YCombinator not really count as a seed anymore?
Great to hear you experienced a great improvement in the reliability of GitLab! We agree that the network effect of open source hosted on GitHub will take a lot of time to overcome. But right now we're very much focussed on on-premises installations and hosting private repos for free with GitLab.com
Most people don't regard the Y Combinator investment as a seed round. Also, the seed round can stretch out in time due to the SAFE agreements that are used (it is not a priced round).
So the price is one thing. Granted my personal projects are only just me but some of the projects I've collaborated on before involved multiple people so just for simplicity's sake I moved all of them over (I hate having multiple services for the same type of thing; GitHub is the only exception because their private pricing is really high and it's really difficult to do OpenSource anywhere else).
I'm not going to lie and this is going to sound kinda shallow but I thought GitLab looked nicer too. Granted this wasn't the main thing that made me move but it did help nudge me a little.
Beyond that it's not like git is very different between places so it's kinda hard to differentiate in my opinion.
I've been using Gitlab now for a few months and really like it but I've run into some bugs on gitlab.com that I've reported through multiple avenues and have had zero success fixing. The main one is that there are some repos that if I make an issue or edit an issue on the server will 500 error on form submit (the submit will still occur, the redirect is broken.) It would be beyond nice to see this extra cash go to a more responsive support system.
Congrats from another Dutch company that expanded to the US! We're using GitLab for all our internal source code at Mendix, and are extremely happy with it.
GitLab is open source. You can run in on almost anything or use our free cloud offering GitLab.com.
We're almost at feature parity with GitHub, but also offer other things. For instance features such as rebase before merge, merge request approvals, LDAP group integration.
In addition, we build GitLab Continuous Integration, which is a fully featured CI tool that is easy to scale and integrates with GitLab. It's completely free.
A nice notification panel like the one in github would be excellent. I really like Gitlab and have been using it for my projects but the lack of a notifications panel is annoying.
Good point, we're thinking about this. Personally I would really like to see a list of items I've been mentioned in but where I have not responded in the issue or merge request. Is that also what you want or do you want to see all mentions regardless of having responded yourself.
Thanks for mentioning that, and actually, GitLab.com is free whatever your usage. The paid plan is to get email support, the free users have forum support. https://about.gitlab.com/gitlab-com/
Many services integrate natively with Github (dev oriented services use Github oAuth, CI solutions use Github hooks to kick off builds, integration built into various editors, etc)
Much of this can be replicated in those services though it may require a slightly more manual integration.
I'm a big fan of GitLab's ability to create custom hooks and protected branches. GitHub doesn't offer those things, and despite their more polished UI it was a dealbreaker.
I'm quite excited about the future of GitLab CI. We're working hard on it and with each release it's becoming easier to use and more powerful.
GitLab is going very fast both in terms of customization/integration and in usability. We've always valued a solid product that doesn't hurt itself by adding too many new features or configurables, but lately we've been spending more and more time thinking about the feel and look of GitLab.
I don't like the idea of a free as in beer software. GitHub is Great but Gitlab seems like a cheap clone, so targeting People that want to pay less or nothing. I don't think it is ethic to clone ideas, to build a better world we nerd new ideas.
I think building up a libre platform, even if the basic patterns have been established, paves the way for innovation. Imagine if people could just "add features" to Github.
To put it another way, GNU and Linux were just a "cheap clone" of UNIX, but became a great platform for innovation.
One interesting thing about GNU is that originally developers were encouraged to implement work a-like solutions, but with completely different internals. This resulted in a large number of improvements over the standard Unix tools (a great example being bison vs yacc). I'll probably get some push back from the BSD folks, but back in the old days it was pretty common to install GNU (without the kernel) on every new Unix box you got because the GNU utilities were considered to be better (possibly some of them have gotten a bit bloated... bash... ;-) ).
Currently, we have to create milestones in each of the repos and assign issues to those milestones. It's really a hassle. We cross reference commits a lot in the issues and this is the reason why we don't create a "empty" repo simple for common issues. Unless there is some way to say something like "Fixes commonissuetracker#43".
Thanks, a very happy gitlab user