Gogs, an alternative to Gitlab | Hacker News Reader

Gogs, an alternative to Gitlab

apertoire.net

424 pointsapertoire231 comments

I love OSS, however I hate this argument:

"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.

Some people have way more than 5 repositories that a $7 plan brings. Also, if you don't want to host it yourself, GitLab.com has free private and public repositories https://about.gitlab.com/gitlab-com/

For the record, I think GitLab is awesome :) There's a ton of amazing reasons for large companies to use GitLab (storing your own data, customization, etc) that I completely stand by.

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.

That's true if you're running a typical business. But there really is a whole other world that opens up when things are free.

Maybe you are a young person, and don't have access to online payment methods. $84/year or more could be really significant for a 15 year old, or someone in a country that Github can't legally transact with.

Or maybe you need to roll your own hosting solution. Maybe for security, maybe you're integrating with APIs like a corp SSO that are not on the public web, etc.

We do a few wacky things in our business (test infrastructure SaaS) and sometimes we need to do stuff at scale where all available commercial solutions assume a single user. Open source solutions are a godsend there. We don't have that need for code repos (we use Github) but I can totally see why others would need it.

I really wish GitHub only counted private repos that have more than one collaborator. If you are like me and have dozens and dozens of smaller repos that only you yourself work on, it makes the GitHub model a non-starter (and I'd love to be GitHub only, rather hosting my own server or using bitbucket).

Yeah. I pay for GitHub micro plan and indeed for my personal libraries I use bitbucket. It got a decent cli so I create the remote repo from my terminal.

I would love to use GitHub more, but it becomes pricey for 20+ repos.

How would Github differentiate between you and another collaborator that uses your logon details?

Good point "here's our Github account" would become a common solution for free private repos.

How does BitBucket? They don't, and that's okay, there will always be those who push the boundaries of the rules, but most people will be honest.

What about is tiers based on storage?

Short of biometrics, there is no way any online service can differentiate between you and another person with whom you have shared your credentials.

I'd like to hear counterexamples if you have any.

For a private repo with just yourself, why not use BitBucket? You don't need any of the social features of Github in that case.

Simply personal preference. I'd like to use the same supporting tools, UI, zero context switching between products, etc. Funny enough, I use some of the social features (issues/milestones/wiki) for project management, even for my own projects.

Bitbucket provides those. I use it professionally because I like all my stuff in one place and that's where I keep my free private repos.

While bitbucket have some similar features to github (or vice-versa), the features are not the same. So if you want to use only one interface, and you prefer github for projects with multiple collaborators, bitbucket isn't really much of an alternative. Or, if you prefer bitbucket, but is also professionally involved in a number of projects hosted on github, you're still stuck with two interfaces (this is likely the case for pretty much everyone, as almost everyone will have a dependency of some kind hosted on github, and at one point or other you'll probably want to/have to deal with upstream).

This would be true even if bitbucket was (subjectively) better: assuming one values having one consistent interface more than the "best" interface.

I don't necessarily think github's interface(s) are better than bitbucket (or that either are good, for that matter) -- but I can certainly relate to the desire for having a consistent interface, to lower cognitive overhead.

For me, that's the main argument for using Free/Open solutions, that one can self-host: one can guarantee consistency, which in turn can save time. There'll always be a balance between how much time is needed for managing such solutions, and between stability and stagnation.

All that said, it's hard to deny that github managed to leverage the network effect much more dramatically than either self-hosted CVS, stand-alone bugzilla+wiki or Source Forge managed to do. (The latter probably because they didn't realize what they business model should have been: not ads, but charging for forge-services. Then again, AFAIK github isn't profitable, either, yet?).

Re: Debian -- I see that the notabug.org gogs repo[r] contains a debian-folder, and the package build-depends on gccgo (and gccgo-go, which doesn't appear to be in Debian at all, but is in Ubuntu[g]). My initial attempt to build it under plain Debian 7.0 Wheezy (without gccgo-go, just with a "-d"-override) failed -- but perhaps it works on Ubuntu 14.04.

I don't have any idea about the quality/approach taken wrt Debian packaging, just thought it might be a point of interest.

[r] https://notabug.org/hp/gogs/

[g] http://packages.ubuntu.com/search?keywords=gccgo-go&searchon...

Some people also have regulatory reasons to store their code on-premise. Sometimes the "correct" answer is to hire a team of sysadmins and one of their responsibilities is to maintain a SCM infra in-house. It really isn't that hard.

Time is often managed at a lower pay scale than money and is less likely to be micromanaged. It is generally easier for a developer or manager to squeeze in a few extra hours working on a specific need than it is to get the equivalent money dedicated to the exact same issue. This is probably because most companies look at their employee's salaries as sunk costs and fail to factor in the opportunity cost of an employee's time. Not saying that is the correct way to do things, just what I have discovered through experience.

My argument would be your freedom is the most important thing you have, and you shouldn't throw it away for the convenience of github.

Well, your salary is something of a sunk cost. Now depending on the amount of time spent managing that GitLab server, it might make financial sense. If it is truly easy to maintain as they seek, and claim, then it just might make sense.

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.

GitLab has been ridiculously easy to manage for us. Really my only complaint is that it's slow as all hell, and gives up too early on a lot of pages because of this.

Still, compared to the Perforce server crashing every other week (a slight exaggeration, but still), it's a marked improvement.

That's if you only have 5 repos. If you don't want to be forced into the 1-big-repo thing and have many discrete projects/microservices, GitHub gets really expensive fast.

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 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.

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.

Until you have to deploy something with automated provisioning tools and Github or Bitbucket is down. It has happened a few times. We use gitolite with no UI for this very reason.

I think it's unfair to compare self-hosted to shared hosting. GitHub Enterprise is not $7 self-hosted. It's $5K/year.

For my personal stuff, I'm happy to pay GitHub to host my private repositories, but it's not always that simple. I work for a large, bureaucratic corporation in a heavily regulated industry. If something costs money -- even a dollar -- someone has to pay for it, which means that someone has to approve the expense, which means you need a risk assessment and permission from legal. Even if it doesn't cost money, there are a lot of bureaucratic hassles associated with using external services to store company IP. Sure, maintaining your own source control server takes time, but so do the alternatives.

It's not really that simple. For people that already do it - managing servers is easy and doesn't take much time at all. One of the main reasons to run your own code repo is that you're in control of your data and you're not limited by the performance or features of the upstream vendor. Not to mention how much faster having your code repo running internally is - when you have 100 people commit code to and from git all day along with using other 'cloud' products you end up eating up a lot of bandwidth - and in many countries that's really expensive (Australia being one of them).

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.

Exactly. I have a somewhat beefy server that I continue to use just for personal things. Once you're well acquainted with self hosting, the successive time investment drops dramatically, and the rewards become substantial.

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

By spending my time, I not only get these services, but the expertise to manage and run other services. It's less rewarding in the short term, since I certainly didn't get all this right when I bought the thing, but at this point I am getting a ton of return on my invested time.

Do you need a static ip for that kind of stuff?

It's not necessarily a requirement, but I find it very helpful. Any dedicated server package will include one, so it's not to much of a worry.

Hi, GitLab CEO here. Installing GitLab should take only 2 minutes with the Omnibus packages available on https://about.gitlab.com/downloads/

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

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.

Looks like you need a `gitlab-ctl upgrade` command

Good idea, I made an issue https://gitlab.com/gitlab-org/omnibus-gitlab/issues/471

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...

Why not just do apt-get update like (substantially) everybody else?

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.

Heh, "simple"...

http://blogs.msdn.com/b/oldnewthing/archive/2015/03/10/10598...

Nice to hear you're working on something simpler than simple. :-)

:) I agree, it should really be one command. We'll look at making it better, https://news.ycombinator.com/item?id=9212456

Pretty ripe coming from MSDN...

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.

¹https://github.com/gitlabhq/gitlabhq/pull/6883#issuecomment-...

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.

¹https://about.gitlab.com/2013/07/22/announcing-gitlab-enterp...

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.

>Oh, so it's not because "there already is a nice implementation in EE." Ok

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".

I agree with this actually - the whole public Gitlab CE vs EE repos and management is a bit of a mess - it seems to be getting better though.

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.

Yeah, thanks for the hard work of David Renshaw from SandStorm for making that work.

Just FYI you're now every grandchild comment of this grandparent.

Could you maybe stop shouting GITLAB! all over this thread that's not about Gitlab?

OK, I'll reduce the volume a bit, thanks for the feedback.

You're answering specific questions about your product, nothing wrong with that.

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...

Whoa, easy with the thread policing. He's specifically replying to people asking him questions, not randomly shouting.

Congrats about GitLab it's amazing, you guys rock.

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.

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 just tried setting up GitLab and after running reconfigure it seems to just hang. Is my sever (2GB Linode) too slow for GitLab?

2GB should be enough, can you email support@gitlab.com and reference this comment in your email?

Thanks, I just sent an email.

It would be great to have these packages available for the fantastic https://alpinelinux.org Have a nice day!

Thanks! I can't promise anything but we'll take your suggestion into account.

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.

I'm sorry to hear you experienced stray processes. Did you use the Omnibus packages? Did you use gitlab-ctl stop?

+1 (Or can I give +1million?) to Gitlab.

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.

Actually, I was wrong (also in my sibling comment):

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.

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:

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

I've used FPM for small things that aren't too complex but I certainly wouldn't trust the Ubuntu packaging team.

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...

Thanks mrmondo, glad to hear you like GitLab!

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!

[1] https://github.com/kandanapp/kandan/ [2] http://feedback.gitlab.com/forums/176466-general/suggestions...

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.

http://feedback.gitlab.com/forums/176466-general/suggestions... is marked accepting merge requests, we would love to see this too

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.

Glad to hear you love GitLab. If you want to use the Omnibus packages with Apache please see https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc... Edit: I tried to make this easier to find with https://gitlab.com/gitlab-org/omnibus-gitlab/commit/e2f9d17d...

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:

  - Gogs: https://github.com/geerlingguy/ansible-vagrant-examples/tree/master/gogs
  - GitLab: https://github.com/geerlingguy/ansible-vagrant-examples/tree/master/gitlab

Thanks for the Vagrant image! We like to think that GitLab is simple to setup and manage if you use the Omnibus packages.

Also, another vagrant installer is https://github.com/tuminoid/gitlab-installer

Thanks for the vagrant files, super easy to set up.

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.

"No pull requests" and "It's a full on GitHub replacement" seem like incompatible statements.

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.

You can always use another code review tool to do pull requests. You can also do it the way Linus does with pull request emails (git request-pull).

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.

Yeah, no pull requests is an instant deal breaker.

They'll be included in some near future release. See this: https://github.com/gogits/gogs/issues/5

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 have to say, I appreciate your willingness and approach in solving problems and improving your product. Keep up the good work!

Thanks lifty!

> anybody can sign up to your Gogs instance and use it.

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.

Why do I rarely see Gitblit talked about as an open source alternative to GitHub? It does a lot: http://gitblit.com/features.html, including a well thought out ticket workflow: http://gitblit.com/tickets_overview.html It's also very easy to install, since it only needs a JVM.

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 haven't seen Gitblit before - thanks for the mention. I will check it out and see if it offers me any wins over GitLab.

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."

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...

Why are they not dogfooding?

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.

> If they will use Github to develop Gogs, the potential audience may think why should I not use Github itself?

Because you have to pay for private repos and pay even more to host your own deployment?

also, they might be using github because it's already open to the wide audience that might want to contribute.

Their feature comparison shows that they do support Issue Tracking.

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.

They don't support issue tracking yet. Not really something you'd want for the development process.

I see issue tracking on the demo site: https://try.gogs.io/moulaf/VLC-git/issues

Oh, indeed. My bad, that's good to know - It seems that I misread that code review section where they were talking about GitHub issues.

Thanks!

If a primary stated goal is self-hosting private repositories, why would you expect them to self-host?

Especially when it's an open-source project and GitHub is a large nexus of OSS development.

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".

This should be more popular!

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....

Just as a warning, I don't consider gogs to be stable enough for production use. There's data race errors that pop up, resulting in errors resolving various assets. I've had everything from user's avatar icons to the main homepage randomly error out as 404. The dev doesn't seem to understand that data races, i.e. unsafe cross thread data access, is an issue. In addition, note that it and least some of the libraries it uses are written by devs for whom english is at best a second language, so expect difficulties communicating. Finally, a lot of the paradigms it uses are considered un-idiomatic by the golang community at large, so don't expect assistance from the community(for instance, dependency injection and reflection powered "magic").

> note that it and least some of the libraries it uses are written by devs for whom english is at best a second language, so expect difficulties communicating

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 tried to get the developer to fix my issue, or even consider it as an issue, but got no where.

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-...

I explored it heavily for the last 2 minutes on my Ubuntu 14.04 fresh VM.

- 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.

Just downloaded the current linux binary package. Unfortunately, installing is not yet as easy as unzipping the archive as the article claims.

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

The path to the binary here has to be ../../gogs and the mentioned directory has to be created.

Once it's up and running, I do like it so far for my personal repositories.

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.

Care to share how did you get it working on Synology? Thanks very much.

Uhm, basically I built it on my mac with

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.

Thanks izacus for sharing!

I would be interested by a more in-depth how-to too.

Synology has also just announced Docker support on DSM 5.2 beta [1], so we could also run Gogs as a docker image :)

[1] https://www.synology.com/en-global/dsm/5.2beta/productivity

There's also Gitbucket which has as similar advantage: https://github.com/takezoe/gitbucket

+1, Gitbucket is quite nice.

Deployment is trivial, and it is very stable.

Gitbucket is what I recommend.

I found gitbucket after trying (unsuccessfully) to run gitlab on my 512mb RAM VM.

It has satisfied all the needs of our small group, which is essentially keeping a visual track of our git repos and permissions.

You probably just needed more swap. If you already had 1.5GB, maybe try it with 2GB. https://news.ycombinator.com/item?id=9212476

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).

