[ruby-core:34261] Re: Moving to Git?

At 11:58 PM +0900 1/8/11, NARUSE, Yui wrote:
>(2011/01/08 5:37), Lucas Nussbaum wrote:
>>On 08/01/11 at 05:13 +0900, Ryan Davis wrote:
>>>
>>>On Jan 7, 2011, at 12:02 , Daniel Bovensiepen wrote:
>>>
>>>>	- new people would be committing work to Ruby if we switch to git
>>>>		->  is this really true? how much stuff is coming back via the current git-mirror on github?
>>>
>>>DATA: There are a whopping FIVE pull requests on github.com/ruby/ruby (including closed). There are only three on shyouhei's (including closed).
>>>
>>>So, no, not really, despite there being 97 forks of ruby on github.
>>>
>>>Again, I think this is a family matter and the rest of the contributors on this thread are git zealots pushing an agenda more than a necessary solution.
>>
>>Is it really a good indicator? I would assume people able to contribute
>>to know that this is just a mirror, and that patches should be sent
>>through other means. Or was it documented that pull requests would be
>>processed?
>
>Don't spread FUD.

I normally interpret the acronym "FUD" to mean unreasonable or dishonest statements that increase fear, uncertainty, and doubt about a technology.

Questioning whether the number of pull requests to the ruby mirror on github is a good indicator to predict future levels of pull requests if Ruby were to switch to git is not unreasonable or dishonest.

If you have a different definition of FUD that does not include "unreasonable or dishonest" it would be helpful to bemore precise.

I think that switching to git would make the generation of both high *AND* low-quality patches and the associated pull requestseasier for non-committers.

To me a more important question is whether increased participation in ruby-core is useful and if so how the current coordination among the core team could effectively change to handle this increased flow.

>See r28569 for example.

I've setup, managed, and use svn, git, and projects that use both and I am curious about how that merge happened because AdrianBloomer's initial commit message was lost in the process.

You are referring to this changeset/commit:

  http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=28569

Which can be viewed on github here:

  https://github.com/ruby/ruby/commit/ce9c95293757a211bf9dcdb45908a835e5080f7d

  Merge branch 'mybranch' of git://github.com/orangea/ruby into trunk

  Conflicts:
	ChangeLog
  git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@28569 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Here's Adrian's original commit made to a branch named 'mybranch' in a repo he forked from https://github.com/shyouhei/ruby

  https://github.com/orangea/ruby/commit/e848a249bfc68437a77330b5715d80116f766b8e

  * numeric.c (fix_rev): Replaced fix_rev with '~num | FIXNUM_FLAG'.

Obviously commit messages can vary in value but in general they should be preserved.

The version 2 Pull-Request system that github rolled out last summer is quite nice: https://github.com/blog/712-pull-requests-2-0

It would be nice to integrate this with RedMine but while there is a beta Pull Request API described here: http://develop.github.com/p/pulls.html I don't see any kind of service hook API  which could be adapted to initiate a web hook that would notify redmine.

----

How I manage development that goes on in both git and svn repos at the same time.

When I have a project with a cannonical svn repo which also has a git mirror on which development occurs I setup a post-commit hook on the svn repo to push to a branch named trunk on the git repo. Separately I merge commits on the git trunk branch to amaster branch on git.

I tell committers NOT to push anything to the trunk branch in git. Instead a committer should combine in one local repo a git-svn clone of the svn repo and a clone of the repo on github. The committer now has copies of all the branches that are in the svn repo AND the master branch and any other branches that are just in the git repo.

It is a committers responsibility to merge the most up-to-date trunk into master and confirm that any changes made in the git branches work at which point they merge the change into their local trunk and use svn-dcommit to push to the svn repo.

The commit is then pushed to the trunk branch in github by the svn post-commit hook.

This works ... but it's more work to setup and manage than if it was all in git and most of the people I work with don't understand it very well because it is complex and they are working on other things.