[ruby-core:25443] Re: [Feature #2033] Move Core Development to Git

2009/9/6 mathew <[e-mail]>:
> On Sat, Sep 5, 2009 at 16:43, Rick DeNatale <[e-mail]> wro=
te:
>> =C2=A0 =C2=A0Many ruby projects formerly on rubyforge or other self host=
ed svn
>> repositories are now cloned on github, and in lots of cases the way it
>> appears to me that's where they are actively maintained.
>> =C2=A0 Rubyforge has provided git as an alternative to svn for some time
>> now. =C2=A0In the case of my RiCal gem, I have got github and Rubyforge
>> repositories containing it.
>
> Well, my RubyForge project was cloned on github against my wishes, and
> it's not exactly fair to cite git's popularity on RubyForge when the
> only other option they offer is SVN.
>
> On Sat, Sep 5, 2009 at 15:54, Ron Mayer
> <[e-mail]>=C2=A0wrote:
>> Who uses bzr? =C2=A0According to Wikipedia, Gnome's java
>> bindings (while Gnome itself uses git), Squid, MySQL,
>> and Mailman.
>
> And Ubuntu, and OpenSolaris, so I kinda think it could handle the Ruby so=
urces.
>
> Git is currently popular because Linus created it, and because it's
> being pushed on everyone by git zealots, who will literally fork a
> project onto git against the wishes of its owner because they refuse
> to use any other tool. This general assholishness of git zealots is
> also visible in things like=C2=A0http://svnhub.com/
>
> But this shouldn't be a popularity contest. It should be a matter of
> evaluating which systems meet requirements best. There are serious
> technical and working practice reasons to dislike git--the magic pull
> and automatic merge and commit, possibility of partial commits and
> limbo files, poor documentation, loss of metadata and history if you
> rename a file, visible SHA-1 hashes as revision names, and so on.
>
> Ultimately, I decided to get over my dislike of Python and use bzr
> because it works well on every platform, allows me to work the way I
> want rather than forcing a particular model, lets me change my mind
> about workflow and hosting easily at any time, requires no special
> hosting and makes it trivial to publish a branch anywhere, uses the
> containers my OS already supports, has no major UI pitfalls I could
> find, and is fast enough. Yes, git is faster, but bzr is now faster
> than git was, and I don't care if a commit takes 10 seconds; yes, git
> uses less disk space, but disk space is cheap.
>
> That said, I'm also willing to use svn, mercurial or monotone. I don't
> do religion; I don't believe in One True VCS, One True Text Editor, or
> even One True Programming Language (sorry Matz).
>
> I think Scott James Remnant
> <URL:http://www.netsplit.com/2009/02/17/git-sucks-2/> is right on the
> money when he says:
>
> "My personal opinion about this is that Arch (and now GIT) is the
> first distributed revision control system that people try, and then
> they get it. =C2=A0They understand why distributed revision control is so
> awesome, and they attribute this awesomeness to Arch (and now GIT)
> rather than realising that it=E2=80=99s an inherent property of any such
> system. =C2=A0The learning curve is pretty damned steep, so there=E2=80=
=99s a lot
> of investment to learn Arch (and now GIT) and once people have made an
> investment in something, and received an epiphany as an award, they
> become very attached to it and very aggressive about attacks on it."
>

It's true that git could use some polishing. It's not that hard to
walk the tree and assign a monotonic revision numbers to each commit
(as long as you have a sane single-rooted repo).
The major disadvantage is that git is not really a high-level tool so
you can (and must) see some of the low-level state of git even if you
do not really want to, even for usual workflows. I can imagine this
could be hidden with additional tools but these do not come with the
standard distribution.

However, git has some advantages over other tools. First it comes with
the distributed awesomeness, of the distributed VCSs it is one of the
more well known, it can switch between branches in one repo (which is
not only space efficient but also better supports some workflows that
would be harder if this was not possible) and it can intelligently
call a pager like less when the output of a command requires it (which
is still not possible with mercurial afaik).

I think that git (or any half-decent distributed VCS) really makes the
life easier for contributors because
 - rebase feature allows keeping small patches up to date really
easily, and that's where a contributor typically starts
 - even large changes can be split to multiple patches that are easier
to keep up to date with rebase and easier to apply upstream separately

With centralized VCS you typically get just one huge "local changes"
patch which makes working with multiple changes quite hard.

Unfortunately, git with its imperfections is probably going to be the
de-facto standard for open-source development until some 5 years from
now somebody finds they are really spending too much time working
around small and larger deficiencies of the various VCS tools nobody
cares to fix and writes a VCS v 2.1 ( in the sense CVS being around
1.0, SVN ~ 1.1, and git ~ 2.0).

Thanks

Michal