This has changed; we've supported hosted repositories since late 2013.

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.

What integration are you missing from GitLab? It has issue tracking, version control, code reviews, wiki's, CI and CD out of the box. Maybe we can use a little more of https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELO...

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/

I realized I left a dangling sentence:

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.

Phabricator is a brilliant piece of software. Very well written code, an emphasis on security, nice UI, tons of features.

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/

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.

I am not affiliated with the project.

https://gogs.io/ seems to be a completely different site from http://gogs.io/, and has the wrong certificate as well.

My bad! Accidently just assumed https.

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.

  > The functionality I miss the most is search.
  > it may be easy to implement some basic form of search using git grep.

Or maybe have Gogs integrate The Platinum Searcher - a code search tool similar to ack, written in Golang: https://github.com/monochromegane/the_platinum_searcher

We run Gitlab at work.

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.

The advantage is that it's free to host it yourself.

Github enterprise is super expensive.

And Stash (the self hosted equivalent of Bitbucket) is also fairly expensive once you go over 10 users.

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.

Self hosting is a big plus for Gitlab.

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...

Gitlab has gotten much faster in recent releases.

Indeed, and false range detection should also not be a problem anymore.

I like this a lot. Gitlab was hard to get running for me on Debian. Plus it was a rails project so it always takes 10 seconds to start up.

