GitHub

[Jeff Mitchell]

Magnus Bergmark wrote:
> That depends on the model of development. With a centralized repo,
> almost every developer should have push access to it, yes. However,
> one-shot contributors shouldn't get push access to the repo, but should
> instead send in patches or pull requests (in case of GitHub).

Yes, obviously.  I was speaking in terms of our current development model.

> I still doesn't understand what you are trying to say here. All branches
> in the public repo is visible in your local clone.

That's because you're thinking of the rails repo, whereas my example is
the "normal" github method, where everyone has their own account and
forks off the main repo.  If you look at it in that context it will
probably make sense, and it's why the everyone-shares-one-account model
is the only usable way for any decent sized project on Github.

<snip, snip, snip, because you keep repeating what I had already said>

>     Why is it useful for Github to do the merge for you?
> 
> 
> Well, it's useful if you get a long list of small commits. Now, this may
> not happen here, but in many projects, people can contribute with small
> commits like spelling fixes and it would be easy if you didn't have to
> fetch your repo, add the other fork as a remote, fetch the remote, get
> the specific commit, cherry-pick it into your own repo, push it and then
> remove the remote repo. 

Umm...or you can just have people send it in with format-patch.  No need
to overly complicate things for a spelling fix.  In fact, the above
method is overly complicated for users as well as developers.  Much
easier to simply have them clone the public repo, make their change, and
use format-patch to send in the change.

This gets even more complicated for users later.  For a fresh fork of
Amarok they just took there wouldn't be a problem...they could just
assume that they are up-to-date, make their change, push to their repo,
and send a pull request.

If they keep their fork of the repo, it will get out of date.  So
instead of a simple git pull, they have to git pull from the remote ref,
merge into their "upstream" branch, push that up to their account, then
send the pull request.

It's not that difficult, but it is more complicated.

>     > 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.
> 
> 
> Could you please elaborate. Let's say you create a repo and then just
> forget about the web site. What will be different from your SSH access
> to a repo on server X and the SSH access to the repo on GitHub's server?

You can't do HTTP, for instance.  And from what I've heard you can't
integrate it with Trac or Jira, but that's just hearsay.  Github also
has a bunch of ways to do CIA-like things, or send commit notifications
to email addresses or IMs, but you lose the flexibility you get when you
can control all of the hooks yourselves.

> Yes, people are easily amused by visualizations and the word
> "collection", regardless
> of whether it actually means anything (and in Amarok, it doesn't...you
> have collections instead of file hierarcies).

No, collections are nothing like file hierarchies.  And I don't think
people are easily amused by the word "collection".  Bad example.

> "social" makes it just a bit easier to make small time contributions.

Yes, and here's where I disagree.  I think it makes it just a bit harder
to make small time contributions.

> I do, and I hope you understand that I'm not 100% for GitHub either. I'm
> that kind of person that believes in using the best tool for the job. I
> will change my stance in a heartbeat if I could see a valid reason
> GitHub is not adequate. I'm also aware that I'm not part of the project
> yet, so I have nothing to say in the matter. I'm not trying to decide
> for anyone, just make sure that people get the facts straight. :-)

Please feel free to point out to me (in a private email) where my facts
have been incorrect.

--Jeff