Hacker Newsnew | comments | show | ask | jobs | submitlogin
Github turns five (github.com)
360 points by trustfundbaby 688 days ago | comments



Congrats on 5 years to Github! They are true pioneers for creating a social network for programmers, and not limiting it to just experienced programmers. I barely knew how to program but I was suggested to try Github with the little HTML/CSS/JS I knew and it is been my favorite, not to mention most effective, way to practice to become a better programmer. Collaborating with fellow hackers on projects is more fun than I ever imagined. They have actually found a way to make programming a social and fun experience! The beauty of Github is that it attends to programmers of all experience levels, so I really don't see myself straying away from it even as I become a better programmer. Here's to hopefully more than another 5 years!

As an afterword, I guess the big question is: What comes after this? What will make Github irrelevant?

-----


GitHub rocks. I would only switch for the yet to be invented GitGrub. If you'll request is accepted, you get a free burrito.

-----


GrubHub! My favorite Hub. GitHub is second. Though if they partnered...

-----


"What will make Github irrelevant?"

A stable github?

Edit - this was somewhat flippant, and they do a great job, but when it breaks it can stop me from doing what I need to do next.

-----


It can stop you, but odds are it doesn't in many cases. IMO this is one of the biggest benefits of git over something like Subversion or CVS: its distributed, so you can continue to work locally while the origin is unreachable.

I can't tell you how many times in my svn past where I couldn't get any work done simply as a result of the repo sever going down or having some other issue affecting its reachability.

At least with git I may not be able to pull commits from origin, but I can still commit locally which is typically enough to keep me productive during outage periods.

-----


It's certainly better than a similarly stable SVN server, there's no question about that.

However, when it's down, I can't push my changes for others to review, or review pull requests. I can't update and pull in the latest changes, or checkout branches to help someone with a bug. If it's an integral part of your workflow, it can be quite a pain when it's down.

"I can't tell you how many times in my svn past where I couldn't get any work done simply as a result of the repo sever going down or having some other issue affecting its reachability."

I had the opposite experience, although an SVN outage would have been worse, I'm used to them being far rarer.

-----


", I can't push my changes for others to review, or review pull requests. I can't update and pull in the latest changes, or checkout branches to help someone with a bug"

You can do all of these things if your colleague has that branch checked out - it does require remembering some pretty poorly-named CLI flags though!

-----


Maybe, I work remotely, most other people will be in the office. Pulling something from someone on the internal network might be... interesting.

It is another benefit of git, and one of the reasons I first moved to it (often did work on a robotic system, pulling an pushing new branches was a really nice way of moving code back and forth without committing to a central repo).

Git is great, and github is brilliant. I just wish it was more stable, because I would say that is a real issue at the moment.

-----


Github is probably one of the biggest innovations in web since Google. Sourceforge was okay, but it felt clunky and inaccessible, not to mention it lacked really any kind of social aspect. Github brought source control to the mainstream and made open source cool again and made it felt like an actual social thing as opposed to single developers making commits without context to a repository.

If it weren't for Github I probably would never have open sourced the amount of work that I have done since its inception nor contributed to the amount of projects I've committed too.

-----


> Github is probably one of the biggest innovations in web since Google.

I love GitHub as much as the next guy, but 99% of Internet users neither know what git is, nor have any need of it. There are a little more than a million users. (EDIT: well no, there are now 3 million.[2])

By contrast, Google is used by over a billion people every month.[1]

[1]: http://www.statista.com/topics/1001/google/chart/899/unique-...

[2]: http://en.wikipedia.org/wiki/GitHub

-----


Doesn't matter that 99% of people don't know what it is because 99% of people are using software built with it.

-----


[citation needed] - highly doubtful.

-----


As far as the "99% of users are using software built with git" claim goes, it's not that far fetched depending on your notion of "using". ~32% of servers run Linux (http://en.wikipedia.org/wiki/Usage_share_of_operating_system...), which of course was built with git, so if you are an Internet user at all it is extremely likely that you are using software built with git.

-----


But not GitHUB. The site itself is not on par with Google in terms of influence, and neither does it's services influence nearly all Internet users.

-----


