github source

[Mojca Miklavec]

On Sat, Apr 20, 2013 at 11:01 PM, Rainer Müller wrote:
>
> What kind of benefit do you expect from a mirror on github?

A very nice user interface to browse through history.

On Sun, Apr 21, 2013 at 6:25 AM, Ian Wadham wrote:
> On 21/04/2013, at 8:00 AM, Chris Jones wrote:
>> On 20 Apr 2013, at 9:50pm, Roger Pack wrote:
>>
>>> As a note, in case there's a poll or anything, here's my +1 for at
>>> least having a github mirror, if not moving to github entirely for
>>> trunk development.
>>
>> -1
>>
>> I just don't get git. Much prefer svn.

I support the idea of making a github mirror. It *doesn't* imply that
the whole development cycle should switch to git or that any developer
would have to use it. It's just a request for a mirror of an already
existing git repository on a hosting service with the most friendly
user interface.

I have no problem setting up a mirror on my personal github account,
but it would make a lot more sense if one creates a MacPorts project
and puts the repositories there (and that it would be updated together
with the official repository rather than by a cron job on an arbitrary
server). I volunteer for providing help for setting that up if needed.


> That said, I think MacPorts might be just as comfortable staying with
> SVN for as long as it is well-supported.  There is no point in changing
> unless there are significant advantages to the MacPorts project as a
> whole

+1. Git is a wonderful tool, but both SVN and GIT have their strengths
and weaknesses and SVN still makes sense in some cases.

I use git exclusively for working with my own port(s) in MacPorts
though since that's the easiest and most comfortable way to play with
some features and bugfixes, store them into a separate branch for a
longer time until they mature, and put them back into life when they
should be committed. That said, it currently wouldn't make much
difference for me to have all the MacPorts sources available as git.

> and it is a lot of work to port code from SVN to GIT and preserve
> all the history faithfully.

Given that git mirrors already exist:
    http://www.macosforge.org/post/git-mirrors/
it is a trivial task to create a mirror on github as well.

I agree that making sure that everything is 100% compliant (like
having proper .gitignore files instead of svn:ignore properties,
making sure that proper names and email addresses are used instead of
plain usernames, ...), that all the tools like trac system are
adapted, that all developers migrate, ... might be a lot of work, but
creating a simple read-only mirror is trivial, in particular when one
exists already, it's just a matter of doing another pull & push on any
server, optimally at the same one where
git://git.macports.org/macports/trunk.git is being updated already.

Mojca

(Off-topic: example of a bad experience from another project. One
submits a patch to a bug tracker. Nobody looks into it for months. By
the time someone stumbles upon the patch and would be ready to try it
out, it can no longer be applied since so much source code in the
project has been changed since. Developers are too lazy to do manual
patching and the only way to get the patch accepted is for the
submitter to get it up-to-date against the latest sources on regular
basis and hope that it will eventually be applied. While git cannot
solve bad project management per se, the need to resubmit patches
would basically vanish with git. In most cases git would do the right
thing with an old patch automatically.)