6 ms·

A good warning sign for companies that only have their codebase at Github which seem more common to me nowdays. If you run your own server at least you can like

A good warning sign for companies that only have their codebase at Github which seem more common to me nowdays. If you run your own server at least you can like physicaly restrict the access to local network only.

reidrac 12y ago
I'm not sure if I understand what you're saying. They're using git, don't they? Obviously you miss the web interface to issues, pull requests, etc; but if you don't have git repositories distributed in your own infrastructure you're doing it wrong.
inglor 12y ago
Why though? The whole point of git is that it's distributed source control - you _always_ have a local copy of the source and the history. That's one of the biggest wins in using git and not a centralised source control in the first place..
- butwhy 12y ago
  But you don't necessarily have an up to date copy. If you had a local mirror, you could queue collective commits until the github server becomes available again.
  - hayd 12y ago
    You have your own local branches...
  - ademarre 12y ago
    > But you don't necessarily have an up to date copy. You would if you designed your build process that way. I think it's a good idea to eliminate all third party build-time dependencies. In practice this means keeping a Git clone of everything to use for official builds, or anything that can't risk a third-party being unavailable when you need it most.
    - inglor 12y ago
      Exactly! If you have a sane build process everything is always synchronized anyway.
  - mikeash 12y ago
    You could set one up in approximately no time at all using your local copies. I mean, having a proper local master backup is a great idea, but you could survive without it in a case like this. Just set up a new repository somewhere everyone can get to it and have everyone push to it.
- rodgerd 12y ago
  If people have their whole workflow in git kernel-dev style, sure. But the reality is that for a lot of people their workflow is github. Leaving them with raw git is equivalent to leaving them with nothing.
  - tommorris 12y ago
    Then perhaps we need to make workflows that don't rely on Github a lot easier. https://github.com/toolmantim/bananajour https://github.com/toolmantim/bananajour is pretty nifty. I've worked at places with enormous enterprisey SVN checkouts that might take an hour or two to slowly download off the internet even though the developer at the next desk may have the exact same bunch of bits available without having to go all the way out to the internet and back. Just solving that problem with better Git tooling could mean a better experience than the current re-centralised decentralised version control...
- jhildings 12y ago
  Well yes, but if you need to setup the codebase on another computer for example or are very used to use GitHub to do some "extra things" like browsing and follow commits, it will disrupt the workflow.
thejosh 12y ago
Or run something like https://toranproxy.com/ https://toranproxy.com/ if you use composer, and also mirror your code remotely.
onion2k 12y ago
First of all, physically restricting access to a local network pretty much makes the benefits of using Git redundant. Ignoring that though.. I don't think there are many companies who have the depth of info security knowledge that Github can draw upon. You might believe that running your own server and locking it down to your local network (as best your team can do that) is better, but I'd rather trust Github even if that means my code is available online. While the chance of being victim to a non-specific attack is far higher (Github is a much bigger target; I'm affected if they're attacked), the chance of someone targeting my code and actually getting it are far, far lower because Github is better at making things secure than I am, and they have people who are paid to make sure things stay that way. A policy of only having your code on Github has it's flaws but making sure it's secure isn't one of them.
- maaaats 12y ago
  > First of all, physically restricting access to a local network pretty much makes the benefits of using Git redundant. No, it doesn't. Why should it?
- flyinglizard 12y ago
  > I don't think there are many companies who have the depth of info security knowledge that Github can draw upon That's true and I believe in that as well. However, GitHub also poses a much larger attack surface than any single company and it's safe to assume that once someone is in, they're going to get _everything_. Apart of that, you're also vulnerable to having GitHub disgruntled employees accessing your data, and the inherent vulnerability in having a remotely accessible repo in the first place.
  - ddorian43 12y ago
    I think google protected your data from employees. Can't github do the same ?
    - flyinglizard 12y ago
      It makes sense that Google protects your data from most employees, but there's always a core of employees that have everything accessible. It's probably a small operational core in Google (still probably way bigger than the entire headcount of Github).
oelmekki 12y ago
And what when your own server hosting repos is down ? The problem is not having a third-party host, it's having no redundancy. We use this, in our capistrano tasks : set :repository, ( ENV[ 'FALLBACK' ] ? fallback_url : github_url ) If github is down, we just push on that secondary repos (which is indeed on one of our servers) and just process business as usual.
- simon_vetter 12y ago
  If the reason you're using github is its tools and (nice) interface, why not start your deploy by syncing github to your private repo, then have capistrano always pull from there? Less code paths to test and no need to define env[FALLBACK]. Also, it's probably faster.
  - mitchty 12y ago
    A simpler way is just define two remotes to push and pull from in a single namespace say origin. If one is up you'll have no real problem. No need for code paths to test or having fallback stuff either. Just make git use both remotes. Linus uses git that way. http://marc.info/?l=git&m=116231242118202&w=2 http://marc.info/?l=git&m=116231242118202&w=2
    - oelmekki 12y ago
      Nice, I didn't know one could have multiple urls for the same remote. This post does not specify what happen on a `git fetch all`. I suppose it takes the first one, and you have to specify other remote entries if you want to pinpoint the remote repos to use ? Note that the deploy I mention will do a fetch, so this solution does not replace the fallback variable.
      - mitchty 12y ago
        No idea on git fetch all, but for a normal fetch it just iterates if the first one say fails it goes to number 2 in the list etc.. Past that I've not used it that often outside of having a cheap cluster solution in a way. Try it out and let me know!