I didn't mean in terms of numbers. Of course more people use Google, but lets not underestimate the impact Github has had and will continue to have. If you're a developer, Github has essentially become a requirement to have, it's a developers resume. If it weren't for Github the numerous open source contributions I've made as well as projects I've open sourced myself wouldn't have come to fruition, and while my contributions are small in the greater scheme of things, you never know, one commit might make all the difference between a good web application and a great web application.

-----


> it's a developers resume

I keep hearing this on places like HN, yet when I've been applying to software jobs in the real world lately, there's been barely a mention of it.

-----


Perhaps only part of the resume. As a programmer, seeing real code, quality of commits, and working example projects made a big impression on me when recruiting intern-level developers. Also can see engagement with OSS, if applicable. Would be curious what sort of companies (size, location, focus, developer-to-other ratio) you're applying to and who they're seeking. Thanks!

-----


A few months back, I was applying for developer positions in northern California. Most of my professional experience is in .net, but I applied for all kinds of work, including a rails position. I'm not sure what the average dev/total ratio was for all those, but it's roughly 1/3 where I ended up, with a total size of less than 50. Github was never mentioned during any of my interviews, except occasionally by me to say that I have an account. (though I haven't done much with it) No one seemed particularly interested.

-----


I've had my Github account on my resume for a while now, and the last time I had an interview, they literally pulled it up while I was there and made some comments about it. It didn't seem like a huge factor in their decision, though.

-----


That's because most big, established corporations aren't using it.

-----


Innovations in infrastructure are usually unknown to most of the people using that infrastructure--until they fail. Think of what would happen if Github was down for a week: how many users would now have the name "Github" on their lips (probably with a negative connotation) after some web service they do use said "sorry, the fix on that showstopper bug has been delayed a bit; Github is down, you see."

-----


The very fact that git is distributed means that if github was down for a week your development shouldn't suffer, just become more annoying maybe, but you can easily so without GitHub I'd you know the ABC of how git works.

Your theory doesn't hold when comparing github with infrastructure everybody uses but few people know about, just because its used by many people that write programs that are used by many other users doesn't mean it's an infrastructure like an Internet backbone.

-----


> your development shouldn't suffer, just become more annoying maybe

Right, that's why I wrote "has been delayed a bit", not "has been delayed indefinitely." If you run a distributed OSS project, where your main point of contact with your collaborators is through Github--and your workflow relies on using Github's collaboration features (its wiki and issue tracking, its pull requests, etc.) then Github going down can greatly impede (though not halt) that workflow. (In fact, I might say that if your workflow doesn't rely on the collaboration features, you're not really "using" Github--you're just using git, and syncing with Github, like any project which has a Subversion repo with a Github mirror.)

A more major problem with Github going down, though, would be needing to pull an update from a third-party library to fix a bug, when that library's canonical repo is stored on Github. (A problem with any centralzied repo host, really.) If you have any git:// URL dependencies in your Gemfile, or you use Bower at all, you might have a problem deploying your updates...

-----


If fixing a bug in your product depends on GitHub being up, you're doing something wrong.

-----


BTW, 99% of all Github projects use it as centralized VCS.

-----


Somehow you don't even need to know what Git is to browse and download things from Github.

-----


Not to sound too elitist, but github is used by the people who make things, important things. How much has the existence of github contributed to the success of major projects hosted there, such as rails, bootstrap, jquery, node, coffeescript, etc?

-----


Looking at the number of pull requests for any given project I guess is a very good indicator. Looking at the number of closed jQuery pull requests yields a pretty high number: https://github.com/jquery/jquery/pulls?direction=desc&pa... — there's no doubt in my mind that putting Bootstrap on Github is the reason it succeeded as well (look at the number of pull requests, forks and issues raised. Looking at Rails you can see there have been thousands of successfully merged pull requests: https://github.com/rails/rails/pulls?direction=desc&page... — would that number of bugs and features have been addressed if it weren't on Github? I could go on with lists of more high activity repositories, but I think it's more than obvious Github has been a blessing to a lot of open source projects and undoubtedly helped them become more successful and stable (how much is a somewhat subjective and un-measurable thing).

-----


Also look at the other side of the equation, acquisition and installation. How many OSS projects have "git clone <git-hub-repo>" as the first step of their install instructions these days?

-----


I'd say since Stack Overflow, in terms of how it made life better for developers.

-----


Sourceforge was a lot less clunky and inaccessible 10 years ago. In '04/'05 they did a big site redesign that basically killed it. That's part of why github took off, a lot of people were waiting for the next old sourceforge.

-----


You clearly remember a different Sourceforge than I do as it was always clunky and inaccessible.

-----


I don't remember Sourceforge ever being anything but clunky and inaccessible, even back then. To be fair, I wasn't much of a programmer at that time, either.

-----


Without Github, contributing to OSS would have been much harder for me (being a noncoder). Thank you for giving us a tool with tremendous leverage in many aspects, both technical and nontechnical.

-----


In which ways do you contribute to OSS on github without being a coder? Through issues?

-----


From his website, "In my spare time, I contribute to the open source Fluentd Project's documentation." In fact, you probably don't even need to understand Git, since pretty much everything can be done via the browser now. Clicking on the "Edit" button on README/documentation pages automatically forks the repo and makes it trivial to submit patches.

-----


Yup :) I'm involved with the docs.

While it's true that everything can be done in the browser, "saving = committing" there so I prefer to use the terminal and emacs.

-----


Probably the biggest contribution a non-coder could do is bug-triaging, which means: Look into newly reported issues and try to reproduce them and check for duplicate issues.

In the best case, you can simply reproduce it. Then say so in a comment to the issue. However more probable, you have to ask the reporter for more details or try different versions and environments.

-----


I've been meaning to do this with Firefox but haven't been able to get around to it :(

-----


Github mainly succeeded because of the various shortcomings in Gits command line interface. Github made certain models of cooperative development incredibly easy, and since most or almost all of the open source development is just that the time was 100% ripe for something like github.

Still, it is an incredible achievement and I hope that github will be around for a very long time to come.

For a laugh:

http://svnhub.com/

-----


Git's quirks were surely a catalyst, especially helping the company to build momentum as Git grew. But Github added a lot more value than just that. I mean SourceForge was basically from the CVS + SVN era, and those tools were simpler and more intuitive, but SourceForge still served a great need.

I'd say GitHub mainly succeeded because it put code first and overall focused on a great experience for developers to contribute and collaborate. SourceForge, in contrast, was heavily influenced by consumers wanting to download the latest version of FileZilla or some Linux games.

And Google Code, for the brief time it was the main event, took things too far the other direction from SF. It was just too terse and the design too raw, as was customary for Google back then. It actually had the basis for a lot of the critical functionality, but lacked the kind of design flair GitHub has shown. I don't think it was ever seen as a potential profit center, so always seemed starved of the resources to compete with GitHub.

-----


Github succeeded because they have build a fantastic platform, order of magnitude smoother, better looking, easier to use and faster than any of the similar projects. Try to navigate http://sourceforge.net/ or http://code.google.com/intl/pl/ for a while to get a feel of how free VC hosting looked like before Github - nobody approached the problem with a normal (in the industry) professional product design approach, it was just developers throwing things together, those are almost showcases for how bad developers can be at user experience design when left by themselves.

-----


Actually, read the history of how github got started, they started exactly the way you describe: a hack put together by developers that needed that and built it as a side project without thinking about releasing it as a product.

-----


Github would probably not have succeeded had git's command line interface been better? What rubbish. Github is a fantastic achievement. As aashaykumar92 says, making programming social and with a website that almost looks like it might be fun to normal people?? That's some achievement!

-----


> Github would probably not have succeeded had git's command line interface been better? What rubbish.

Indeed. Except that it's your words, not mine.

I wrote: "Github mainly succeeded because of the various shortcomings in Gits command line interface."

The message, which apparently needs to be spelled out is that using a repo through a command line is a hard thing to do for many developers nowadays who think the command line is something for people with long beards. By putting a friendly face - and a web based face no less - on a really nice open source distributed repository tool github did exactly that which you need to do to gain mass adoption:

Make something people need easy to use and do it in a way they can afford. Then iterate like crazy to dig out a defensible moat around the basic core.

Github blew the doors of the competition including some corporate heavyweights by capitalizing on Git and the trend of collaboration in software development. If they had had to develop git from scratch, if git would have come with a web based front end or if an established competitor (say sourceforge) would have adopted git earlier or (when git was still just for open source nerds and SVN, mercurial or some other repo system used more for corporate) they would have had a much harder time of it.

History happened the way it did for a reason and git being very powerful but somewhat harder to use gave github an opening that they used to create a spectacular success.

Opportunities arise all the time, how you make use of them is what matters and without git as it was there would be no github today.

But why would I rephrase what the git guys said so eloquently on their first homepage:

"git repository hosting no longer a pain in the ass"

And:

"GitHub is the easiest (and prettiest) way to participate in that collaboration: fork projects, send pull requests, monitor development, all with ease. "

http://web.archive.org/web/20080514210148/http://github.com/

-----


I stand by my comment. I see no clear difference in meaning between your wording and my rewording.

> "Github mainly succeeded because of the various shortcomings in Gits command line interface."

The success of github has nothing to do with shortcomings in git's CLI. As you say, for some people, the command line is for beards. So for them any CLI is a non-starter; nothing to do with shortcomings with git's CLI. The power available to a command line user of git is one of the reasons github is such a good thing.

-----


Marc Hedlund: "One of my favorite business model suggestions for [web] entrepreneurs is to find an old UNIX command that hasn't yet been implemented on the web, and fix that." (2007)

http://www.codinghorror.com/blog/2007/04/when-in-doubt-make-...

-----


Github has been a great boon to the D programming language community https://github.com/d-programming-language . There's been a very obvious 'before' and 'after' we moved to github.

-----


Was the improvement from increased visibility for the project or from changes in the development process using GitHub?

-----


Both. What also improved enormously was participation by people who previously thought it too clumsy to. Github brought an organized, easy method of contributing. It was like night and day.

Switching to github was probably the best organizational decision we made.

From a business standpoint, I've also found that github's severs are fast and reliable, and the turnaround for tech support questions is fast and accurate.

I'm very impressed with github.

-----


I LOVE github, their little project forever changed the way I think about & write software, and their ideas (blogposts/presentations) about how to build software are truly a massive inspiration for me.

PS: Would be awesome to see who has the oldest github account on here. I joined April 20 2008.

-----


January 11, 2008. User id 4[1] :D

[1]: https://api.github.com/users/wycats

-----


Incidentally, this id is why we call wycats the "gate to enlightenment" -- it's proof that he's the "Mu" programmer.

A monk once asked, does JavaScript have a Buddha-nature or not?

Wycats said, "nil".

The monk said, "Above to all the Haskells, below to all the crawling Javas, all have Buddha-nature. Why is it that JavaScript has not?"

Wycats said, "Because it has the nature of karmic delusions."

(http://blog.bigbinary.com/2008/06/23/why-the-id-of-nil-is-4-...)

-----


And the winner is ....!!!

-----


NilClass.

-----


I joined on 2008-10-06 and by then it was already id 27786.

https://api.github.com/users/steveklabnik

-----


See here for the list of early accounts: https://api.github.com/users

-----


http://caius.github.io/github_id/

Doesn't show join date, but user IDs are auto-incrementing.

-----


January 29, 2008. User id 95. :)

-----


95? Wow. I joined almost a month later (Feb 23, 2008) and got #714.

-----


There must have been a rush right around that time - I joined Feb 17 and got #332.

-----


May 19th 2008 - #10793. That's quite some spurt.

-----


Ooh.. 118 here ;-) I bet 99% of the first 1000 are Rubyists!

-----


I'm number 1000: https://api.github.com/users/aslakhellesoy

I was a rubyist at the time :-)

