[OSM-dev] I converted the rails port to Git

Ævar Arnfjörð Bjarmason avarab at gmail.com
Mon Feb 22 09:08:11 GMT 2010


On Mon, Feb 22, 2010 at 08:14, Frederik Ramm <frederik at remote.org> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>>
>> We discussed briefly on IRC where we would host our Git repositories
>> if we hypothetically converted all of the OpenStreetMap SVN to
>> it. Personally I think Github would be great for that, the alternative
>> of just setting up our own git ssh:// and gitweb really misses the
>> added benefit of the web-based forking, pull requests,
>> multi-repostiory tracking and the other collaborative aspects of git
>> which really shine through with Github.
>
> I have no experience with Github. Is it "clean" from a privacy / owning
> one's data viewpoint, i.e. doesn't try to sell stuff and annoy users (like
> Sourceforge does with endless "buy services for ..." ads), doesn't require
> committer's real names or e-mail addresses, and so on - or is it one of
> those sites with an evil business plan where sooner or later you'll be
> ashamed that you used them at all (as I have heard people say about
> Sourcefourge)?
>
> Because if there is any lingering doubt that Github might one day send
> targeted e-mails advertising the latest Ruby book to those who have checked
> in lots of Ruby code, or whatever, then I'd rather forgo these
> "collaborative aspects".

They have a non-evil business model: Selling access if you need large
or private repositories.

This is their privacy policy, it's written in Human:
http://help.github.com/privacy/

> (All this comes from someone with almost not Git exposure; if Git is built
> in a way that even if OSM uses Github people can easily and equally well
> contribute without registering at Github then the point is probably less
> important. But if everyone is told "why don't you register at Github then
> you can participate better" then Github really needs to be squeaky clean for
> that to happen.)

You'll always be able to contribute without registering with Github,
although of course if the master repository is hosted there and you
want to push directly to it you'll need an account there.

Github just makes things easier, especially if the people you're
working with use it too. Here's an example:

Earlier in this thread I mentioned that I back up my Github
repositories, but just after writing that E-Mail I found a bug in the
program I'm using to perform that backup.

So I do:

 1. Click "Fork"
 2. git clone git at github.com:avar/git-megapull.git
 3. Patch it, the commits are here:
http://github.com/avar/git-megapull/commits/master/
 4. Notify the author that I made the changes: http://i.imgur.com/K97zP.png

If the author doesn't respond in a timely fashion by applying the
patches other people that run into the same problem can see that the
bug is fixed in my branch and trivially merge from it or just use it
instead of his.

This process is much easier than making a change to a program in a
subversion repository you don't have access to. Then you have to fix
it locally, do svn diff & attach your patch (which won't have 4 commit
messages like the above) to an E-Mail / trac ticket. Someone who wants
to use your patch has to download it somewhere manually, may have
difficulties merging it etc.

Even if you do have commit access to the primary repository it's great
to be able to easily fork programs in this manner. I've fixed a few
issues with some programs in OpenStreetMap's repository but you always
feel like you're playing with somebody else's toys. Maybe they don't
like the changes you made and then you've just fouled up "their"
trunk.

It's much easier just to fix it locally, push it and tell them that
they can merge from you if they like the changes.

The biggest feature of Git or any distributed version control system
is that it brings things that were previously outside the repository
inside the repository, for instance getting multiple commit messages
and easy merging for things that were previously huge patches attached
in trac somewhere.




More information about the dev mailing list