lmm 12y ago
Internal servers might theoretically be under your control, but in practice your sysadmin team probably isn't better than Github's and you're not going to have 100% uptime. If you're spending time and effort doing stuff in-house, be sure you're getting real value and not just the feeling of being in charge.
- semi-extrinsic 12y ago
  No, but even if your sysadmin team is crap and you have a 95% uptime, that's a 95% chance that your solution will be a backup on the fairly rare occasions that github is down. Unless you have some reason to have your downtime correlated with github downtime.
  - lmm 12y ago
    If you just want a failover option, github + bitbucket is quite possibly more reliable and/or cheaper than github + internal.
    - emn13 12y ago
      That's possible, but since internet connectivity isn't 100% reliable, it's quite likely that bitbucket and github are effectively down at the same time.
- batou 12y ago
  No. Our internal source control server is more reliable than our local shared ethernet with cable backup combined with the reliability of github. We've had 43 minutes (scheduled and unscheduled combined) downtime in the last 11 years across three VCS technologies hosting internally. If it was github and remote, we're talking about 7 days of downtime in the last 2 years alone. We're definitely in charge and it has consumed virtually no admin effort in that time. The VCS server currently has an uptime of 3 years, 5 days, 20 hours and 38 minutes. It's also shifting 10mbit peaking at 200mbits pretty much all day every day 24/7/365. (CentOS 6, SVN, HP DL380 for ref)
  - 12y ago