-----


Feb 11, 2008, #184 https://api.github.com/users/paul

-----


A contribution to https://github.com/defunkt/mofo got me #71 on January 27, 2008 (https://api.github.com/users/uggedal).

-----


February 18th, 2008 (#365)

https://api.github.com/users/pius

Those were the good old days. Hanging out in #merb, just starting to get my feet wet with contributing to open source. Really great memories.

-----


Mar 05, 2008

-----


Sep 30, 2009 :(

-----


April 10, 2008, but Jeremy has me beat (as do several others, I'm sure)

-----


It's just been five years? It feels like I have been reading about it forever. Never got to use it because of limited private repos.

-----


Say what you want about Git, GitHub is awesome.

-----


Say what you want about GitHub, Git is awesome. (Not sure why we're comparing them but I'll throw in my opposing opinion. I actually like both but Git itself is much more important to me than GitHub.)

-----


Honest question: If it's not for GitHub's community features that get enabled through git's decentralized repository, what does git do for you more than a local SVN server?

-----


I used to use SVN. We built control software for robots. We'd take the robots away on a field trial - no internet access - fix some bugs, write some code, add some features.

That's five to ten people, all writing code that interacts with each other's, all without any access to the SVN server. You can imagine the copy-pasta that went on. The amount of "oh fuck, I just rebuilt-all without Dave's changes". The amount of "Bags not merging this shit."

Then we'd get back to work after a weekend and have to merge all our independent branches. That could take a day or two on its own. Sometimes, sitting with five people's laptops in front of you and using the human brain's visual diff was more efficient than trying to do it properly.

---

Now, with git, we push and pull wherever the hell we like as needed. Everyone's laptop is equivalent to the server. When we get back, everyone merges their stuff into staging, all the cross-dependencies get magically resolved, we test it, and merge that into master. It takes about fifteen minutes.

(Actually, I don't work there any more, but the conclusion works better in the present tense.)

-----


Thanks, that's an interesting example. Yes, I can absolutely see that for truly collaborative projects where multiple programming tasks over the same code portions run in parallel, git becomes a real time saver. I just haven't run into such a project yet myself.

-----


The fact that Git can be used without a server is a big benefit. Being able to do "git init" in any directory and start versioning files is pretty nice.

And Git handles branching and merging better than Subversion.

-----


Honest response: If you're coming from a Subversion background (like I did) then wrapping your head around the possibilities of git takes a long time. You almost have to unlearn everything you knew about version control.

If you're not frequently using local branches, your stash, `git add --patch`, git bisect or git rebase then you're really missing out.

Everyone's git workflow is different which makes it even harder to get up to speed since you read about 10 ways to accomplish the same task.

You might not use ALL the features of git but once you master a subset of them you'll find that your workflow is unlike anything you could have done with Subversion.

-----


Wrapping your head around git takes a long time regardless of your background, because git's interface is incoherent and requires you to understand internal details of its implementation to a degree I haven't seen in a commonly used dev tool since the '80s.

-----


I don't think this is really true.

Sure, you have to learn the (absurdly simple) model that git uses behind the scenes, but after you do that, who really cares about the standard CLI interface? That interface sucks in the same way a dashboard might suck on an all-terrian vehicle. Sure it looks like shit, all the knobs are in the wrong place and don't turn in consistent ways, and that analog clock seems really out of place in a car... but who really cares? It doesn't impede actual use.

Those "internal details of its implementation" are in fact what git actually is. "Learning git" without learning that stuff is not in fact learning git.

-----


I agree with you, basically, but that is the substance of my complaint. Git leaves all of its messy internal bits exposed and does not provide a clean abstraction layer in its interface. Many people have written such abstraction layers, but they tend to be incomplete, and none of them is a standard. Everyone who wants to use git - which includes everyone who wants to merely collaborate with other people who use git - therefore has to learn git's internal implementation details.

It's one thing to learn the internal implementation details when you are a power user who really cares about a particular tool and wants to master it: it's another thing to require everyone to gain low-level familiarity.

The whole point of a computer - indeed, the whole point of computing, if you look at it through a lambda-calculus lens - is to provide abstractions over lower-level details, thereby allowing human brains to spend less time worrying about those details and more time manipulating higher-level abstract concepts.

In failing to offer a high-level interface, git wastes human brainpower which could otherwise be spent solving actual problems.

You don't need to know what an AST or a symbol table or an intermediate representation are to use gcc; you don't need to understand static single-assignment form, linker relocation entries, or ELF segments. You can use the tool without any knowledge of its internal mechanisms. This is not true of Git, and that is why I hope it can be improved or replaced with something that has more respect for human brain power.

-----


I found learning git to be very similar to learning vim.

Nothing felt intuitive. The interface for vim might in fact be unintuitive and that might make learning it take longer.

But once you learn it, the un-intuitiveness is no longer a barrier.

I don't argue that learning git is difficult no matter what your background is. But that's the nature of a tool that's almost 100% un-opinionated on how you do something.

I don't disagree with your comment but I think that's inevitable for this type of tool.

-----


I don't see how an unintuitive CLI is 'inevitable' or 'in the nature' of such a tool.

How is it inevitable to have inconsistant flags for showing contextual help?

How is it in the nature of such a tool to have command names that are inconsistant (for example 'push' to not be the opposite of 'pull')?

I think in the end these things are relatively small oversights by Torvalds at the beginning, that have become rather difficult to fix now, after git has become such a standard tool - but it makes live really hard for every beginner. I mean imagine a GUI application where the help menu is sometimes accessed through F1, sometimes it's shift-F3. Imagine Edit->Copy would do something completely different than what people are used to form other similar programs. Even worse, in a GUI tool it's no big deal to fix those problems in version 2, but a CLI automatically becomes an API for other higher level tools such as GitHub and changing it would break it afterwards - so it's really important to get that interface right from the start.

-----


I've never found the inconsistencies in the API the major learning hurdle for git. If that's the case then it's really too bad since, as you mentioned, it could have been avoided.

For me the hurdle was not the API. That's what documentation is for. It makes learning it inefficient to always check the docs but that's about all.

-----


> what does git do for you more than a local SVN server?

It does less than a local SVN server, there is no server.

Git is peer-to-peer, which is a huge advantage. Because it is decentralized you can access your whole repo and its history while off-line. That and easy branching are the main selling points of Git though over time you discover more and more ways in which Git is subtly superior.

If I could start over again on my main repo I'd do it in Git but I already have all my files dating back a long time in an svn repository so the cost of transiting is huge. (it is a very large repository). But anything new is stored in Git. Maybe one day I'll work up the courage to do a proper transition.

-----


git-svn does it perfectly. We use it to track OSS projects that use SVN (we use git internally). So far, it has proven to be very reliable.

-----


I prefer git because it stays out of your way. No more .svn garbage littering every folder. No more "mother may I?" before deleting or moving files. And no more URLs when branching and merging.

-----


the spectacular ease of creating and merging branches is a huge one.

-----


For one, decentralized version control.

-----


I haven't heard too many people say bad things about Git.

-----


Git's technology is awesome, but are you happy with its CLI?

-----


The CLI for Git could use a lot of design help.

-----


Git is like linux in... 1996 maybe. The underlying technology is pretty awesome, but it leaves a lot to be desired in terms of usability. Git is enormously powerful, but it has some key weak spots that can lead to intense frustration, and it doesn't exactly guide users into using it in the best way possible.

-----


Mercurial is like a git designed for humans. Basically the same design (distributed, branching and merging is very easy) but with slightly higher-level command line options that removes some of the rough edges. I kind of wish it had won over git.

-----


The obvious counter is that Git is like a dvcs designed for maintainers and only incidentally for developers. I started out using bzr and eventually switched to git, partly to try out github, and things like rewriting history have become a major part of my workflow (I'm picking that one because it seems to surprise people coming from other vcs systems how easy it is to rewrite history in git).

I'm sure mercurial is nice, and given its users passion for it I might recommend it to people starting version control for the first time (I'm in academia, version control is surprisingly rare), BUT... I'd use the term "very sharp edges" and not "rough edges." My impression is that they're meant to be there.

-----


Mercurial is awesome. I never use GitHub, except when I want to download a zip of some code to review. Mercurial I use on any project not in TFS.

I've tried to revisit GitHub many times, but I just don't get it - it's not as good as Mercurial or TFS, and I have no desire to 'follow' anyone or watch a project. I'm just too damn busy building apps and projects to pay any attention to anything I'm not actively working on.

I'm still waiting for the 'ah ha' moment on why so many people are talking up GitHub, but it hasn't happened yet.

-----


I'm to young to know about linux in 1996, but linux in 2013 also seems to fit what you describe.

-----


Imagine a time when during the install you needed to know all the details about your hardware intimately. For example by making a wrong choice during the install you could destroy your monitor.

User groups had install parties so users would have a positive experience with Linux and not give up.

-----


Imagine linux back in an age before it was possible to search the web for answers to problems you run into. In an age when some of the most popular linux distros not only didn't have advanced install-on-demand internet based package management (e.g. debian) but may not have had any package management at all. Also in an age when plug-and-play was still more a theory than a reality and when hardware support in linux was a cruel joke.

Add to that a dizzying array of competing distros and hardware so slow it usually took hours to do a kernel compile. It was a frustrating time for computing in general and deciding to try using linux was a fairly daring venture certain to result in hours upon hours of frustration.

-----


Oh, memories of installing Slackware Linux from floppies....

-----


...installing TeX, waiting 24 hours for your 16MB 486 to generate all the Metafonts...

-----


I can't believe I forgot about floppies and monitor hsync frequencies. Those were dark times.

-----


Does that mean that the decision to pull with merge vs rebase will be decided as quickly as 'vim vs emacs' or 'gnome vs KDE'? :)

-----


Git and GitHub have both made monstrous contributions to the software development landscape. I've acquired incredible new powers, for free!

What other power-tools are on the horizon? What's next?

-----


Wow, I had no idea Github had 158 employees. I guess I mostly hear about their engineering team here on HN, and didn't realize the rest of the team was that big. Congrats on 5 years guys, it's a great service!

-----


Github is the reason I have an awesome internship this summer. Thanks :)

-----


What I really love about GitHub is that it's one of the really exciting companies that has never really disappointed nor sold out like Twitter did.

I'm as excited about GitHub as ever.

-----


> What I really love about GitHub is that it's one of the really exciting companies that has never really disappointed nor sold out like Twitter did.

To be completely fair to Twitter, it's been less than a year since Github raised their first round of funding ($100MM). Twitter has raised $1.6 billion over the last seven years.

It's a lot easier not to sell out when your investors aren't pressuring you to pull a profit yet. (Also remember that almost all of Github's funding comes from a single investor).

I like Github, but it's a bit premature to say that they've "never sold out".

-----


That just means that GitHub were much quicker to find a profitable business model than Twitter, though. :)

-----


Happy birthday Github! You are rocking opensource.

It's just amazing so easily be able to fix some software, to make some commitments into project you do love!

But, 6 million repositories for 3.5 million users? Really? How many bots do you have? I'm not sure, that general user has 1.7 repository. I thought the number is higher, at least 3 or something. How many repositories do you have with forks?

-----


I joined on April 12 2008 [1], I wonder what's my user id :)

[1] https://github.com/igorgue

-----


It's in the early 7000's.

-----


It is 7014.

-----


Amazing work github! Now get those sticker packs back in the store so I can buy a few and stick them everywhere :P

-----


Yay!

BTW, I live in SF and I REALLY want one of those octo-nyan-cat stickers for my laptop. Just sayin...

-----


Hard to imagine a world without GitHub now, it's become that pervasive. Great service, great people there. Hopefully we'll be saying happy birthday in another 5 years with even more people using it for open source projects.

-----


GitHub really become the standard for open source projects in such a short space of time, even the big name projects felt compelled to switch. Congrats GitHub.

-----


Happy Birthday, GitHub! I use it every day to collaborate with fellow hackers that don't live anywhere close to me. It's indispensable for me. Here's to 5 more years!

-----


How did you learn Github?

-----


For me, it was this: http://try.github.com/

I've been on the verge wanting to learn Git and GitHub for a long time, but that was what pushed me over the edge.

-----


Looks great. Thanks for the link!

-----


Happy Birthday. Project is awesome and so are the people.

-----


the same birthday for Meteor(http://meteor.com/)

-----


It’s also my Github birthday, as I joined on April 11th, 2011!

-----


Hub Hub Hurrray Gitters!

-----


Moderators edit titles all the time but now it’s been 7 hours and no one still has corrected "Github" to "GitHub"?

-----




Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: