
Committing like Crazy - GitHub - jackowayed
http://github.com/blog/620-committing-like-crazy
======
aaronbrethorst
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.

~~~
middus
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?

~~~
aaronbrethorst
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.

------
pilif
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.

------
po
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.

~~~
paulbaumgart
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.

------
pkaler
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.

~~~
schacon
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.

~~~
paulbaumgart
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.

------
alexkay
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.

~~~
chousuke
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.

------
rick_2047
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.

