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

On Sep 2, 2009, at 17:38, Run Paint Run Run wrote:

>>> * Opens Ruby development to a wider range of contributors. Ruby- and
>>> non-Ruby-based projects alike have shown a dramatic upswing in  
>>> contributions
>>> after moving to Git.
>>
>> This is scientifically proven?
>
> Heh, I confess not to have orchestrated a wide-scale statistical study
> on the matter, no. The anecdotal evidence, however, is very much in
> keeping with my claim. The experience of Rails
> (http://www.igvita.com/2009/01/27/ruby-swarms-visualizing-rails-git/)

None of my contributions from the svn days showed up here.  It seems  
to be biased towards git simply due to lack of data.

I had a patch for Rails sit around until it rotted simply because  
nobody bothered to communicate back the few problems that existed in  
it.  I don't think git magically solved the problem of Rails  
developers not caring about contributions.  I'm more willing to  
believe DHH releasing his stranglehold on committers (to the central  
repository) was the real change here.

> and the Linux kernel
> (http://www.linuxfoundation.org/publications/whowriteslinux.pdf)
> mirror those of other major projects which made the transition.

I would hope that the tool designed for the linux kernel development  
workflow would make linux kernel development work well.

>>> * Allows tickets to be handled by de facto topic branch  
>>> maintainers. A
>>> contributor interested in improving documentation, for example,  
>>> could review
>>> the documentation tickets, apply the relevant patches to his 'doc'  
>>> branch,
>>> then propose it be merged periodically. The core team could, and  
>>> should,
>>> still monitor this branch's progress, and intercede where necessary.
>>> Ultimately, development would suffer less from the current  
>>> bottleneck
>>> effect, allowing contributers to play a larger role.
>>
>> This sounds like more work than what happens now.  How is more work  
>> supposed
>> to make ruby development faster?
>
> It is indeed more work than happens now. Now being the time of severe
> ticket backlogs on Redmine (the statistics for which I cannot provide
> as Redmine is, again, unresponsive), and more requests than I have the
> decency to reference languishing without so much as an acknowledgment.

Ruby has a ticket system now so fixes to problems and backlogged  
problems are much more visible. It didn't used to be this way, it used  
to appear that all problems were backlogged.

> I am but an insignificant player, yet can vouch that I have a
> multitude of tickets in my buffer which remain locally because
> similar, submitted requests have been left to perish. The workflow we
> propose will alleviate this situation by distributing this work to
> extra and eager pairs of hands. It will require slightly more work to
> the benefit of significantly more progress.

You've done a lot of good work for Ruby.  You should ask for a commit  
bit.  IMO you deserve it.  It's usually this easy:

1) show you can contribute useful stuff
2) ask for a commit bit
3) commit (maybe occasionally asking if it's ok when you're unsure)

It's as if git will make people less shy about asking to get directly  
involved. If you're going to go to be continually writing patches is  
it really that hard to ask for a commit bit?  It's not like you're  
getting turned down for a date.

>>> * Working with the trunk becomes more pleasurable due to Git's  
>>> advanced
>>> toolset and significant performance benefits.
>>
>> I've found git less pleasurable and it's "advanced" toolset  
>> cumbersome and
>> unfriendly.  It's largely been a performance detriment to me.
>
> Perhaps if you could explain your difficulties, we may assist you in
> overcoming them? If you desire to use Git as SVN, the interface is so
> similar, that if one establishes compatiability aliases, the key
> remaining difference is Git's superior speed. By "performance
> benefits", I was referring to these magnificent speed benefits, which
> are especially noticeable with large repositories such as Ruby's. :-)

Today a coworker of mine was pulling from upstream and ran into a  
conflict.  (If you just push and assume everything is ok git doesn't  
say "please pull, there are conflicts" it says something like "can't  
fast-forward" which is far less clear than the former.)

He resolved the conflict and ran `git commit` then `git rebase -- 
continue` which proceeded to give a very unclear error message.   
Instead of `git commit` he should have used `git add`, but git  
couldn't be bothered to tell him that he probably didn't want to do  
that.

On the other hand, if I have a conflict in subversion or perforce I  
get a very helpful interactive resolving tool that lets me  
interactively merge conflicts or bring up my favorite editor for  
involved conflicts.

If I walk away from my computer in the middle of a conflict and come  
back later I can easily figure out where to continue with subversion,  
perforce, even CVS.  This isn't guaranteed with git (`git add` but  
don't `git rebase --continue`? your only clue is something like "not  
on any branch" in `git status`).

I've found that for the 90% use case of a VCS (committing software to  
a shared repository), git makes me do more work.  Advanced tools  
should make me do less work.

PS: Perforce does branching and merging better.