Committing like Crazy - GitHub | Hacker News Reader

Committing like Crazy - GitHub

github.com

85 pointsjackowayed13 comments

Github > Google Code > Sourceforge

On checking out/exporting:

I had to use Sourceforge a few weeks back: some project I needed the code to was hosted there. I'm not a stupid person, but it took me several minutes to figure out how to grab the source code to the project.

Google Code, in contrast, still makes you jump through a couple hoops.

With Github, it's a simple matter of clicking the little clipboard button (which I think should be bigger), switching over to my terminal, typing git clone and pasting. Easy, simple, fun. Just the way it should be.

On the social aspects of open source:

I have absolutely no idea who the people are that are involved with Sourceforge projects. I'm not sure why they're still using CVS. I'm not even sure I have CVS installed on my laptop (update: turns out I do. Snow Leopard ships with it. Who knew?). I have no desire to join a project.

Google Code is better. At least I can easily figure out how to post an angry comment to a project wiki. But who knows if a given project is still in active development without digging into the commit history? (Click Source, Click Changes. Oh great, the project's dead.) It's a pain to figure this out, especially when I eventually find a link buried somewhere informing me that the project maintainer has moved themselves over to Github.

Github tells me exactly what I want to know as soon as I get to a project page. When was the project last updated. Who's involved in it? How many people find it interesting? How many people find it interesting enough to fork it?

Sourceforge was relevant back when I could say the same about Slashdot. Google Code was fun for a year. I'm glad Github is as big as it is now. To reiterate another commenter, I really hope they never get acquired by Google.

You're calling clicking twice a pain?

If the project maintainer has moved to Github and doesn't post this prominently, it's hardly Google Code's fault, isn't it?

I am calling clicking twice a pain. There is a lot of useful information that Github surfaces on main project pages that Google Code and Sourceforge do not.

There's no reason why Google Code's very sparse right information column should not be supplemented with a 'last activity' row.

Nitpicking: Slashdot seems to have stood the test of time way better than sourceforge.

Some of these differences in numbers come from how git works in general.

A push is basically just uploading your repository to the remote server. As such a push might contain many commits by the person who pushes and others by different people - many of which are also part of other pushes.

Also due to the decentralized model of git and the model of pulling code from other people, it's highly likely that some (most?) of these pushes/commits never end up in the official repositories of the different projects.

Pushes may contain commits to throwaway branches, to branches for private use.

Also, the blog post doesn't say anything about rebases. If I push a rebased private branch, it will contain all the commits of the branch but with changed IDs.

There are so many more occasions for a commit to be moved around over the network in git than there is in the more centralized solutions as they are provided by Google Code and Sourceforge.

Yes. Google Code does provide Mercurial, but it's still project centric. So what gets committed to google code is official code that is part of that projects code base.

What gets commited to github is mostly throwaway stuff or patches about to be processed before being merged into some mainline.

This is where the difference comes from. It's just natural.

Github is a full-on game-changing company. They seem to be doing most everything right.

By charging developers money to host non-free projects, they've aligned their interests with developers: their customers. This means you get a no-bullshit interface which is exactly what I want from my project hosting.

I pray that google doesn't buy them.

From conversations I've had at their drink-ups, I get the sense they're pretty disinclined to sell the company, for reasons of personal freedom. Naturally, enough money will tend to push that sort of thing aside. I just don't think they're actively looking to get bought out, unlike some.

Part of this has to be a Git vs SVN. (I know that Google Code supports Mercurial, but I believe all project I'm subscribed to use SVN.) But I commit and push way more with Git than I did with SVN. Probably twice as often. I usually commit every time I write a function or even a loop. I usually push whenever I've fixed a case in the bug tracker.

With SVN, I used to only commit once I fixed a case.

Really? I do the opposite. You can't commit at all without hitting the server in SVN, where I can go for quite a while in Git without pushing. I would assume that most people would push in Git much less often then committing in SVN. It's obvious that because the commits are faster, they would commit more - and they are (109,000 Git commits over 33,154 pushes vs 17,000 svn commits). So in Git people commit on average 3 times before they contact the server.

Pushing to a public repository (especially forks of ones people actually care about, but this is true in general) gives me a small feeling of accomplishment. It's a way of sharing that I did something I think is useful, especially since it shows up in the news feed of my (handful of) followers.

So yeah, I probably push more often than is strictly necessary.

A lot of repos on GitHub are clones of popular projects hosted somewhere else. I doubt many people import svn repos on Google Code in a similar fashion.

I may just be stating the obvious, but I think this is because git is decentralised and SVN is not.

If you fork a git project, your clone is just another branching point in the DAG that represents the "universe" of commits across all repositories.

SVN on the other hand does not support branching naturally. It's as if the branching never happened, and there always were two separate repositories.

I think this is why SVN users often avoid branches. SVN can make them, but it does nothing to help developers merge their branches.

I think the easy interface of GitHub is because it was made to just work. No bullshit git functionality, which led to a fine product which everyone wants to use.

Reply on news.ycombinator.com