This was pretty quick. As a Go person myself, I love the single binary way.

> 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.

Unlike GitLab, gogs can probably run well on a $5 DigitalOcean instance.

Digital Ocean recommends running GitLab on their $10/month instance, so while I haven't tried it, the $5 one is probably still up to the task: https://www.digitalocean.com/features/one-click-apps/gitlab/

(Full disclosure: I'm a developer at GitLab B.V.)

If you're going for the 512MB please read the requirements https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/inst... (make sure to set up swap and use ssh access)

> 512MB RAM + 1.5GB of swap is the absolute minimum

lol

Leaving me with an entire annual savings of $24 over Github.

I should probably set up SSL, backups, patch it occasionally, etc., which is going to pretty quickly eat that up.

You could use BitBucket. They have free private repositories.

The cool thing about this is that it makes self-hosting a viable option for more people.

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.

I've got Gitlab running on a DigitalOcean droplet, and even if you choose not to use their pre-built images, setting up Gitlab is very easy.

Is it just me, or does it bother anyone that the design seems SO ripped from Github? Github's UI has a lot to be said for it and perhaps emulation is more of a compliment here, but...even the icon font glyphs...

Look-and-feel is famously not copyrightable in the US, and there's a familiar interface brings a lot of benefit to the user.

So, no, it does not bother me. :-)

