GitLab crawling back online after breaking its brain in two In a classic example of the genre, GitLab yesterday dented its performance by accidentally triggering a database failover. The resulting “split-brain problem” left the code-collection trying to serve its users out of a single database server, postgres-02, while it tries to sort out the remaining three. The problem first arose …
It is kind of an ironic coincidence for me because today I set up my first official GitHub repository, backed by Git obviously, and it was an amazing experience for me. Git is plain and simple a very impressive tool, for both its extensive capabilities as well as its outstanding documentation.
Just for contexts sake: I had a local project I'm working on which is used on several servers. Because of that the project isn't only kept in a local repository but also in a central one. So basically whenever I have an important change I 'git push' that onto the main repository and done. Then this can be 'git pull'ed' on another server so that they're automatically in sync with my copy. So far, so good.
I decided to upload and maintain this project on GitHub as well. As such I created the repository, copied the URL, set up a new (dedicated) branch in my local project, added my GitHub repository as a so called 'remote' and then assigned that as the new branch upstream.
As a direct result I now have 1 project which can be pushed onto multiple upstreams with ease. All I have to do is select ('checkout') the appropriate branch and run 'git push', couldn't be easier.
Can it get any better than this? Of course it can! GitHub also provides you with a nice wiki for your repository which you can use to document your work. And that wiki is basically a Git repository in itself. Which I then added as a submodule in the project I mentioned above. But only on the master branch which is maintained locally (pushed on a locally hosted repository), on my 'github' branch the entire .gitmodules file gets excluded as such there's no risk of my main project getting mixed up with my GitHub project.
So why am I sharing all this... First of all because GitHub / Git left me truly amazed at the things I could do there. But second because I cannot imagine doing all this just as easily solely based on GitLab. Judge for yourself: just compare the GitHub help with the GitLab help.
And last time I checked GitHub actually knows how to make and maintain backups ;)
Yes, if you don't look at how it is implemented, and don't enjoy the ugly task of setting up a complex VCS server yourself and don't use a premade one (which stores your code outside your control).
Despite its features, Git is a HUGE step BACKWARD in the ways server software is written. It's a pile of disparate tools cobbled together in some way to achieve something usable in a lazy effort - its implementation under Windows is laughable, and with a very high administrative overhead because it lacks a central and single way to manage it, you have to cope with the disparate tools and all their idiosyncrasies - and with a very scanty documentation, for example, if you need to put sound ACLs on repositories - not everybody does open source projects. Even using multiple repositories if frowned upon, because it is difficuuuuuuult. Heck, you can't even simply create a remote repository with a single command.
That's why you need layers like GitHub or GitLab to make it manageable somehow. Just one stores your code on its servers - and in many situations you can't simply do that-, the other brings in features you may have already covered with other tools ,just adding more useless complexity.
Just today everybody drinks the kool-aid some open source "guru" ask them to drink, without ever thinking what they're going to drink.
@AC Git is a HUGE step BACKWARD in the ways server software is written
Nope, git is not server software in the first place. If you try to use it as such, you will meet inevitable failure (unless your use case is so trivial it barely merits "server" word). That's why you need something like gitlab. It is not an omission, server part (except for the most trivial case) was not and is not in scope, by design. You are setting yourself for failure if you ever think otherwise.
You can't compare them at all. GitHub is a service. GitLab is an open-source server software with an official hosting option. Sure, that official hosting option does rather suck in terms of reliability and that's why I don't use it, personally, but I'm still a huge fan of GitLab as a software. House-of-ten-thousand-dodgy-dependency-cards (written in at least half a dozen different languages, too!) it may be, but, once it *is* up and running, GitLab is sublime.
And, frankly, on a shallow U.I. level, GitLab is way ahead in terms of usability. GitLab's Repository -> Graph page knocks the pants off any linear list of commit history with a combo-box for changing between branches and tags. If you're managing a team of developers, all collaborating on various branches in various repos. to create real products, being able to see a high-level, graphical overview of the graph straight in your browser is a hugely convenient tool. (If such a thing exists in GitHub, PLEASE let me know. I haven't been able to find it. Oh, and also how to see a list of the repositories I have starred but not contributed too without having to navigate to my own public profile page -- an obtuse route that requires at least three page transitions!)
Judge for yourself: just compare the GitHub help with the GitLab help.
Most of what you wrote is about git, not GitHub/GitLab, so is equally true of both. Both also have wikis, although I don't know how they compare.
It's not clear what your point is regarding the help. IMHO some parts of GitLab's help aren't great (to put it mildly), but I've suffered far worse.
GitLab a YC startup relies on YC M$ deal, their free-tier Azure Cloud. While GitLab SW stack is quite slow as hell on-premise, it doesn't scale well in the Azure cloud. GitLab blog is filled with adventures how instable and incomplete the Azure cloud stack is and both GitLab and Azure technical debt is responsible for the continues more down than up statistics.
Choose "Gogs", for an on-premise GitHub alternative - Gogs is open source, written in Go, and is very fast, and painless: https://github.com/gogits/gogs
Eh, the primary problem here is Postgres, presume you ignore that since its OSS and can do no wrong.
GitLab have long moved off Azure as they had a large IOPS requirement (200000) that didn't match what Azure could provide. They admit they didn't do the basic math before moving onto it so it was always going to fail.
Use the best cloud for your use cases if you can. If you have massive IOPS requirements the cloud might not be for you, writes will be slower as it has to be replicated across zones, reads will have limits as there are other people in your cloud as well.
The reason they have huge IOPS is Git, 300 reads for every 10 writes, its massively inefficient at scale. Again don't mention that since its OSS and can do no wrong.
MS have created a virtual layer to fix this problem for large repositories https://gvfs.io/
No your anecdotal story about your use case does not mean it applies to larger use cases, just because you can walk to the shops does not mean you can run a ultra marathon, unless its an Open Source marathon of course.
GitLab is an old skool architecture where they are just renting servers, that will bring its own pain.
I like Go its a nice language to work with. OOS is not bad, neither is proprietary, its whatever you need to get the job done.
Um, how can something be deployed if it isn't even set up ? Deploying does not just mean "copy to production server". It means configuring, testing that the config works in production, and activating in production.
I wonder whether the problem was as a result of these vulnerabilities being patched:
https://twitter.com/jobertabma/status/989708798515265539
Jobert Abma, 4:32 am - 27 Apr 2018
In December I found a number bugs in @gitlab, all of which were disclosed today. The team responded swiftly and professionally and is a pleasure to work with. I'll describe each vulnerability in a separate tweet in this thread. Enjoy them and happy hacking!
Everyone bashing GitLab and comparing it to Github are blind to the benefits of GitLab.
GitLab, while it offers a free online service, also provides software allowing you to run your own git repo on your own server. When GitLab's servers have problems, these independen GitLab installations are unaffected.
When GitLab went down last time, I spun up my own GitLab server, and it's been stable ever since. No data slurping, no charges, if it goes down it's on me. If it needs maintenance I can schedule a time for it to suit me.
Primary repositories are in house and we mirror some stuff out to gitlab.com for external use.
It's a great product, but the hosted service is definitely a bit flaky. We've seen performance problems before, in addition to the more widely publicised failures. Growing pains maybe. It's fine for what we do, but I'm not sure I'd trust the hosted service yet as our primary code repository.
At a previous employer, we ran an inhouse Github server. Worked pretty well. Things that we open sourced went on github.com, but the master was kept in house. Which also meant that if github ever went down, we were fine.
We weren't fine when rubygems.org went down, though. Oops.
I weep that people using GIT , who you would expect are programmers or at-least IT savvy, think it is a "server system"
Same reasoning I suspect that people think if it's in the cloud or 365 you don't need to waste money on backup storage, "because the providers have their own backups"
Or the people hiring IT staff in Hong Kong based on "tell us your current salary or we won't look at your CV"... nice......
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
