GitHub

[Jeff Mitchell]

Ian Monroe wrote:
> On Wed, Jan 7, 2009 at 12:46 PM, Jeff Mitchell
> <kde-dev at emailgoeshere.com> wrote:
>> Ian Monroe wrote:
>>> No one in #amarok.dev knew that. :)
>> The fact that people didn't remember the URL, and didn't look it up in
>> the email or look in their git remotes doesn't make it a problem with
>> the server.
>>
>>> Everything I tried was password protected.
>> I don't know what you tried, but it's only password protected if you try
>> to push to it.  It's using Apache LIMIT directives in conjunction with
>> DAV, and GETs are not affected.
>>
>> Whatever you were doing must have been really funky.  I just tried it
>> out now and it worked perfectly fine for me.
>>
>>> So a contributor really can't push back into the central hub, so we'd
>>> be stuck all using the same account?
>> Yes.  When you clone your git repo that is a fork of the original,
>> you're doing an indirect cone, and you don't get the proper refs set up
>> so that you can push directly.  So you have to also have the main amarok
>> remotes/branches to push to, which makes having your own fork a moot
>> point anyways.  So if we were to use it, we'd all need to just use one
>> account (but it would keep us separate through email addresses).
>>
>> See the other parts of this thread for much more detail.
> 
> So if you're not working on a feature branch, why would you make your
> own fork? Its impossible to clone the original?

Because that's what Github tells you to do.  It's absolutely possible to
clone the original, but even for casual contributors Github encourages
you to "fork" it so that you can then use their Pull Request mechanism,
because that's their desired workflow (and it's their desired workflow
because the Pull Request mechanism is one of the unique things about
Github).  In my experience, this makes things more, not less,
complicated for the casual contributor wanting to just write a one-off
patch than simply cloning the original repository (instead of forking it
ahead of time), making the change, and sending an email.  It's one more
step, even if the send email/log on and send pull request are considered
of equal complexity, which they are.  But you can of course still clone
the original and format-patch it.

If you want to keep things up to date in your clone, you have to pull in
the original repo's branches anyways, and push all changes to your repo
(your "origin").  This is the way Funtoo works, where only one person
has commit access to the master repo, so everyone else needs to use
their own Github forks and then send pull requests.  Does it work?
Sure.  But it's much more complicated, especially if you then want the
various developers to pull branches from each other instead of always
syncing against the master repository...it can quickly become unmanageable.

So, the development model that Github encourages you to use is not
actually that useful for large projects with many developers...because
real projects don't work on a paradigm of forking.  They work on a
paradigm of synchronization of source code, and Github's indirect
clone-of-a-clone method breaks the built-in synchronization of git that
makes it very easy in the normal case of multiple users sharing a single
hosted repo.  However, if you use it more like a normal Git development
model (like Rails does, and like I'm proposing we do if we start using
Github instead of trying to encourage the KDE transition or rolling our
own) then it becomes a simple Git server with some easy management,
which is fine.

>>> It has a nice GUI to a standard git repo as far as I can tell.
>> It's not too different, functionally, from gitweb.
>>
> 
> What you just described sounds functionally very different from gitweb
> (which doesn't have any backend account handling at all of course).

Sorry, the display GUI part of Github is not that dissimilar to gitweb.
  Github obviously does a lot more.  Github is basically a collection of
scripts and such prepackaged for you, so it makes it easy to get set up.

--Jeff