Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gogs – Go Git Service

gogs.io

Post reply on HN
Print view View original

71–80 of 186 posts

Re: Gogs – Go Git Service

#71

Post by raimue »

robmccoll wrote: post #64
raimue wrote: post #47

Earlier quoted context omitted.

"Make sure you run Foo 1.7, Bar 2.1, Baz 2.3, ..." "Make sure you update to OpenSSL 1.2e and restart all services." If you think of more than one program using the same module, shared libraries make a lot of sense.

You do run into false dependencies causing needless headaches with dynamic libraries though. There's a vulnerability in hash X in OpenSSL. One (or worse zero) of my 15 installed applications that depend on OpenSSL actually uses hash X, but in order to upgrade, I have to carefully manage those 15 dependencies. With statically linked dependencies, the hash X code wouldn't be in any of the other binaries and I only upda…

What do you mean by managing dependencies? You upgrade to an OpenSSL version that fixes hash X and be done with it? I don't understand your point.

Re: Gogs – Go Git Service

#72

Post by mh-cx »

sytse wrote: post #22
matheweis wrote: post #21

I switched to gogs from GitLab and haven't looked back. The installation literally took 10 minutes including all of the sysadmin work. Main reason was the resource utilization of GitLab was just too high. iirc, it was actually the CEO of GitLab that recommended the switch... ;)

Yes, if you are resource constrained (less than 2GB of memory) and using it privately I think Gogs is a great choice.

Sorry, but even with 2GB Gitlab is painfully slow. And it also happens on gitlab.com where I assume resources are optimized. Loading times of up to 3 seconds for a stupid list of issues are not really acceptable for a web application in 2016. In fact, they never were.

Re: Gogs – Go Git Service

#73

Post by raimue »

chm wrote: post #62
raimue wrote: post #47

Earlier quoted context omitted.

"Make sure you run Foo 1.7, Bar 2.1, Baz 2.3, ..." "Make sure you update to OpenSSL 1.2e and restart all services." If you think of more than one program using the same module, shared libraries make a lot of sense.

They do, but static linking means the developer actually does have control of the environment. What happens if you ship the latest and greatest binary but the shared libraries aren't updated by the user?

That is why libraries guarantee API/ABI compatibility within a version number (SONAME). The package manager of your distribution will be responsible for updating the required dependencies if needed.

Of course, if the user chooses to install software outside of the package manager, it is their responsibility to upgrade dependencies accordingly.

Re: Gogs – Go Git Service

#74

Post by wsh91 »

merpnderp wrote: post #48
wsh91 wrote: post #24

Earlier quoted context omitted.

What issue did you have with Bitbucket, if you don't mind my asking? :)

When viewing merge history, we got a generic modal error. I opened a bug with Atlassian, but we never got it resolved. Their first response wasn't the solution and I had limited time/energy to devote on debugging it.

That's entirely understandable--and thank you so much for raising it with us. I'd be curious to know what the issue ID is; my JIRA-fu is failing for what you specified. That said, again, thanks for giving us a shot. :)

Re: Gogs – Go Git Service

#75

Post by kakwa_ »

forrestthewoods wrote: post #42
Mahn wrote: post #27

> How to use downloads? > 1. Extract the archive. > 2. cd into the directory just created. > 3. Execute ./gogs web and you’re done. Can't beat the simplicity of running Go applications. It's funny because running a compiled binary is so incredibly basic to computing, and yet 90% of the time installing a new shiny toy in a server involves dealing with 342525 dependencies, half of which broke because god knows what dep…

Yes. Digging up dependencies is the worst. Managing another fucking build tool is the worst. To be honest, anything short of clicking a thing is the worst. Because there's no reason it can't be as simple as clicking a thing. I've always believed that 100% of all dependencies should be included in projects. Whether that is raw source code, amalgamated source code, static libs, or dynamic libs I don't care. Give to me…

As itself, bundling dependencies is not necessary a bad thing, but it often leads to really bad practices.

Once you bundle dependencies, you make the choice of having to track those dependencies for security fixes and bug fixes. Otherwise you end up exposing bugs and security issues to your users.

Too often, I've seen applications (specially in the "Enterprise" Java World) with hard pinned versions from 2, 3, 4 and even more years old, with tons of bugs and tons of security issues.

