"You could certainly purchase access to private Github repositories, but most certainly you’d rather want to invest your capital in more pressing matters."
That's their #1 reason? GitHub is, like, $7. If that saves you 10 minutes of having to maintain your own servers? Completely seems worth it to me. Or, GitLab or BitBucket have free private repos.
My argument is this: your time is the most important thing you have, and you shouldn't be wasting your time on maintaining your own source control servers.
I would love to use GitHub more, but it becomes pricey for 20+ repos.
Remember companies that sell cloud services have a vested interest in making you believe that it always makes financial sense to use a cloud hosted product which as those of us that have experience in both cloud hosted and on site deployments will tell you is not always the case.
At this point, my server replaces:
- A site host
- Image host
- Streaming video service (Netflix replacement)
- File host (Dropbox replacement)
- Build server
- Git repository host
- Proxy
- Render server
- Hosts all the random webapps I write
- Game hosting
Consider the organization that needs hosted GitHub enterprise - a pricey proposition. Unless you could otherwise have spent your time working on a feature that would directly increase sales (which is probably unlikely in an enterprise locale) then your time really is just sunk cost.
So to recap, for the one-off private repo - probably easier and more sensible in terms of resources to use GitHub. For a large organization that has man hours to burn or otherwise needs an in-house hosted solution, GitLab (or Gogs) could make sense.
Still, compared to the Perforce server crashing every other week (a slight exaggeration, but still), it's a marked improvement.
And then you wrote this comment, spending these alleged pair of minutes bragging about how cheap it is to just pay for something.
On the other hand, I remember spending a fair bit of time and energy at my current company to get approved 10$ per month Bitbucket plan. Let's say it took us months to actually get it declined. Then, we happily spent 200$ per month for a virtual machine that we had to maintaint and ended up installing Gitblit.
I'd love to use GitHub for my personal projects but there are too many different ones.
I wish it were metered by what it actually costs them (storage) rather than stupid arbitrary numbers like repo count.
My umbrage is simply with the price argument Gogs lead with; it'll always end up cheaper to use GitHub (or another hosted solution) than to run your own.
Upgrading GitLab is as simple as:
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
sudo gitlab-rake gitlab:backup:create
sudo dpkg -i gitlab_x.x.x-omnibus.xxx.deb
sudo gitlab-ctl reconfigure
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.
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?
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.
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...
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.
[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.
I have a couple quick demo Vagrant configurations you can use to spin up both and choose for yourself which one you like better:
- Gogs: https://github.com/geerlingguy/ansible-vagrant-examples/tree/master/gogs
- GitLab: https://github.com/geerlingguy/ansible-vagrant-examples/tree/master/gitlabAlso, another vagrant installer is https://github.com/tuminoid/gitlab-installer
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.
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...
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.
Especially when it's an open-source project and GitHub is a large nexus of OSS development.
Because you have to pay for private repos and pay even more to host your own deployment?
This should be more popular!
Considering that English is not their native language, I'd say they're doing pretty darn well so far. Speaking with at least one of the developers personally and via email, I've never had any trouble.
> don't expect assistance from the community
Well that's a mighty presumptuous thing to say about a lot of good people. By and large, the Go community likes Gogs and its developers. I've met Jiahua personally. He's a solid guy and one really dedicated developer. Overall, the Go community wants Gogs to be great.
If you don't like Gogs, you don't have to use it. But you're raising a warning about it because you think the Go community treats it like some sort of poison and that the developers are incompetent. Neither are true.
I'll admit, I don't speak for the community as a whole, but about every go developer I've spoken to has the same feeling I do, and it's echoed all over the web. Macaron, the central framework, is inspired by, and rather heavily follows, the style of Martini. It's dependency injection and runtime reflection code style is considered highly unsafe. But don't take my word for it, maybe you'll listen to the author of Martini? http://codegangsta.io/blog/2014/05/19/my-thoughts-on-martini... Or the post it's in response to? https://stephensearles.com/three-reasons-you-should-not-use-...
- Installation (and liberty to chose between 3 database engines) couldn't be easier. No Gitlab's omnibus package doesn't come even close.
- Gogs does support issues. Proper Github like issues with labels, milestones, assignees, markdown etc.
- There are no pull requests. And you can't edit files from the web interface. I bet Linus Torvalds will love it and ask Github to shutdown in favor of Gogs.
- The interface is pretty much the same as Github, so ++ there too.
- Sending commit messages like "do something, fixes #3" won't close #3.
- You cannot code review, comment on diffs, or commits. This one hurts me.
- Is too much fast and less resource intensive compared to Gitlab, so ++ if you are resource limited.
I would recommend to run locally for small personal projects. OR if you just want a web interface to git, and not a browser based version control system.
It contained some __MACOSX, ._* and .DS_Store files. They don't disturb anything but thats just careless packaging.
The executable bit on the executable was not set.
The config file suggests fo generating keys:
; Generate steps:
; $ cd path/to/gogs/custom/https
; $ ./gogs cert -ca=true -duration=8760h0m0s -host=myhost.example.com
Once it's up and running, I do like it so far for my personal repositories.
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
It has satisfied all the needs of our small group, which is essentially keeping a visual track of our git repos and permissions.
Gitbucket is what I recommend.
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...
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 am not affiliated with the project.
The functionality I miss the most is search. I think it may be easy to implement some basic form of search using git grep.
> The functionality I miss the most is search.
> it may be easy to implement some basic form of search using git grep.
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.
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...
Github enterprise is super expensive.
And Stash (the self hosted equivalent of Bitbucket) is also fairly expensive once you go over 10 users.
This was pretty quick. As a Go person myself, I love the single binary way.
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.
Haven't tried Gogs yet but sounds like it would be faster.
(Full disclosure: I'm a developer at GitLab B.V.)
I should probably set up SSL, backups, patch it occasionally, etc., which is going to pretty quickly eat that up.
So, no, it does not bother me. :-)
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.
* 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 :/
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"
http://benjamin-meyer.blogspot.com/2014/10/so-you-want-to-bu...
That said, the project is pretty cool.. it just bugs me a little that people always reach for a full product for small teams with private git needs.
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.
This makes the coolest tool for remote code review I've ever used.
I'm interested in Gogs because gitlab seems to have trouble servicing multiple requests, like when deploying to four servers and they all try to pull code at once (three of them fail). We could have just misconfigured something, but it's hard to imagine there's a config option for "fall over on concurrent requests."
On GitLab.com we have 20+ unicorn workers that handle over 30k monthly active users.
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!
That in itself is pretty compelling, even if it's clearly not as mature as the competition yet.
Well, Google Code was never used for private repositories, so that argument is irrelevant for the intended free private repository introduction.
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).
[1]: http://doc.gitlab.com/ee/integration/jira.html
[2]: http://doc.gitlab.com/ce/integration/external-issue-tracker....
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...
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.
Gogs isn't a hosted service; you're installing it on servers you control, so you retain ownership of your content. (I suppose there would be questions about ownership if you uploaded content to their demo instance at try.gogs.io, but you probably shouldn't upload things you care about to a demo server like that.)
Only commenting because I found their docker setup to be far overcomplicated (uses fig and I couldn't be bothered figuring out what I needed / didn't)