GitLab could definitely have been a bit more original with the name, but actually the UI is very different from GitHub. Which has its pros and cons, of course.
Just wanted to say that neither being the same of different is a goal for GitLab, we just want to have an easy to understand, efficient and beautiful interface.
Personally I feel for pieces of software like this it's fair to more or less clone the user interface. There's a lot of effort built up in understanding how to use this tool. Think of the complaints LibreOffice gets for not looking enough like Word, or GIMP for not looking enough like Photoshop.
Plus, Gitlab is already open source, so can you really call it "ripping off"? If you're referring moreso to Github, then I think Gitlab did it first and Gogs is following that trend. I'm sure both projects improve on UI where they feel best.
It's one thing to offer the same UI elements and experience, it's another thing to make it look identical in colors, spacing, fonts, icons, etc... They took it quite far imho.
Can you show some screenshots of what you mean? Gogs[0] looks plenty different from Gitlab[1] in colors, fonts, icons, and spacing. Hardly identical, but both clearly inspired from Github.
It's a bit slower than Stash, but other than that I really love it. Lots of features, and they are easy to use. Upgrading to the newest version has always been simple.
Only gotcha we have had is the timeout of the workers, which meant that some large repositories would be impossible to clone. After adjusting the timeout everything was fine. Although a bit more caching would be in order to speed up clones.
"a bit slower"? My experience with Gitlab was terrible. It's unbearably slow especially when I try to create a relatively large pull request for review. The pull request comparison tool is not very smart either. Often times I have a big chunk of false change detection.
Maybe I was doing it wrong, but I just don't see any advantage of it over the like of Github and Bitbucket.
Depends on how you look at it. Stash is dirt cheap compared to GitHub enterprise so if you think Stash is expensive you are not either of their target audience.
Gogs is great for one-person or small team setups. I switched to it from gitbucket, which is also great and I do recommend it. It was the memory footprint (Go binary vs JVM) that made the choice easy for me.
The functionality I miss the most is search. I think it may be easy to implement some basic form of search using git grep.
What experiences do people have with http://phabricator.org/ ? It's not a GitHub clone but it does seem very complete, possibly replacing Jira and Stash if you're into the Atlassian ecosystem.
I played with it a little bit once for a small personal project. It seems to have all the features you want, but the way you used them never really clicked with me.
Unlike Stash, GitLab, GitHub, Gogs, or others of that nature - though - it expects you to setup your git repositories elsewhere (at least the last time I used it) instead of acting as a receiving host for them (at least the last time I used it - which was a year or two ago at this point).
Phabricator does host git repositories. The workflow is a bit strange when compared to github's more natural PR model, but it works, and is overall quite solid.
Bonus points that in encourages you to upload memes under macros to troll your coworkers when doing code reviews.
I like it much much better than Gitlab, and find it's real good alternative for Atlassian's stack. I've been nothing but pleased with it and I've deployed it a number of places now. The biggest thing is that everything is integrated (i.e. it plays well together, unlike trying to graft Redmine + Gitlab or other combos), and that installation and upgrade is comparatively painless. The sense of humor is also an added plus.
We switched to it 6 months ago and are loving it. We have about 20 developers interacting with it and recently people are starting to move more and more project management and analysis tasks in alongside the code stuff (engineering/modeling/design company).
I've been working on migrating to using phabricator at my company. The developer workflow is a bit different than that of GitHub/GitLab but it's nothing that should hinder development. Primarily it revolves around using a client-side command/utility called 'arcanist' in order to submit code for reviews. The largest difficulty is working with feature branches which is a newer concept at my company.
I have it working with LDAP + ssh access (a la GitHub, everyone uses the 'git' account to push but uses their own keypair for authentication). The review system works quite well, and one thing that I hadn't seen in other systems is the ability to "squash" revisions -> while the code is being reviewed and updated, once it's finally 'landed' into the repository all the diffs can be squished to a single commit rather than having multiple commits correcting eachother. One of the nicer things about running Phabricator is that it has quite a bit of documentation, and
I've been quite pleased with Phabricator, and the bright people working on it are always helpful in the IRC.
The largest gripe I have with Phabricator is the UI is a little tedious at times (multiple page navigations for doing some things which feel like it could be simpler, etc.).
You can create yourself an account on their hosted version, and browse their development of Phabricator: https://secure.phabricator.com/
Edit:
One other thing I wanted to point out which Phabricator does that GitHub/GitLab and others do not appear to - Phabricator starts to form a model around "Ownership" of code which has been useful on a large project. People can elect to be notified when areas of code change that they otherwise would not notice.
Thanks (to you and the others) for your replies. The code ownership thing is interesting, I saw something similar in Zach Holman's presentation on how GitHub works: http://zachholman.com/talk/move-fast-break-nothing/
One of the nicer things about running Phabricator is that it has quite a bit of documentation, and..
..and the install provides really great feedback about how it's running. Server issues are identified and displayed to logged-in administrators, so phabricator actively analyses its status and any reports what actions might need taken. The upgrade process is really smooth as well.
I used it when I was contributing to Wikimedia in Google Code-In. It was very easy to use and the issue system was very powerful. The whole system looks powerful.
Arcanist - command line tool, great!
GUI - confusing, strange names on modules and lots of navigation issues.
Tasks - works, but too clumsy
Workboards - just too bare bone to be functional
code review - one of the better ones
We use gitlab as a replacement for gitosis and in that workflow there is no longer any room for phabricator.
But now that phabricator can self host repos it is a big plus. They should rework the GUI, it is my biggest gripe at the moment.
What I miss in all tools I have tried is to make a random comment in the source tree. I don't want to fake a branch to achieve that.
I use Gogs on my Synology NAS for personal use and I love it. Mostly because it's so easy to setup and deploy - cross-compiling the binary for ARM was simple, after that it was just a matter of SCPing it to the NAS itself.
It's not as feature rich as other options, but it does it's job well.
Then I created a new user, scpd the distribution and added gogs binary to rc.local. I also installed git from the Synology package manager. There was some tweaking involved, but that was mostly it.
We moved to Gogs. GitLab was too slow, and started giving us random 500 errors (fatal bug).
Overall, it's been more enjoyable than Gitlab. Things I don't like:
* No pull requests / issues
* No deploy keys
* It's a full on GitHub replacement in the sense that anybody can sign up to your Gogs instance and use it. Who's using it that way? Would be much better if it were built for one organization with a way to group repos into projects.
I think what he meant was "Why can anyone signup for my Gogs server?" It'd still be nice to have pull requests across teams, or even just as a place for code reviews.
GitLab CEO here, I'm sorry to hear you experienced 500 errors. That shouldn't happen. Did you use our Omnibus packages? https://about.gitlab.com/downloads/ Anyway, if you want to look into it email me at sytse@gitlab.com
I just downloaded this to try it out and it really is insanely easy to get going. Just unzip and `./gogs web`, done. It's also clear what settings and data are getting stored where, so moving / upgrading / removing looks easy.
That in itself is pretty compelling, even if it's clearly not as mature as the competition yet.
What's the value of hosting your own Github alternative as an organization / company? Do people have on-premise requirements and don't want to pay for Github enterprise? I assume most start-ups don't and 25 USD for 10 private repositories isn't going to break the bank.
If you like it someone else might. And submitting it spares the you trouble of maintaining a fork when you upgrade. But making it a project service might be hard. So feel free to not submit it. Alternatively you could write a small blog post about it, maybe it inspires someone else to contribute.
> What's the value of hosting your own Github alternative as an organization / company?
Despite Github maturity not everyone is comfortable hosting their own code at someone else's host. Github could get hacked, employees could copy your code, etc. Github Enterprise can help with these concerns, but it's expensive.
This 100x. A lot of employers (including several I've worked for) have strong security policies, and like have 4-5 nine uptimes; the security aspect, if your code contains a lot of valuable IP, is huge, and I would be rather wary of letting Github be responsible for my own IP for non-open source projects, rather than the more palatable choice of having control over it in-house.
If you have some commercial secrets which you want to keep from competitors who're on friendly terms with US politicians, you often feel uncomfortable having your data hosted under US jurisdiction.
In sensitive domains such as aeronautics, the question of what's hosted where is considered in every collaboration contract, and US or China hosting are typically excluded.
We use at this moment GitHub for "consumption-ready" projects and GitLab internally for young projects.
Reasons for hosting your own:
- Billing is complex as it has to pass through multiple departments;
- Most code never makes it out of the company (I sincerely hope);
- Configuration files and sensitive data sometimes ends up in repositories, especially with young projects.
So GitHub for big, released stuff and internal repositories for small projects and as a developer sandbox.
I have dozens of small repos so Github is too expensive. For example, all of my Golang packages are 2-10 file individual repos as well as Erlang components etc.
Long ago I had asked github if they would offer a size-based account (e.g. $10/month for 1GB of unlimited repos) but they don't. So Gitlab works really well for me.
If you mean globally, then it should be obvious that banks, private research institutes and other sensitive workspaces are NOT going to use an off-premise code hosting solution.
I've been trying both Gogs and GitLab locally for personal projects, and like both for different purposes. GitLab seems to have an edge in terms of larger organizational usage and integrations... but Gogs is faster for smaller orgs and way simpler to set up and manage.
I have a couple quick demo Vagrant configurations you can use to spin up both and choose for yourself which one you like better:
I started using it after getting frustrated with Gitlab's install process on RHEL (a year ago), and I used Gitolite before that. Gitblit has been refreshingly simple to deal with. Am I missing something other than the standard JVM hate?
I see a lovely list of all sorts of features, but then I get to limitations: "Built-in access controls are not branch-based, they are repository-based."
Still looking for a good locally deployable github alternative that has decent issue tracker (i.e. youtrack/jira/tfs level of customization and planinng support) AND pull request support. Are there any? Is this it?
In the "enterprise", my experience is that incentives/expertise fight hard against successful integrations of 'best of breed' products. In large organizations, features for developers are (at least minor) headaches for the build team, so they don't get rolled out.
Github has raised the bar on what to expect from an integrated SCM, and others have followed suit, so I don't much value added by specialist vendors. I kind of think of it like car radios; you used to have to replace the factory system with a third party product, now almost no one does. The deck that comes with the car is plenty good enough, plus it has the integration with the steering wheel, etc.
I was introduced to the concept of integrated defect and issue tracking inside a source control system by IBM CMVC [1]. I'm certain there are even earlier tools that implemented this concept.
If you have a large, distributed team, say more than a couple dozen developers, then a tightly-interwoven defect and issue tracker that disrupts the workflow of the developers as little as possible enables some support organization models that are otherwise very unwieldy. Even with just plain text defect and issue fields, it was pretty remarkable how much sideband material via email was avoided.
Most of the satisfaction with this tooling depended upon (as usual) how management dictated it be used. Developers who had to use these features didn't universally love it though, even with developer-savvy/friendly management. Generally, modulo adverse management interference, if you did a lot of maintenance work on a code base, I can reasonably predict that you would tend to either like the integration, benignly tolerate it, or come to like it; it did save a lot of time, especially for those who automated parts of the related workflow.
This stemmed from being able to start with an issue that simply described the support ticket, evolve it to a defect that identified change sets that encompassed the suspected cause, check out, branch, check in code only related to the specific defect, including ancillary/utility/harness/test code specific to just the defect. It made it easier to "break off" a chunk of code for a specific defect, if someone put in the work to identify those pieces of code and properly used the integrated defect/issue features.
I personally like this kind of integration, and furthermore want regression testing support tied into it, but that's only because I'm really lazy and my memory leaks like a sieve, so getting back into the zone for a specific issue I worked on even only N weeks/months ago, locating all the relevant chunks of code needed, is terribly tedious for me.
I know this is on the front page of https://gogs.io, and also that gogs is made to be self hosted, but have a look at https://notabug.org as a website to host git repositories which runs its own version of gogs.
If they will use Github to develop Gogs, the potential audience may think why they should not use Github itself.
I am not trying to put them down, it's very difficult to dog food when your product is in its early state but their page suggests that they already support Issue Tracking. I think it is in a state where they can use Gogs to develop Gogs. This will ensure that they work on those items which affects developers the most.
To be fair, Gogs is about having your own, possibly private to a company, Git service. Github is about collaboration. Most people wanting to contribute to this are probably already on Github.
I expect dog-fooding by people making tools for other people. There is no reason they can't self-host (without publishing the interface to the entire 'net) and then just use GitHub as another remote to handle external collaboration.
Tried the product again (w/ no repos..) and it looks very nice. Dogfooding, drop the "written in Go" like technomancy says, big-ass buttons "Import from my Github" and "Import from existing repository".
Written in GO is important for us as we have inhouse GO skills, we dont have ruby skills. This tool would be perfect for us, if it had AD/LDAP integration. Being written in GO means we can consider doing it ourselves.
Go look at the code, it's crappily written and virtually unmaintainable. I'm using it right now, but only by breaking it's concurrency. If I let it handle more then 1 request at a time, it starts 404'ing random resources....
"But what if you’re writing some Android app, maybe you’re building the next great iOS game or in general, you’re writing some code that you don’t want to be exposed to the general public ?
You could certainly purchase access to private Github repositories, but most certainly you’d rather want to invest your capital in more pressing matters."
Yeah, the reasoning is not completely sound. I think a better argument to use Gogs would be the fact that your code is self-hosted with the implications of privacy that brings.
Maybe it isn't fair, but every time I see "...written in X" tacked on the end of the tag line, I assume it's a very immature product. If the implementation language is that high on the list of things potential users might be interested in, it's usually a sign that they've got a ways to go.
I wrote up an essay of the three key things that every Git server should have, features that if are missing cause users to decided to look around for alternatives. And you are right, "Written in X" is not on that list.
It has more paragraphs than meets the eye, but for some reason the middle chunk of the article stops double-spacing and starts doing (very small!) indents for paragraphs instead. Some sort of formatting issue.
I had the same reaction. I associate it with weekend projects people post on HN -- "Minecraft written in Elm" or the like.
The claims about it being automatically cross-platform because of Go were also pretty dubious. Most languages are cross-platform until you write code that isn't (or use a dependency that isn't).
Go compiles easily to platform-specific binaries, unlike some other languages which either require a lot of provisioning or middleware to run cross-platform.
Saying that the project is "automatically cross-platform" is just shorthand for saying "no additional configuration is needed to run on platforms supported by the Go compiler"
As a potential user I find the information on the technology used to be pretty helpful, actually. It sets up my hopes for an app that is lighter on the resources than the Ruby on Rails based GitLab, with maybe easier installation process as well.
Install of gitlab is pretty easy with the Omnibus install method and manual install is certainly doable. It runs ok here with 1G RAM on an Atom processor.
Everything's doable, but that is not the point. I once had a client - a one person shop kind of deal - who asked me to install a ticketing software on the same account they hosted their website from. They liked Redmine, another RoR app, so I set it up for them and suddenly everything went down, because the CPU and memory usage went above of what their plan offered. They decided it's not beneficial for them to pay for a better plan, so instead we went with a PHP based solution. So yeah, in some cases technology can be as much - if not more - important, as the list of provided features.
The implementation language has a lot of implications.
* I'm extra wary installing anything written in e.g. PHP: it has a higher chance to be remotely crackable.
* I plan for more CPU and expect higher latency if something I need to run is written in e.g. Ruby.
* I plan for extra RAM and JVM tweaking for things written in Java (or Scala).
* I expect extra setup hassles for things written using Node.
Upsides are easy to see, too.
* I expect that it will be especially easy to read and alter code of something written in especially readable languages like Python, or Ruby, or Go.
* I expect that it will be dead easy to deploy something written in something that gives you a static binary, like Go or C or Haskell.
* I expect that things written in a compiled language like Java, or C, or C#, or Go, etc will run pretty fast.
* I expect that a program written in C has good chances to be optimized for low/efficient resource usage and thus could run well on a low-power device.
* I expect that something written in an elaborate statically-typed language like OCaml or Haskell is not prone to crashing with null-pointer exceptions or memory corruption.
PHP itself might be fine, but it is very widely used, and thus very thoroughly attacked. Unfortunately, a lot of sloppy code still historically exists in PHP. PHP itself is not inherently unsafe, of course.
By the same token, if I deploy a network-facing app that invokes a lot of C code (as opposed to e.g. bytecode), I must be aware of a higher probability of stack smashing, buffer overruns, etc, and plan a deployment accordingly.
And we're working very hard to make sure this is a flawless, uneventful & boring process for 100% of the users https://twitter.com/PentiumBug/status/569930640725946368 We're also working on a package server so you can just use apt-get to upgrade.
We're working on having a packagage server. We wanted to have something for multiple platforms that also supports our Enterprise Edition. We've decided to go with PackageCloud.io on-premises and it will be up in a month. Currently we're doing 1TB+ of package downloads per week.
Gogs looks quite polished and it might attract people who needs to setup a new server. But once you setup your workflow you don't want to worry about it for a while because you want to focus on the actual work. Switching the tool is of the least concern unless the old one broke.
I've been using Gitlab to manage all my personal projects and I am grateful of how many features and constant improvements I get for free. Lots of free software have terrible UIs, eg. ReviewBoard, Jenkins, Graphite etc (these are great projects btw, just the UIs still look like from 2000). But Gitlab's UI is modern, elegant, and shows me all the activities on my projects. So I check my projects regularly and feel encouraged to work on them. Granted I can't tell if it scales for big teams but it is not an issue because I only share the instance with a few friends.
It has ran worry-free for me for almost two years besides occasional updates because I wanted the latest UIs and it helped me focus on coding. Thanks for the great work!
Hi txu, glad to hear your enjoy GitLab. An GitLab certainly scales for larger teams. We have a customer installation with more than 10k developers and there are more than 30k active users on GitLab.com
And we're spending more time to polish the UX to make sure it looks good.
nice. the problem i have with gitlab is not much the upgrage process anymore, but the fact that you don't accept push requests from the community of features that you implemented in the enterprise edition. for example the git hook stuff.
i hope someone who has the time and the skills forks gitlab and merges push requests of new features, even if they are already implemented in your pay-for version.
Can you link to the merge request you refer to? Merging something depends on the quality of the implementation and the use case. We don't say that git hooks will be EE forever and we try so evaluate each merge request on its merits.
> We don't say that git hooks will be EE forever and we try so evaluate each merge request on its merits.
Seems like you sad exactly that a while ago:
"We are unlikely to merge this functionality in CE because there already is a nice implementation in EE."¹
It's your repo. You can do whatever you want with it, no need to merge PR for features that are already in your EE edition. That's why I hope someone forks it, or something better comes around.
Thanks for the link. In the lines before the quote I said "This PoC still leaves a lot of work. Right now the controller writes files, this should be done though gitlab-shell."
We where unlikely to merge it because the code quality was low, if someone makes a good implementation we're more open to merging it.
BTW The pull request in question uses the git hooks to do code linting. I think it is a better user experience to do this in GitLab CI in parallel with the rest of your tests https://about.gitlab.com/gitlab-ci/
> We where unlikely to merge it because the code quality was low
Oh, so it's not because "there already is a nice implementation in EE." Ok.
It's also in disagreement with what you sad on the EE announcement:
"If the community develops code for a feature that is already in EE we will certainly consider merging it or open sourcing the EE feature. This depends on several factors including the seriousness of the merge request, the number of GitLab users requesting this feature and if the feature is useful for small and medium size organizations."¹
For at least this particular feature the community is clearly interested (just by looking at the +1 on the github issue), but you continue to handle the CE version as "demo" software for EE. Which is ok. Just say so clearly.
Hi y0ghur7_xxx, I think the comment you just quoted is the most extensive and the best thing I've written about this. All my other comments are shorter versions of that comment in my mind.
The CE version is not demo or crippleware. It is a fully functioning version of GitLab without any restrictions that is just as performant and secure as the EE version. The only difference is that the EE version has more features.
Another possible option is the Sandstorm.io port of Gitlab. It can be installed as easily as a mobile app. :) That's where I found out about/first tried Gitlab.
In fairness, when someone makes a post specifically saying "replacement for :product:" it's probably fair game to discuss the merits of the product being supposedly replaced.
I mean, if only every CEO was connected enough to read like almost every comment or criticism about their product online...
Thanks! We're looking into reducing the resource footprint, but it is not easy. Right now we're working on a package that makes GitLab easy to install on a Raspberry Pi 2, a request that we've seen a few times of the last few weeks.
I put GitLab on a personal server a week or two ago for some stuff, and I'm sorry to say it but the overwhelming takeaway from that experience was watching it hog memory and spawn what felt like a million processes which somehow lingered for days after uninstallation until I noticed them. This thing runs one process, idles at 0.0% CPU, and is blazing fast in <450MB memory - when all you want is a nice git GUI for a small group it seems pretty perfect.
GitLab is now one of the core products in our business and we (Devs, Ops and PM's) love it.
For Ops:
* It's easy to deploy.
* It's easy to manage / support.
* Gitlab-CI now builds all our Docker images which is great.
* Gitlab-CI runners are a pain in the ass to deploy.
For Devs:
* It's workflow and code review is great.
* GitLab CI is a great alternative to using external CI systems / Jenkins.
For Everyone:
* It's wiki is great (and getting better over time).
* It's fast.
* It's very reliable.
* The community is great as is GitLab as a company.
* GitLab's momentum of the last 6 months has been great and shows no sign of slowing.
We don't have it hosted on very powerful hardware but it flies - so much faster than using Github, or our old internal setup of Gitolite+Gitweb/Redmine
I tried out Gogs yesterday and this is what I took away:
* It's incredibly fast.
* It's incredibly lightweight.
* At first it looks 'pretty' but quickly you it becomes clear that it's actually quite unintuitive to use (for example, it took everyone that tried it here longer than it should to find how to log a new issue).
* There is no wiki.
* There is no CI.
* There is no Debian package which would be nice.
* It's written in a language that most Devs / Ops can't contribute to or bug fix.
All and all, I'm very excited about Gogs for my personal git hosting at home / on my VPS' - but I don't think it's even close to providing the system that GitLab has at present.
Thank you for sharing your points: for me this is actually quite an endorsement of gogs (But then, I'm not looking for an alternative to gitlab).
> * There is no Debian package which would be nice.
True. AFAIK there aren't any packages in Debian that depend on go/golang yet, not even in sid. That doesn't mean one can't make out-of-band debs, of course, but gogs unfortunately isn't alone here. Does anyone know of any util/tool/package in go (other than golang) that's packaged for Debian?
> * It's written in a language that most Devs / Ops can't contribute to or bug fix.
As opposed to what? I'd think being able to patch something in go would be within the grasp of most Ops, and also most devs?
For sure - it's got lots of promise and we are by no means bound to what we've bought into - we'll use whatever's best, at the moment that's Gitlab.
To clarify I didn't mean that it would be nice to have packages that are maintained by or in the default Debian repo - but an apt repo for the project would be nice.
I've found Go a pain to read and hack with - Ruby and Python however are a lot more readable and any of our ops or devs would feel confident in finding / reporting bugs in either.
(Linked from the github page). So there are debs available of gogs. Trying to figure out how to build a deb from the git repo, but if all you want is upstream binary debs, you appear to be covered.
See this stackoverflow q/a -- it appears to contain most of the current highlights. Basically Ubuntu has started packaging a few go apps, and fpm[f] seems to be an ok alternative in the meanwhile:
packager.io (which upstream googs uses) seems to be a nice way to just get packages out there, but as far as I can tell it's pretty well walled-off behind a service, so no easy way to build locally, off-line, or without using packager.io etc. In that sense it strikes me as a poor choice for Free software, as there is no promise that things will continue to work, or can be made to work, long term.
I think I have an idea where you're comming from, but that's still a little too harsh. In case of programs written in go, it's not really all that complicated I think: go pretty much "solves" (ignores by forcing vendoring in) source/build dependencies -- and the resulting build is only a binary and resources. So it's a pretty good fit for stuffing in a cpio/deb-file -- I think what's mostly lacking on the Debian side is motivation (some package or other that is written in go).
Actually, come to think of it... might be time to have a look at apt-get source docker.io...
Not directly about installation process - but about integration with external tools. Looks like you're focused on the SaaS tools, rather than selfhosted ones. Integration with application like Kandan [1], rather than locking with HipChat would be awesome too. And/or Jabber integration also could help a lot. Thank you for the awesome work you're doing by developing GitLab!
Most integrations are contributed by the community. I must admit that KanDan is very interesting and it is good to see it is still alive. It would be awesome if someone could contribute an integration for it.
I love GitLab, I'm using it for my freelance projects, but there's one thing that I encountered that is crucial, choosing which web server you want to use, I have apache2 installed at work and installing the gitlab omnibus package which uses nginx breaks my apache installation and I didn't find it easy to use both alongside.
Besides that, GitLab is fantastic and I thank you for that.
One of the reasons I'm using Bitbucket vs GitHub is that Bitbucket allows free private repositories. Yay, but I love Cogs. Easy to install self hosted version. Sounds perfect for just so many purposes.
> You could certainly purchase access to private Github repositories, but most certainly you’d rather want to invest your capital in more pressing matters.
Getting a few private repositories on GH is $7/month.
It'll cost me more than that for a server, not to mention the time setting up and managing.
Can confirm. Running Gitlab on the $5 (or even $10) Digital Ocean VM is not gonna give you optimal experience unless you are a single user with a tiny repository and dedicate the entire VM to Gitlab (even after that, it is pretty slow on the $5 instance).
Haven't tried Gogs yet but sounds like it would be faster.
sytse: I think installation is not the issue with gitlab. It's rails ecosystem. It's slow, hard to manage and composed of magic. I'm currently using gitlab, promoting it. But this does not mean, I won't leave it at a whim if some contender without rails comes through.
I agree that Rails applications are more complex. But having 100+ gems in GitLab also allows us to reuse a lot of great libraries and deliver features faster. But cgit will always be more performant.
238 comments
[ 2.6 ms ] story [ 227 ms ] threadPersonally I feel for pieces of software like this it's fair to more or less clone the user interface. There's a lot of effort built up in understanding how to use this tool. Think of the complaints LibreOffice gets for not looking enough like Word, or GIMP for not looking enough like Photoshop.
Plus, Gitlab is already open source, so can you really call it "ripping off"? If you're referring moreso to Github, then I think Gitlab did it first and Gogs is following that trend. I'm sure both projects improve on UI where they feel best.
[0] http://gogs.io/imgs/screenshoots/2.png [1] https://about.gitlab.com/images/feature_page/activity_stream...
It's a bit slower than Stash, but other than that I really love it. Lots of features, and they are easy to use. Upgrading to the newest version has always been simple.
Only gotcha we have had is the timeout of the workers, which meant that some large repositories would be impossible to clone. After adjusting the timeout everything was fine. Although a bit more caching would be in order to speed up clones.
Maybe I was doing it wrong, but I just don't see any advantage of it over the like of Github and Bitbucket.
Github enterprise is super expensive.
And Stash (the self hosted equivalent of Bitbucket) is also fairly expensive once you go over 10 users.
I've used it at a few places and had nothing but a good experience. Upgrades are easy and it's easy on boarding people who are used to Github.
I would recommend giving Gitlab another try...
Gitbucket is what I recommend.
It has satisfied all the needs of our small group, which is essentially keeping a visual track of our git repos and permissions.
The functionality I miss the most is search. I think it may be easy to implement some basic form of search using git grep.
Unlike Stash, GitLab, GitHub, Gogs, or others of that nature - though - it expects you to setup your git repositories elsewhere (at least the last time I used it) instead of acting as a receiving host for them (at least the last time I used it - which was a year or two ago at this point).
Bonus points that in encourages you to upload memes under macros to troll your coworkers when doing code reviews.
I have it working with LDAP + ssh access (a la GitHub, everyone uses the 'git' account to push but uses their own keypair for authentication). The review system works quite well, and one thing that I hadn't seen in other systems is the ability to "squash" revisions -> while the code is being reviewed and updated, once it's finally 'landed' into the repository all the diffs can be squished to a single commit rather than having multiple commits correcting eachother. One of the nicer things about running Phabricator is that it has quite a bit of documentation, and
I've been quite pleased with Phabricator, and the bright people working on it are always helpful in the IRC.
The largest gripe I have with Phabricator is the UI is a little tedious at times (multiple page navigations for doing some things which feel like it could be simpler, etc.).
You can create yourself an account on their hosted version, and browse their development of Phabricator: https://secure.phabricator.com/
Edit: One other thing I wanted to point out which Phabricator does that GitHub/GitLab and others do not appear to - Phabricator starts to form a model around "Ownership" of code which has been useful on a large project. People can elect to be notified when areas of code change that they otherwise would not notice.
One of the nicer things about running Phabricator is that it has quite a bit of documentation, and..
..and the install provides really great feedback about how it's running. Server issues are identified and displayed to logged-in administrators, so phabricator actively analyses its status and any reports what actions might need taken. The upgrade process is really smooth as well.
We use gitlab as a replacement for gitosis and in that workflow there is no longer any room for phabricator.
But now that phabricator can self host repos it is a big plus. They should rework the GUI, it is my biggest gripe at the moment.
What I miss in all tools I have tried is to make a random comment in the source tree. I don't want to fake a branch to achieve that.
Once you get used to it, the Differential code review process feels very natural (better than pull requests, even).
Further reading:
http://gregoryszorc.com/blog/2013/10/14/phabricator-is-aweso...
http://cramer.io/2014/05/03/on-pull-requests/
It's not as feature rich as other options, but it does it's job well.
GOOS=linux GOARCH=arm GOARM=7 go build
See http://dave.cheney.net/2012/09/08/an-introduction-to-cross-c... for cross compilation instructions.
Then I created a new user, scpd the distribution and added gogs binary to rc.local. I also installed git from the Synology package manager. There was some tweaking involved, but that was mostly it.
[1] https://www.synology.com/en-global/dsm/5.2beta/productivity
Overall, it's been more enjoyable than Gitlab. Things I don't like:
* No pull requests / issues
* No deploy keys
* It's a full on GitHub replacement in the sense that anybody can sign up to your Gogs instance and use it. Who's using it that way? Would be much better if it were built for one organization with a way to group repos into projects.
It isn't really a deal breaker to not have it built in. There are other ways to use git than following rigidly to the current github model.
It's possible to turn off the registration feature. I've got it integrated into our Active Directory.
It's possible to get project "groups" by creating an organisation per project.
That in itself is pretty compelling, even if it's clearly not as mature as the competition yet.
This makes the coolest tool for remote code review I've ever used.
I don't think it is either upstream-ready or especially advantageous for the project. Am I wrong?
Despite Github maturity not everyone is comfortable hosting their own code at someone else's host. Github could get hacked, employees could copy your code, etc. Github Enterprise can help with these concerns, but it's expensive.
In sensitive domains such as aeronautics, the question of what's hosted where is considered in every collaboration contract, and US or China hosting are typically excluded.
Reasons for hosting your own:
- Billing is complex as it has to pass through multiple departments; - Most code never makes it out of the company (I sincerely hope); - Configuration files and sensitive data sometimes ends up in repositories, especially with young projects.
So GitHub for big, released stuff and internal repositories for small projects and as a developer sandbox.
Long ago I had asked github if they would offer a size-based account (e.g. $10/month for 1GB of unlimited repos) but they don't. So Gitlab works really well for me.
I have a couple quick demo Vagrant configurations you can use to spin up both and choose for yourself which one you like better:
Also, another vagrant installer is https://github.com/tuminoid/gitlab-installer
I started using it after getting frustrated with Gitlab's install process on RHEL (a year ago), and I used Gitolite before that. Gitblit has been refreshingly simple to deal with. Am I missing something other than the standard JVM hate?
That falls under one of the three things that the Git solution must have or else I will just pass and find something else. http://benjamin-meyer.blogspot.com/2014/10/so-you-want-to-bu...
[1]: http://doc.gitlab.com/ee/integration/jira.html
[2]: http://doc.gitlab.com/ce/integration/external-issue-tracker....
Github has raised the bar on what to expect from an integrated SCM, and others have followed suit, so I don't much value added by specialist vendors. I kind of think of it like car radios; you used to have to replace the factory system with a third party product, now almost no one does. The deck that comes with the car is plenty good enough, plus it has the integration with the steering wheel, etc.
If you have a large, distributed team, say more than a couple dozen developers, then a tightly-interwoven defect and issue tracker that disrupts the workflow of the developers as little as possible enables some support organization models that are otherwise very unwieldy. Even with just plain text defect and issue fields, it was pretty remarkable how much sideband material via email was avoided.
Most of the satisfaction with this tooling depended upon (as usual) how management dictated it be used. Developers who had to use these features didn't universally love it though, even with developer-savvy/friendly management. Generally, modulo adverse management interference, if you did a lot of maintenance work on a code base, I can reasonably predict that you would tend to either like the integration, benignly tolerate it, or come to like it; it did save a lot of time, especially for those who automated parts of the related workflow.
This stemmed from being able to start with an issue that simply described the support ticket, evolve it to a defect that identified change sets that encompassed the suspected cause, check out, branch, check in code only related to the specific defect, including ancillary/utility/harness/test code specific to just the defect. It made it easier to "break off" a chunk of code for a specific defect, if someone put in the work to identify those pieces of code and properly used the integrated defect/issue features.
I personally like this kind of integration, and furthermore want regression testing support tied into it, but that's only because I'm really lazy and my memory leaks like a sieve, so getting back into the zone for a specific issue I worked on even only N weeks/months ago, locating all the relevant chunks of code needed, is terribly tedious for me.
[1] http://en.wikipedia.org/wiki/IBM_Configuration_Management_Ve...
It's dead simple, and I haven't had any issues in almost two years (though my needs are small, just supporting a small team with very low volume).
I am not affiliated with the project.
If they will use Github to develop Gogs, the potential audience may think why they should not use Github itself.
I am not trying to put them down, it's very difficult to dog food when your product is in its early state but their page suggests that they already support Issue Tracking. I think it is in a state where they can use Gogs to develop Gogs. This will ensure that they work on those items which affects developers the most.
Because you have to pay for private repos and pay even more to host your own deployment?
Thanks!
Especially when it's an open-source project and GitHub is a large nexus of OSS development.
This should be more popular!
You could certainly purchase access to private Github repositories, but most certainly you’d rather want to invest your capital in more pressing matters."
... BitBucket!
http://benjamin-meyer.blogspot.com/2014/10/so-you-want-to-bu...
The claims about it being automatically cross-platform because of Go were also pretty dubious. Most languages are cross-platform until you write code that isn't (or use a dependency that isn't).
Saying that the project is "automatically cross-platform" is just shorthand for saying "no additional configuration is needed to run on platforms supported by the Go compiler"
* I'm extra wary installing anything written in e.g. PHP: it has a higher chance to be remotely crackable.
* I plan for more CPU and expect higher latency if something I need to run is written in e.g. Ruby.
* I plan for extra RAM and JVM tweaking for things written in Java (or Scala).
* I expect extra setup hassles for things written using Node.
Upsides are easy to see, too.
* I expect that it will be especially easy to read and alter code of something written in especially readable languages like Python, or Ruby, or Go.
* I expect that it will be dead easy to deploy something written in something that gives you a static binary, like Go or C or Haskell.
* I expect that things written in a compiled language like Java, or C, or C#, or Go, etc will run pretty fast.
* I expect that a program written in C has good chances to be optimized for low/efficient resource usage and thus could run well on a low-power device.
* I expect that something written in an elaborate statically-typed language like OCaml or Haskell is not prone to crashing with null-pointer exceptions or memory corruption.
No language war/php sucks discussion, but this isn't even remotely true :/
[0] http://sakurity.com/blog/2015/03/15/authy_bypass.html ("How "../sms" could bypass Authy 2 Factor Authentication".)
By the same token, if I deploy a network-facing app that invokes a lot of C code (as opposed to e.g. bytecode), I must be aware of a higher probability of stack smashing, buffer overruns, etc, and plan a deployment accordingly.
Upgrading GitLab is as simple as:
And we're working very hard to make sure this is a flawless, uneventful & boring process for 100% of the users https://twitter.com/PentiumBug/status/569930640725946368 We're also working on a package server so you can just use apt-get to upgrade.I also noticed that the current instructions were not very copy-paste friendly and made some small changes to remedy that https://gitlab.com/gitlab-org/omnibus-gitlab/commit/51d51fe1...
I've been using Gitlab to manage all my personal projects and I am grateful of how many features and constant improvements I get for free. Lots of free software have terrible UIs, eg. ReviewBoard, Jenkins, Graphite etc (these are great projects btw, just the UIs still look like from 2000). But Gitlab's UI is modern, elegant, and shows me all the activities on my projects. So I check my projects regularly and feel encouraged to work on them. Granted I can't tell if it scales for big teams but it is not an issue because I only share the instance with a few friends.
It has ran worry-free for me for almost two years besides occasional updates because I wanted the latest UIs and it helped me focus on coding. Thanks for the great work!
And we're spending more time to polish the UX to make sure it looks good.
http://blogs.msdn.com/b/oldnewthing/archive/2015/03/10/10598...
Nice to hear you're working on something simpler than simple. :-)
i hope someone who has the time and the skills forks gitlab and merges push requests of new features, even if they are already implemented in your pay-for version.
Seems like you sad exactly that a while ago:
"We are unlikely to merge this functionality in CE because there already is a nice implementation in EE."¹
It's your repo. You can do whatever you want with it, no need to merge PR for features that are already in your EE edition. That's why I hope someone forks it, or something better comes around.
¹https://github.com/gitlabhq/gitlabhq/pull/6883#issuecomment-...
We where unlikely to merge it because the code quality was low, if someone makes a good implementation we're more open to merging it.
BTW The pull request in question uses the git hooks to do code linting. I think it is a better user experience to do this in GitLab CI in parallel with the rest of your tests https://about.gitlab.com/gitlab-ci/
Oh, so it's not because "there already is a nice implementation in EE." Ok.
It's also in disagreement with what you sad on the EE announcement:
"If the community develops code for a feature that is already in EE we will certainly consider merging it or open sourcing the EE feature. This depends on several factors including the seriousness of the merge request, the number of GitLab users requesting this feature and if the feature is useful for small and medium size organizations."¹
For at least this particular feature the community is clearly interested (just by looking at the +1 on the github issue), but you continue to handle the CE version as "demo" software for EE. Which is ok. Just say so clearly.
¹https://about.gitlab.com/2013/07/22/announcing-gitlab-enterp...
The CE version is not demo or crippleware. It is a fully functioning version of GitLab without any restrictions that is just as performant and secure as the EE version. The only difference is that the EE version has more features.
That they said "there already is a nice implementation in EE" doesn't automatically mean they also intended it to remain EE-specific forever.
It could be also be read as "we won't merge this in the free edition, as we already have a nice implementation in EE we might merge later".
Could you maybe stop shouting GITLAB! all over this thread that's not about Gitlab?
I mean, if only every CEO was connected enough to read like almost every comment or criticism about their product online...
Do you have any plans for decreasing the resource footprint. I think the OP has a strong point in stating that it is a bit of a RAM drainer.
GitLab is now one of the core products in our business and we (Devs, Ops and PM's) love it.
For Ops: * It's easy to deploy.
* It's easy to manage / support.
* Gitlab-CI now builds all our Docker images which is great.
* Gitlab-CI runners are a pain in the ass to deploy.
For Devs:
* It's workflow and code review is great.
* GitLab CI is a great alternative to using external CI systems / Jenkins.
For Everyone:
* It's wiki is great (and getting better over time).
* It's fast.
* It's very reliable.
* The community is great as is GitLab as a company.
* GitLab's momentum of the last 6 months has been great and shows no sign of slowing.
We don't have it hosted on very powerful hardware but it flies - so much faster than using Github, or our old internal setup of Gitolite+Gitweb/Redmine
I tried out Gogs yesterday and this is what I took away:
* It's incredibly fast.
* It's incredibly lightweight.
* At first it looks 'pretty' but quickly you it becomes clear that it's actually quite unintuitive to use (for example, it took everyone that tried it here longer than it should to find how to log a new issue).
* There is no wiki.
* There is no CI.
* There is no Debian package which would be nice.
* It's written in a language that most Devs / Ops can't contribute to or bug fix.
All and all, I'm very excited about Gogs for my personal git hosting at home / on my VPS' - but I don't think it's even close to providing the system that GitLab has at present.
> * There is no Debian package which would be nice.
True. AFAIK there aren't any packages in Debian that depend on go/golang yet, not even in sid. That doesn't mean one can't make out-of-band debs, of course, but gogs unfortunately isn't alone here. Does anyone know of any util/tool/package in go (other than golang) that's packaged for Debian?
> * It's written in a language that most Devs / Ops can't contribute to or bug fix.
As opposed to what? I'd think being able to patch something in go would be within the grasp of most Ops, and also most devs?
To clarify I didn't mean that it would be nice to have packages that are maintained by or in the default Debian repo - but an apt repo for the project would be nice.
I've found Go a pain to read and hack with - Ruby and Python however are a lot more readable and any of our ops or devs would feel confident in finding / reporting bugs in either.
http://gogs.io/docs/installation/install_from_packages.md
(Linked from the github page). So there are debs available of gogs. Trying to figure out how to build a deb from the git repo, but if all you want is upstream binary debs, you appear to be covered.
http://stackoverflow.com/questions/15104089/packaging-golang...
packager.io (which upstream googs uses) seems to be a nice way to just get packages out there, but as far as I can tell it's pretty well walled-off behind a service, so no easy way to build locally, off-line, or without using packager.io etc. In that sense it strikes me as a poor choice for Free software, as there is no promise that things will continue to work, or can be made to work, long term.
[f] https://github.com/jordansissel/fpm
Actually, come to think of it... might be time to have a look at apt-get source docker.io...
[1] https://github.com/kandanapp/kandan/ [2] http://feedback.gitlab.com/forums/176466-general/suggestions...
http://feedback.gitlab.com/forums/176466-general/suggestions... is marked accepting merge requests, we would love to see this too
Besides that, GitLab is fantastic and I thank you for that.
Getting a few private repositories on GH is $7/month.
It'll cost me more than that for a server, not to mention the time setting up and managing.
(Full disclosure: I'm a developer at GitLab B.V.)
lol
I should probably set up SSL, backups, patch it occasionally, etc., which is going to pretty quickly eat that up.
The cool thing about this is that it makes self-hosting a viable option for more people.
Haven't tried Gogs yet but sounds like it would be faster.