Bundling make sense in many cases, for example if you distribute a product, it permits to control most of the stack and to factor maintenance across several platforms.

Not bundling also make sense, for example if you are a distribution, you have tight control over what put in, and it reduces the effort to maintain stuff because you don't have to track x, y, z each in versions n, m, o.

Bundling or not is a trade-off, either way, it must be done properly.

Dependency handling is a complex task, and yeah, it sucks. And it's not technically that the problem will be solved, it's with proper organization, conventions and normalization.

Re: Gogs – Go Git Service

#76

Post by sytse »

mh-cx wrote: post #69
Udo wrote: post #7

I've been using Gogs now for a few months and can't recommend it enough as opposed to GitLab. It does have some rough edges (for example the many instances where its CSRF protection feature misfires), but generally it's a very solid and performant git frontend. Although a plugin or widget system would be nice, it was also easy to extend the Gogs UI simply by editing its very straight-forward template files.

Same here. Gitlab is soooo extremely slow. Even on their own site many pages take several seconds to load. And no one really seems to care. Gogs is a great relief.

GitLab.com is slow because of operational issues, like everything running from one NFS server. GitLab on your own server with enough memory should be fast. The slowness of GitLab.com is unacceptable to us, work to improve it is ongoing in https://gitlab.com/gitlab-com/operations/issues/42

Re: Gogs – Go Git Service

#77

Post by endymi0n »

toolz wrote: post #70
ddon wrote: post #63

Earlier quoted context omitted.

Would be nice to have a list of features which Gogs offers and GitLab is missing! We are happy using GitLab...

I would guess the only feature gogs has over gitlab is low resources and easy install, which for someone like me who does solo side-projects and likes to commit to my home server, is enough reason.

That's what has been the deciding part for us in the end. While Gogs is super lightweight, Gitlab is so feature rich, stable and user focused, that it's the only piece of Ruby that's running in our stack. We were right in the decision phase for a CI and had already set up a Jenkins machine when Gitlab integrated their CI which has been super simple, reliable and well integrated so far, no comparison to the monster that Jenkins is. Recent work on performance has been stellar, setup was quick, including backups, and upgrades have been super painless, they really got the important parts nailed down. Can totally recommend it, and it's really got the traction to both catch up with Github and also offer unique features. The pull/merge request workflow isn't as refined and better code review support would be high on my wishlist, but overall it has been a great choice so far with little regrets.

Re: Gogs – Go Git Service

#78

Post by sytse »

mh-cx wrote: post #72
sytse wrote: post #22

Earlier quoted context omitted.

Yes, if you are resource constrained (less than 2GB of memory) and using it privately I think Gogs is a great choice.

Sorry, but even with 2GB Gitlab is painfully slow. And it also happens on gitlab.com where I assume resources are optimized. Loading times of up to 3 seconds for a stupid list of issues are not really acceptable for a web application in 2016. In fact, they never were.

GitLab.com is slow because of operational issues, like everything running from one NFS server. GitLab on your own server with enough memory should be fast. The slowness of GitLab.com is unacceptable to us, work to improve it is ongoing in https://gitlab.com/gitlab-com/operations/issues/42

Re: Gogs – Go Git Service

#80

Post by merpnderp »

sytse wrote: post #57
merpnderp wrote: post #50

Earlier quoted context omitted.

I tried installing the omnibus and from source. Both times I could not get it completely working. On CentOS 5.3 x64. I eventually got everything but git commits working over ssh, but I quit trying to get that working after it looked like I had to give up port 22. I was just installing installing for evaluation and hopefully our sys admins will do the final install. Gogs was just 'install Go', 'run binary', 'link to d…

I'm sorry to hear you had problems installing GitLab. Maybe it was an SE Linux problem? https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc... You can configure an alternative ssh port for the Omnibus packages in https://gitlab.com/gitlab-org/gitlab-ce/blob/30e4d3ce9a18340... If you encourter problems again please email support@gitlab.com and include a link to this comment.

I think I remember that most of my issues were SE Linux related. We liked Gitlab and are going with it, I just personally found Gogs a lot easier and simpler to get going and the missing features weren't that important to us. Thanks for the helpful links.
Post reply on HN