GitHub

[Magnus Bergmark]

On Wed, Jan 7, 2009 at 4:28 PM, Jeff Mitchell <kde-dev at emailgoeshere.com>wrote:

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

Oh, I though you guys used a traditional centralized model with SVN. My bad.
Usually that is something that can be safely assumed with regards to
OpenSource and SVN. :-)


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

How would multiple repos be easier on a non-GitHub host? I'm pretty sure
that most people usually clone from the same repository in Gitorious and
get.or.cz, so to do the same on GitHub is a non-difference. We are both
agreeing that handling the case where people also have forks is harder.

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

I'm sorry.


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

Yes, that is correct. format-patch is obviously a better choice here. Still,
the UI on GitHub handles this even more easy IMHO, and one method does not
remove the possibility of using the other.


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


True. Taking user training into consideration is also important. Newbies may
forget to update their repository before sending the pull request and this
might introduce some overhead.

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

I heard that Git hosting over HTTP was something you didn't want (http < git
< ssh), but I'm ignorant about that.

They have a general post-recieve URL that they will POST to when someone
pushes changes to the repo there. Please see the guide for this at
http://github.com/guides/post-receive-hooks. True, it's more flexible with a
straight script entry box, but with a proper handler for this callback, it
will be about as powerful.

However, I will agree on this point, though. As long as you aren't using
Lighthouse, Basecamp, CIA, etc. it will be harder to use this feature since
you have to custom code this for their specific callback type, and also make
sure that the place this is POSTed to is accessible, which then could have
been the custom hosting anyway since hosting can happen over HTTP. It is
possible, but combersome.


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

Yeah, I know. :-)


>
> > "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 guess we can agree on disagreeing there.


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

Shouldn't be needed. You are backing up your claims.

I can say this: I think moving to GitHub is not in your interests anymore,
since you still need to sync with svn regurarly, and AFACT from the scm
mailing list, the plans to move KDE to Git is moving along. You should
probably just use the solution they will be using (which is self-hosted
Gitorious, if I recall correctly) when the time comes and you don't have to
sync to svn anymore.

-- 
Magnus Bergmark - magnus DOT bergmark AT gmail DOT com
GPG/PGP: 0x7BE84794DB6AA648
Fingerprint: 0E6F D2DB F0EF 534A 2184 52AF 7BE8 4794 DB6A A648
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20090107/168bbdd7/attachment-0001.htm