emodendroket 12y ago
I don't know. If you're a really small shop the odds are frankly higher that poor administration will lead to your internal servers going down than that your (or Github's, really) server is down because of an attack by a state actor or someone with similar resources.
darkarmani 12y ago
If only git was a decentralized rcs, you could have both.
maxhodges 12y ago
because GitHub's uptime of 99.9912% isn't good enough for you? Even during this attack we were able to push and pull to our projects off and on. https://status.github.com/graphs/past_month https://status.github.com/graphs/past_month

reidrac 12y ago

I'm not sure if I understand what you're saying. They're using git, don't they? Obviously you miss the web interface to issues, pull requests, etc; but if you don't have git repositories distributed in your own infrastructure you're doing it wrong.

inglor 12y ago

Why though? The whole point of git is that it's distributed source control - you _always_ have a local copy of the source and the history. That's one of the biggest wins in using git and not a centralised source control in the first place..

butwhy 12y ago
But you don't necessarily have an up to date copy. If you had a local mirror, you could queue collective commits until the github server becomes available again.
- hayd 12y ago
  You have your own local branches...
- ademarre 12y ago
  > But you don't necessarily have an up to date copy. You would if you designed your build process that way. I think it's a good idea to eliminate all third party build-time dependencies. In practice this means keeping a Git clone of everything to use for official builds, or anything that can't risk a third-party being unavailable when you need it most.
  - inglor 12y ago
    Exactly! If you have a sane build process everything is always synchronized anyway.
- mikeash 12y ago
  You could set one up in approximately no time at all using your local copies. I mean, having a proper local master backup is a great idea, but you could survive without it in a case like this. Just set up a new repository somewhere everyone can get to it and have everyone push to it.
rodgerd 12y ago
If people have their whole workflow in git kernel-dev style, sure. But the reality is that for a lot of people their workflow is github. Leaving them with raw git is equivalent to leaving them with nothing.
- tommorris 12y ago
  Then perhaps we need to make workflows that don't rely on Github a lot easier. https://github.com/toolmantim/bananajour https://github.com/toolmantim/bananajour is pretty nifty. I've worked at places with enormous enterprisey SVN checkouts that might take an hour or two to slowly download off the internet even though the developer at the next desk may have the exact same bunch of bits available without having to go all the way out to the internet and back. Just solving that problem with better Git tooling could mean a better experience than the current re-centralised decentralised version control...
jhildings 12y ago
Well yes, but if you need to setup the codebase on another computer for example or are very used to use GitHub to do some "extra things" like browsing and follow commits, it will disrupt the workflow.

thejosh 12y ago

Or run something like https://toranproxy.com/ https://toranproxy.com/ if you use composer, and also mirror your code remotely.

onion2k 12y ago

First of all, physically restricting access to a local network pretty much makes the benefits of using Git redundant. Ignoring that though.. I don't think there are many companies who have the depth of info security knowledge that Github can draw upon. You might believe that running your own server and locking it down to your local network (as best your team can do that) is better, but I'd rather trust Github even if that means my code is available online. While the chance of being victim to a non-specific attack is far higher (Github is a much bigger target; I'm affected if they're attacked), the chance of someone targeting my code and actually getting it are far, far lower because Github is better at making things secure than I am, and they have people who are paid to make sure things stay that way. A policy of only having your code on Github has it's flaws but making sure it's secure isn't one of them.

maaaats 12y ago
> First of all, physically restricting access to a local network pretty much makes the benefits of using Git redundant. No, it doesn't. Why should it?
flyinglizard 12y ago
> I don't think there are many companies who have the depth of info security knowledge that Github can draw upon That's true and I believe in that as well. However, GitHub also poses a much larger attack surface than any single company and it's safe to assume that once someone is in, they're going to get _everything_. Apart of that, you're also vulnerable to having GitHub disgruntled employees accessing your data, and the inherent vulnerability in having a remotely accessible repo in the first place.
- ddorian43 12y ago
  I think google protected your data from employees. Can't github do the same ?
  - flyinglizard 12y ago
    It makes sense that Google protects your data from most employees, but there's always a core of employees that have everything accessible. It's probably a small operational core in Google (still probably way bigger than the entire headcount of Github).

oelmekki 12y ago

And what when your own server hosting repos is down ? The problem is not having a third-party host, it's having no redundancy. We use this, in our capistrano tasks : set :repository, ( ENV[ 'FALLBACK' ] ? fallback_url : github_url ) If github is down, we just push on that secondary repos (which is indeed on one of our servers) and just process business as usual.

simon_vetter 12y ago
If the reason you're using github is its tools and (nice) interface, why not start your deploy by syncing github to your private repo, then have capistrano always pull from there? Less code paths to test and no need to define env[FALLBACK]. Also, it's probably faster.
- mitchty 12y ago
  A simpler way is just define two remotes to push and pull from in a single namespace say origin. If one is up you'll have no real problem. No need for code paths to test or having fallback stuff either. Just make git use both remotes. Linus uses git that way. http://marc.info/?l=git&m=116231242118202&w=2 http://marc.info/?l=git&m=116231242118202&w=2
  - oelmekki 12y ago
    Nice, I didn't know one could have multiple urls for the same remote. This post does not specify what happen on a `git fetch all`. I suppose it takes the first one, and you have to specify other remote entries if you want to pinpoint the remote repos to use ? Note that the deploy I mention will do a fetch, so this solution does not replace the fallback variable.
    - mitchty 12y ago
      No idea on git fetch all, but for a normal fetch it just iterates if the first one say fails it goes to number 2 in the list etc.. Past that I've not used it that often outside of having a cheap cluster solution in a way. Try it out and let me know!

lmm 12y ago

Internal servers might theoretically be under your control, but in practice your sysadmin team probably isn't better than Github's and you're not going to have 100% uptime. If you're spending time and effort doing stuff in-house, be sure you're getting real value and not just the feeling of being in charge.

semi-extrinsic 12y ago
No, but even if your sysadmin team is crap and you have a 95% uptime, that's a 95% chance that your solution will be a backup on the fairly rare occasions that github is down. Unless you have some reason to have your downtime correlated with github downtime.
- lmm 12y ago
  If you just want a failover option, github + bitbucket is quite possibly more reliable and/or cheaper than github + internal.
  - emn13 12y ago
    That's possible, but since internet connectivity isn't 100% reliable, it's quite likely that bitbucket and github are effectively down at the same time.
batou 12y ago
No. Our internal source control server is more reliable than our local shared ethernet with cable backup combined with the reliability of github. We've had 43 minutes (scheduled and unscheduled combined) downtime in the last 11 years across three VCS technologies hosting internally. If it was github and remote, we're talking about 7 days of downtime in the last 2 years alone. We're definitely in charge and it has consumed virtually no admin effort in that time. The VCS server currently has an uptime of 3 years, 5 days, 20 hours and 38 minutes. It's also shifting 10mbit peaking at 200mbits pretty much all day every day 24/7/365. (CentOS 6, SVN, HP DL380 for ref)
- 12y ago

emodendroket 12y ago

I don't know. If you're a really small shop the odds are frankly higher that poor administration will lead to your internal servers going down than that your (or Github's, really) server is down because of an attack by a state actor or someone with similar resources.

darkarmani 12y ago

If only git was a decentralized rcs, you could have both.

maxhodges 12y ago

because GitHub's uptime of 99.9912% isn't good enough for you? Even during this attack we were able to push and pull to our projects off and on. https://status.github.com/graphs/past_month https://status.github.com/graphs/past_month