Totally valid -- I guess I just like to see projects that try something new out, develop their own design, or at least put their own spin on something. Just a personal preference, really.

They are literally using Github's icons set.

https://octicons.github.com/

Looks like the font itself is OFL and any code is MIT, so reuse is perfectly reasonable.

https://github.com/github/octicons/blob/master/LICENSE.txt

At what point does it become a concern when you're just ripping off the UI of a competing product?

Isn't GitLab doing the same thing?

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.

How original can you be if you want your product name to be explicit that it works with git?

and as short as possible in the domain name sense

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.

Something something good artists, great artists?

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.

[0] http://gogs.io/imgs/screenshoots/2.png [1] https://about.gitlab.com/images/feature_page/activity_stream...

I think the idea is that Gogs mimics GitHub, not Lab.

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.

http://benjamin-meyer.blogspot.com/2014/10/so-you-want-to-bu...

I can't believe you convinced me to click on that link. Could you introduce more paragraphs and/or bullet points and then get back to me?

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.

Some really nasty markup. Whatever CMS that's generated by, it's using BRs to simulate paragraphs and isn't doing a very good job of it.

Its Google's Blogger

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).

More like "So far, it's cross platform on all the platforms I have compiled it on".

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.

> e.g. PHP: it has a higher chance to be remotely crackable

