GitHub

[Jeff Mitchell]

Magnus Bergmark wrote:
> I don't what you mean. Say I forked Amarok from amarok/amarok into my
> own, Mange/amarok, and then clone it to my computer, this is what I
> should do:
> 
>    1. Run "git remote add upstream git at github.com:amarok/amarok.git" so
>       I have the remote repo "upstream" defined
>    2. Commit changes to my repository as usual, and then
>          1. Push to my own github account ("origin") for sync between my
>             machines
>          2. Push to "upstream" when my changes are done and official

This assumes that you have push rights upstream.  If that is the case,
there's no point in having your own account in the first place, and you
might as well all just share one account.

This also doesn't take into account what happens when you have 15
developers, each with their own account, that do the same thing.  If
everyone wants to share branches and try each other's out, you need to
add everyone's remote refs and keep them updated, or push them all to
different branches "upstream".  Either way, you're better off having
everyone share one Github account, and if you are doing that, you lose
most of the perceived benefit of Github anyways.

> In newer versions of Git, the remote branches is automatically added as
> tracked branches now.

Which remote branches?  This doesn't happen (in current git) when you
add a remote ref.  You still have to decide which branches you want to
track and create local branches for them.

> If you need to create a /new/ remote branch,

This will be a common use-case.

> yes, the other developers will not get them automagically, but will have
> to add them themselves AFAIK. But as long as you have added upstream
> like above, it's as simple as "git checkout upstream/new-cool-feature"
> and bam!, it's there, checked out and tracked.

If you've added *everyone's* upstream, or if everyone pushes their
branches to the upstream account (in which case everyone would just be
using that account anyways).

> I think the PITA here comes from the fact that a lot of merging will
> have to be done in case J.Doe pushes to upstream and I have pushed
> changes to my origin AND I want a linear history when I merge to
> upstream myself.

Yes, that would be a PITA.

> We still get the good parts of github, which is
> that one-shot contributors can fork, commit, send pull requests and then
> get their patches in.

But that's not actually a good part, because you can do all of that from
normal git (except "send pull requests" which are easily simulated with
format-patch and email) and Github's two-way indirection makes things
more complicated.

Github "fork" makes you do a clone of a clone.  By the time you get it,
your branches track upstream, except upstream is now your github repo
and not actual upstream.  Of course, this means you still have a remote
location to store your data instead of just having it on your local
machine...and that's the real use for Github anyways (but doesn't really
elevate it above a normal git server), but it means it's actually more
complicated to do what a normal, simple "git clone" from a normal git
server would accomplish.

> GitHub even has a new web-UI for applying patches
> from other people into the repo, without even having to merge or
> anything, which can be mighty useful.

Why is it useful for Github to do the merge for you?

> GitHub is like any ordinary repo hosting server, anything you can do
> with your own bare-bones git hosting can be done on GitHub.

Not actually true.  But I'll let it slide.

> It's their
> UI around all features that make people chose them.

Yes, people are easily amused by AJAX and the word "social", regardless
of whether it actually means anything (and in Github, it doesn't...you
have Github usernames instead of email addresses, which doesn't make it
any more "social").  There isn't anything you can't do on a non Github
server (and some things you can't do on Github).  People choose them
because they don't want to bother setting up a server themselves (which
is a perfectly valid reason for many projects)...and for reasons like in
the article Mark gave, where someone is afraid they may abandon their
project and want to make it easy for someone to pick up without them
having to keep the repo up themselves (much easier to have someone else
host it then).

Please understand that I'm not totally down on Github...it has its
place, and works very well for some things, especially for small
personal projects.  But I've also had to do lots of dealing with what
happens when things go wrong with its model, which starts to break down
and make things harder when people are doing more than sending just a
patch or two, especially if they are not sharing an account.

If Amarok people want to use Github, that's fine; but I would very
strongly recommend that everyone then share an account for Amarok
development work.  It's also worth noting that Github is closed source,
so if people are uncomfortable with that, they should be looking at
Gitorious or some such thing.

--Jeff