It doesn’t look so optional to me if I read the tearful reactions on social media correctly. Apparently, an overwhelming majority of Git users ‘can’t work’ when GitHub is down.
They’re probably not talking about using git, since git is decentralized by nature. You can use git without an Internet connection and then sync everything back up when you have an internet connection again.
Some people literally call GitHub, git and … they’re just wrong.
They also might be talking about review and project management facilities GitHub provides as a service.
There’s a difference between “can’t code” and “can’t work”.
A lot of people use git for version control: super good idea, basically anything else is at best unorthodox, at worst bizarrely stupid.
A lot of people also use github for repository hosting, continuous integration, code review, deployment, packaging, etc, etc. this is more of an opinion thing than a standard practice thing, and there are plenty of other ways to get the same tools, either all in one package or from a variety of different ones, self hosted, in the cloud, or some hybrid in between.
If GitHub goes down, you can make code changes and everything to your hearts content. But you might not be able to run your full integration testing pipeline on it, get a code review, or package your software.
If your local build process pulls packages from GitHub or refreshes a remote repository automatically, it can also powerfully mess that up, but that’s nothing to do with git. You can use “ctrl-c/v” backups and still have a build process that tips over when GitHub goes down.
Under which circumstances would using any VCS that isn’t Git be “bizarrely stupid” and why? I mean, everyone has strong opinions about something, but I’m curious now.
File1, file2, file_3.new, etc would be bizarrely stupid. A home rolled solution involving rsync, tar, gzip, crons or inotify would also be bizarrely stupid.
https://en.wikipedia.org/wiki/List_of_version-control_software anything on that list that’s marked anything other than “active” as a more serious answer. So like DCVS, visual source safe, or bitkeeper. Anything that’s not getting bug fixes or maintenance.
Anything that doesn’t have significant enough usage to give confidence that bugs or glitches are being caught by common usage would be risky, since you don’t want to be the person to find that edge case.
There’s things other than git that aren’t wrong, but I see little compelling reason not to use the most ubiquitous tool.
Ubiquity is not always the most relevant decision. (Especially as most VCS which aren’t Git :-) are easy enough to understand - most of them are even easier than Git in my opinion.)
It depends on the outer circumstances, I think. Using the prevalent tool makes sense in existing environments (which is one of the reasons why many companies use SVN - it worked for them before Git existed and it still works for them, so why not?). For new projects, one-man teams and/or companies starting from scratch, Git might not always be the best choice.
It’s relatively easy to self host your own git repositories.
It’s just that Github adds a lot of extra value added features that help streamline things for larger projects, and this is why many people use it. For most people, the value they get far outweighs the inconvenience when it goes down for 10 minutes here or there.
It doesn’t look so optional to me if I read the tearful reactions on social media correctly. Apparently, an overwhelming majority of Git users ‘can’t work’ when GitHub is down.
They’re probably not talking about using git, since git is decentralized by nature. You can use git without an Internet connection and then sync everything back up when you have an internet connection again.
Some people literally call GitHub, git and … they’re just wrong.
They also might be talking about review and project management facilities GitHub provides as a service.
Eh you still can, the git remote is a mirror but you can still make commits locally and sync later
Then what’s with all these devastated comments on social media?
There’s a difference between “can’t code” and “can’t work”.
A lot of people use git for version control: super good idea, basically anything else is at best unorthodox, at worst bizarrely stupid.
A lot of people also use github for repository hosting, continuous integration, code review, deployment, packaging, etc, etc. this is more of an opinion thing than a standard practice thing, and there are plenty of other ways to get the same tools, either all in one package or from a variety of different ones, self hosted, in the cloud, or some hybrid in between.
If GitHub goes down, you can make code changes and everything to your hearts content. But you might not be able to run your full integration testing pipeline on it, get a code review, or package your software.
If your local build process pulls packages from GitHub or refreshes a remote repository automatically, it can also powerfully mess that up, but that’s nothing to do with git. You can use “ctrl-c/v” backups and still have a build process that tips over when GitHub goes down.
Under which circumstances would using any VCS that isn’t Git be “bizarrely stupid” and why? I mean, everyone has strong opinions about something, but I’m curious now.
File1, file2, file_3.new, etc would be bizarrely stupid. A home rolled solution involving rsync, tar, gzip, crons or inotify would also be bizarrely stupid.
https://en.wikipedia.org/wiki/List_of_version-control_software anything on that list that’s marked anything other than “active” as a more serious answer. So like DCVS, visual source safe, or bitkeeper. Anything that’s not getting bug fixes or maintenance.
Anything that doesn’t have significant enough usage to give confidence that bugs or glitches are being caught by common usage would be risky, since you don’t want to be the person to find that edge case.
There’s things other than git that aren’t wrong, but I see little compelling reason not to use the most ubiquitous tool.
Ubiquity is not always the most relevant decision. (Especially as most VCS which aren’t Git :-) are easy enough to understand - most of them are even easier than Git in my opinion.)
Of course it’s not the only factor, but all things being equal, the most prevalent tool should be preferred.
It depends on the outer circumstances, I think. Using the prevalent tool makes sense in existing environments (which is one of the reasons why many companies use SVN - it worked for them before Git existed and it still works for them, so why not?). For new projects, one-man teams and/or companies starting from scratch, Git might not always be the best choice.
people like to make a fuss and get attention on social media, it’s something to talk about, entertainment
they’re weren’t even down for that long
You’re trolling at this point, right? You have a Boxxy profile picture and yet you’re confused about the dynamics of social media?
It’s relatively easy to self host your own git repositories.
It’s just that Github adds a lot of extra value added features that help streamline things for larger projects, and this is why many people use it. For most people, the value they get far outweighs the inconvenience when it goes down for 10 minutes here or there.
It’s still optional, they just chose poorly.
Here’s hope they’ll learn from this.