This is why I love git (and distributed version control systems in general). For the most part a short downtime isn't the end of the world. When it comes back up I'll push my changes and that'll be that.
While I actually agree with you, as I look at GitHub as "somewhat reasonable git hosting", that is not how many (if not even most) projects actually use the website, so it is an unfair analysis: people seriously often use (and even encourage others to use) GitHub as the only web presence for their project, using a Readme.md to build a landing page; meanwhile, for many people, GitHub is how they handle incoming bug reports and pull requests (as they believe, for right or for wrong, that it is easier to use GitHub to collaborate on these features than a more traditional mailing list).
You thereby can't just say "oh yeah, git is distributed, so I don't care if GitHub is offline"; it makes about as much sense as saying "I don't care that Gmail is offline, as email is distributed: I have all my messages locally in Outlook and can send mail through my ISP" while ignoring that other people now can't send you mail and you have lost access to your calendar entirely.
I spent the downtime trying to figure out how to use Jade without the documentation available -- the docs are in the readme.md on the Github repo. It was only later that I realized that the docs were also available through npm (https://npmjs.org/package/jade), but it was an interesting experience nonetheless.
You seem to have ignored what I said... this insistence that "people can still commit their code locally" is focussing on just one of the use cases for this website. To read jtchang's comment, it is as if that's the only service that GitHub provides.
In fact, "git hosting" is one of the least interesting services GitHub provides for the specific reason that, yes, git is so ludicrously decentralized: it seriously takes less time to push to your own git repository than it takes to log in to your GitHub account.
(Really, the only thing it makes simpler, with regards to actual git hosting, is managing user credentials for a centralized Subversion-like repository; however, if you actually think of git as a decentralized system you don't do that in the first place.)
I will thereby attempt to make this point even more clear by taking my example about Gmail (where you totally ignored the Calendar comment) and ratchet it even further: if all of Google went offline tomorrow, my ability to still send mail using Outlook is great, but it doesn't help me watch YouTube videos or, you know, search the web.
Likewise, when GitHub has an "outage across all services" that affects all kinds of things developers do that have nothing at all to do with "hosted git repository". To repeat one example: a lot of developers are crippled if they don't have access to an issue tracker to tell them what they need to work on next.
So, just because your workflow doesn't rely on anything GitHub provides, doesn't mean that isn't why most of the people who use GitHub aren't using it: GitHub is a popular set of services for project management that are all bundled together in a way that is easy for people to get started with, not just a git hosting company.
Exactly. To expand on this point, I love the redundancy built into Git.
I had a clone of my personal fork of my department's github repository at home. I read this and thought "that's interesting, I wonder if I could still work on it from home if I want to." I saw with "git config -l" that I had my github repository and my university's github repository, but not my university's mirror of the repository. I did a "git add remote", logged in to my university's VPN, "git fetch", and was up and running with my latest changes from Friday.
If that didn't make any sense, well, the gist of it is that the outage wouldn't affect development work in the slightest, thanks to the fact that every repository is a) content addressable, so you have consistency between servers and b) self-contained, so you have a complete copy everywhere. Hit me up for more info if you're curious; I recently upgraded us from CVS to Git for this redundancy advantage, among others.
One of the neat things about repos in Fossil (the DVCS by drh of SQLite fame) is that they have a built-in wiki and issue tracker whose contents are version controlled along with everything else in a project's repo. The Fossil executable also has a built-in web server that presents a web interface for working with the repo, including the issue tracker and wiki.
In short, if you have a project's Fossil repo, you can work on everything locally, then push source, wiki, and issue tracker changes to a central repo at your leisure.
how does fossil do versioning of the issue tracker? i tried using a setup like that for a while, with ditz as the issue tracker. it turned out to be really inconvenient to have my issues versioned along with my code as part of the same repo - i want to navigate around in my code's history and branch layout with the issue tracker conceptually being an entirely separate repo that always points to HEAD unless i explicitly go scroll back in it.
Fossil doesn't track issues along with source code, unlike some scripts for bug tracking on top of git. While Fossil stores tickets in the same repository with source code, with the same basic format, tickets are separate entities and are not connected to the source code itself.
What? That's the complete opposite of what OP was saying.
You don't need github to be online to work with your code or even your repositories so long as you haven't gone and thrown all your digital eggs in the same basket (i.e. as long as you have other remotes or at least local copies of your repositories).
I don't think so, because it's GitHub that's down and I think kmfrk would have mentioned it if his other service was coincidentally down at the same time. I think what kmfrk meant is that he can't operate without GitHub's issues. It isn't ideal but it's understandable.
I would point out that both TFS and Mercurial do the same thing (as does ClearCase, but ClearCase is awwwful), but with much less memory consumption on the local PC. Not trying to add snark (I upvoted the above comment), just adding that it's not a GitHub feature.
> I would point out that both TFS and Mercurial do the same thing (as does ClearCase, but ClearCase is awwwful), but with much less memory consumption on the local PC. Not trying to add snark (I upvoted the above comment), just adding that it's not a GitHub feature.
Well, no, obviously it's a feature of Distributed Version Control Systems in general.
In fact, that's probably why OP wrote "This is why I love git (and distributed version control systems in general)" and didn't in any way claim it was a feature of GitHub?
And do you have some kind of reference for git being less memory-efficient (are you talking RAM-wise?) vs Mercurial or TFS? On its face its pretty hard to believe; git is pretty light-weight.
Git for large projects is not lightweight, nor do they claim to be. In fact, that's the basis of their philosophy - that they store full versions of the files as opposed to just storing the changes because data storage is considered inexpensive. The only time Git uses pointers in when the files have not changed.
I'm certainly not slamming Git for working exactly the way it was intended.
I think you may be thinking of a different VCS such as SVN as Git actually just stores the meta data (changes/deltas) and not full versions of the file in each commit.
As an example when you clone a repository, it downloaded it, then in goes through a process of 'Resolving Deltas'. This is it going through the history applying the changes/deltas to the files so that they are up to the most recent revision.
The only files that are added in full are binary files.
To be fair, it uses the full blob until you pack, which is not immediately and depends on your settings. Large repositories spend a significant amount of effort determining optimum window pack sizes etc to optimise the packing of their history.
So, git can be quite heavy on disk usage, until all the loose objects are packed.
Pro-tip: when you want people to understand a comment you're making about the disk-consumption patterns of one piece of software vs another rather than memory-consumption, consider actually referring to it as "disk-consumption". Git is quite lightweight, if we're actually talking about memory.
Also, maybe don't confuse git with GitHub, as your original comment did.
Your comment looks just like snark to me since 1) the parent comment mentioned other distributed systems and 2) a random unreferenced jab at git for its allegedly bad memory consumption. I have no idea if it is true or not, but it is hardly relevant to the discussion.
Last time I used TFS it would take 5, literally 5 minutes to time out for checkouts. The way TFS acts I don't even feel it's accurate to call it a DVCS.
The only SCM I like less than TFS is SourceDepot. The bane of my existence. It's sad when I can rant about it abstractly and my father can sympathize.
Does TFS beat out ClearCase on the Worst SCM Hierarchy? I'm just curious; I had to use ClearCase a lot at a previous job, and hated it but I've never used TFS.
