If *forge, as you say, had at least decent and responsive service with CVS and SVN then perhaps it might be worth it for some people. But it doesn't! It needs to die.
Except they can never allow you to do anything dynamic on the server or you'd be able to read the HttpOnly github session cookies of anyone logged into github.com itself.
Well, they could, but they'd have to move to www.github.com exclusively, wait for all those session cookies to expire or for folks to visit and get them reset...
GitHub cookies are restricted to github.com and gist.github.com domains (using a redirect trick to allow cross subdomain cookie sharing). You can use all the JavaScript you like on your Pages.
The .github.com cookie is old and useless. You can't use it to do anything - it's a relic of our old authentication system. We should have made sure they were deleted before switching to the new cookie as it's caused some confusion.
What mojombo said is accurate. (He's a GitHub co-founder and I'm the person who wrote the redirect code.)
A friend of mine is a web developer and he's got a shocking dynamic site that the server treats as entirely static. He accomplishes this with JSON callbacks.
(P.S. For a good time, click on the white background box or the "3N" logo when you're using are recent webkit nightly. Ian has a... ironic sense of humor.)
Like a lot of good ideas from Google (Documents springs to mind as well) it seems like the initial version had a lot of promise and then it was followed up with few revisions to bring needed features.
There may be some risk with allowing arbitrary-content (including Javascript) on subdomains of github.com. I tried a few trivial cookie/script/iframe tricks, and was not able to reach logged-in user info. However, my skills are far from the state-of-evil-art. Note that even Google put their page-hosting on a separate 2nd-level-domain, googlepages.com, rather than a subdomain of google.com.
Safari and IE (but not FF or Chrome) will display 'text/plain'-served-content as HTML. That means the GitHub 'raw' view of project content can be used to execute arbitrary user JS from github.com.
Such JS can get at a logged-in user's name and make (at the very least) superficial changes to profile information. A harmless demo (works on Safari and IE) is here:
The 'raw' issue seems more serious and isn't affected by whether Pages are on .github.com subdomains or not. Still, subdomains have a slight leg up on exploiting any security slip-ups and browser bugs that may occur.
Sorry, should have specified: Safari 3 on Windows. All my tests were on Windows, none on MacOS or Linux.
If it hadn't still been your 'topmost' comment, and a recent top story possibly still monitored by multiple GitHubbers -- or if I hadn't received an ack by this morning -- I would have tried an alternate means of report.
Or, if I thought this was a higher-risk issue. (Your general user-management already seems well-fortified by https against all but superficial mischief.)
Still, I understand the preference that a security bug however small be reported directly first, and I'll respect that in the future.
I really like this, but I think a lot of the examples so far aren't really taking advantage of what makes this different.
What makes Github different is that it's connected to your version control, so I don't see this being especially useful for things like personal websites, but it could be a great way to supplement the admin and analytics offered by Github already.
Yeah, this might make a nice tool for publishing any api docs (checkout a separate branch, generate, commit, and push your api docs), or code coverage reports, etc.
I don't know if it's really taken off, but a bug tracking tool like ditz could really benefit from this (it can generate an html report based on the bug "database" stored in your git repo).
I would be incredibly surprised if such a thing happened. Not because GitHub isn't awesome (it is), but because most non-programmers would look at you funny if you said "distributed version control". I mean, most people can barely use the Internet competently.
If would be neat if you could integrate the wiki into the site, with matching style (just a simple HTML layout for the wiki plus control of the CSS). If we could do that, I would consider moving a whole open source project's site to this.
It is a wiki, if you treat it like one. That's what's so cool about it.
Two years ago, we moved the Philadelphia LUG website (http://phillylinux.org/) from a set of static HTML pages to a subversion repository. I dropped in a post-commit hook to update the DocumentRoot after each checkin, and the site instantly became the best wiki I've ever used. Revision history is handled by diff, and svn blame. Updates are made with your favorite $EDITOR. And, as an added bonus, you get to use real HTML rather than some silly wiki markup language. I love it.
One of the most important parts of being a wiki is having a low barrier to entry. Revision control systems (git even more so than svn or cvs) is a huge barrier to entry.
