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

From my recent experiences using a git mirror to manage and merge the MBARI
patches, I can appreciate, and agree completely with, Rick's comments
(below).  For anyone used to CVS or SVN, Git brings a steep learning curve. 
It's a disruptive "new paradigm" with capabilities as amazing as its cryptic
error messages.

My learning experience was bewildering, but not too terribly frustrating. 
The fact is that there are now a lot of good resources on the web to ease
the pain.  The only real hacking required in applying my patches to a git
mirror repo was to write a short Ruby script that stripped the SVN key
expansions from them.
Otherwise, strings like $Date$ or $Author$ would prevent patches from
applying as git does not maintain such metadata in source files.  Its design
philosophy is to leave source absolutely untouched.  This causes real grief
only in the couple places where one sees code like (in runner.rb):

rcsid = %w$Id: runner.rb 11708 2007-02-12 23:01:19Z shyouhei $
Version = rcsid[2].scan(/\d+/).collect!(&method(:Integer)).freeze

After using git, I feel that features like the much touted "rebase" are not
all they were advertised to be.  If one has conflicts, rebase won't fix
them.  But rebase does automate away much of the tedium of "following the
dancing HEAD" that seems to be associated with getting patches accepted.  

For larger patches, following the HEAD can be a real chore.  I merged the
MBARI patches with four different Ruby versions.  First with the version
1.6.8 (don't laugh :-) we still use in our embedded ARM targets, then with
what I thought was the current production release (1.8.7), then with 1.8.6
(for EngineYard) and finally with 1.8 HEAD for Nobu.  Rebase really wasn't
much use for such extensive modifications.  By the end of the fourth round,
I was pretty tired.  Nobu probably had to do yet another round before he
could apply the subset that he finally accepted into the, by then yet
further evolved, HEAD.  The moral is:  in the current system, large patch
sets rot quickly and getting them into the core requires dogged
determination.  The key crash bug fixes for Continuations were first
submitted to list as patches years before I finally put up my "MBARI
patches" web site.

Right now, the core developers are, understandably, overworked and really
seem to dislike forking the source tree, as they alone are responsible for
its integrity.  But, experimental forks are key to testing new features. 
This is where a decentralized source management system like git might help: 
by encouraging forks and spreading the maintenance load among many more
specialized developers, leaving the core team to focus on new development
and aggregating patches (from forks) already vetted by trusted lieutenants.

- brent



Rick DeNatale wrote:
> 
> 
> Actually having made the transition between svn (and svk at times) and
> git, I'd say one needs to get comfortable with the changes one
> must/should make to ones workflow.  It's like learning to ride a bike
> you need to get the confidence that you can keep your balance.
> 
> Git is not just a new svn. Although you can start out using it as if
> it were, eventually you'll run into things which will confuse you.
> I've run into similar issues as Eric Hodel reported with git, but it's
> not that such things are unique to git, I've run into similar things
> with svn and other version control systems in the past, it's just that
> the way in, and out of those kind of confusing places is different.
> 
> On the other hand, in retrospect, I seem to find myself in those
> strange places far less frequently with git than with svn. And the
> fact that git changes are non-destructive gives me more confidence.
> 
> As for being too agile, as others have pointed out git doesn't force a
> wild-west approach to the code base.  Linux has been using git for
> longer than any open source project, and Linus and his committers have
> maintained control.
> 
> What git does though is allow users of the software to maintain local
> patches which are both easy to submit for consideration as part of the
> main branch, but also easily keep those patches in sync with the main
> branch as it evolves.
> 
> ...
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A25285---Feature--2033--Move-Core-Development-to-Git-tp25262987p25306016.html
Sent from the ruby-core mailing list archive at Nabble.com.