No language war/php sucks discussion, but this isn't even remotely true :/

Or at least, we can see that Ruby can have stupid security holes too, for example[0].

[0] http://sakurity.com/blog/2015/03/15/authy_bypass.html ("How "../sms" could bypass Authy 2 Factor Authentication".)

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.

It really bugs me that more people forget that you can use git+ssh on any shared server, if you don't have the Pull-Request/review support, why bother with more?

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.

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.

Actually, $12 a month for 10 private repos.

That pricing is for Individual accounts, not Organizations. $25 for 10 private repos is accurate for the latter.

Ability to add together.js button into the GitLab's Merge Request template.

This makes the coolest tool for remote code review I've ever used.

Sounds cool! Consider contributing it back to GitLab as a project service. Make sure to mention this comment in your merge request.

Actually it's just one <script> header, and a single (ugly) <button> tag duct-taped right into the page template.

I don't think it is either upstream-ready or especially advantageous for the project. Am I wrong?

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.

+1 It's not a matter of cost, we'll just never trust a third party for hosting our code.

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.

Does Gogs support webhook integrations (ie, someone pushed to this repo, notify our team on slack)?

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."

I'm sorry to hear that GitLab didn't seem to work with multiple requests. The way to resolve this is to configure multiple unicorn workers, please see https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc...

On GitLab.com we have 20+ unicorn workers that handle over 30k monthly active users.

Cool, thanks for reaching out! I'll look into this. Finding info about this problem was a chore, so I'm really appreciative you're able to point me somewhere =].

You're welcome, I tried to improve the documentation so that it is easier to find https://gitlab.com/gitlab-org/gitlab-ce/commit/9269606c94853...

"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."

... BitBucket!

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.

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.

> Also, since Google Code hosting project is closing down, you can expect more projects being driven to it.

Well, Google Code was never used for private repositories, so that argument is irrelevant for the intended free private repository introduction.

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?

I haven't used it before, but Gitlab does offer JIRA integration[1][2]

[1]: http://doc.gitlab.com/ee/integration/jira.html

[2]: http://doc.gitlab.com/ce/integration/external-issue-tracker....

Phabricator has really good issue tracking baked in and supports a workflow that is esssential Github style pull requests.

Why not just install a separate product that is dedicated to being a really good issue tracker?

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.

[1] http://en.wikipedia.org/wiki/IBM_Configuration_Management_Ve...

I have found Gitblit Go (http://gitblit.com) to be the easiest to setup and maintain (upgrading is just unzipping).

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).

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.

That's weird. I'd have thought that "difficult to manage/install/update" is a used-to-be problem now that docker's around..

I've used gogs because of it being mentioned here before however I'd love to see an analysis of the stability of these various git front ends.

Can anyone comment on the T&C on ownership of repo content on these Git hosts? I could not locate specific mention of that on Gitlab.

Gitlab's terms and conditions for their hosted service are here; they don't really address ownership: https://about.gitlab.com/terms/

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.)

Should've include Redmine in the list too

seems like with docker to install gitlab now the argument for ease of deployment doesn't matter as much anymore.

Thanks! And if you don't want to use Docker you can use the Omnibus packages of GitLab to install in 2 minutes.

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.

Anything to discourage a GitHub monoculture is a good thing, IMO.

Found an easier to use docker setup [1]. Took around 5 minutes after downloads to setup in a docker-machine vm on a mac. Quite nice little gui, just make sure you change localhost and port to the correct docker vm ip (or hostname if you're on a droplet or something)

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)

[1] https://github.com/codeskyblue/docker-gogs

GitLab is doing a good job here, but it's great to see there are many good alternatives in the git world.

Is this better than Phabricator?

http://phabricator.org/

Reply on news.ycombinator.com