[ruby-core:25285] [Feature #2033] Move Core Development to Git
Run Paint Run Run
http://redmine.ruby-lang.org/issues/show/2033
Author: Run Paint Run Run
Status: Open, Priority: Normal
Assigned to: Yukihiro Matsumoto
Following from [ruby-core:21039], I formally propose that core development switches to Git. The obvious benefits include:
* 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.
* 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.
* Complicated feature proposals would take the form of branches. This solves the current problem of patches rotting in Redmine because `rebase` and Git's superior merging capability allow the patch to be kept in step with the trunk. Further, this allows parties interested in the feature to collaborate on the branch; only submitting a pull request when they deem it mature.
* Experimentation is encouraged because now anybody can branch, and contribute back that branch, with impunity.
* Working with the trunk becomes more pleasurable due to Git's advanced toolset and significant performance benefits.
Etcetera. I am particularly excited about the options that Git would give us to decentralize development: spreading the workload over a wider number of contributors, while still retaining the core team's vital role as gatekeepers. Redmine tickets alone suggest that the current path is not maintainable; the sooner we change our course, the easier the process will be.
In the previous ruby-core thread on this matter matz's sole objection was that certain scripts exist for the SVN workflow that would need porting to Git. If this is still the case, perhaps the scripts could be posted publicly so interested parties could port them? What objections remain?
----------------------------------------
http://redmine.ruby-lang.org
Hongli Lai
I support this idea.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2033
----------------------------------------
http://redmine.ruby-lang.org
Jeremy Kemper
Strongly agreed. Switching to git was a turning point for Rails development also.
There's a full svn mirror at http://github.com/shyouhei/ruby to start using today.
Yehuda Katz
I agree with this, and I think ruby-core wants to do this as well. I'll personally step up and agree to spend time moving the tools over. I think we could probably get a commitment from other folks as well (including some folks at GitHub, I'd guess).
So, where are they :)
Nicolás Sanguinetti
Yes. This would be great for ruby IMO.
Yui NARUSE
Some commiter of Ruby live on Windows.
And windows port of git, msysgit, is still preview (cygwin port is not acceptable).
So we can't move to git.
those benefits seem to be resolved by shyouhei's ruby in github.
If you fork his and publish your patch, we can take it.
(Of course, they must be well commented)
Federico Builes
+1 to this.
As I said in the original thread, I'll be glad to help porting any tools to the new system.
Luis Lavena
> Issue #2033 has been updated by Yehuda Katz.
>
>
> I agree with this, and I think ruby-core wants to do this as well. I'll personally step up and agree to spend time moving the tools over. I think we could probably get a commitment from other folks as well (including some folks at GitHub, I'd guess).
>
> So, where are they :)
According to 'tweets' there has been the rumor that Ruby-core do not
migrate to Git due lack of Windows support.
I must say that is completely inaccurate.
Git support has been excellent using msysGit releases, even with
integrated git-svn support.
Projects like rake-compiler and RubyInstaller uses Git and GitHub as
SCM and contribution platform, something we couldn't achieve using
Subversion.
In my humble opinion, the move to Git will highly increase the options
for people wanting to contribute to Ruby.
Regards,
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
Enrico Bianco
I strongly agree with this proposal.
Using Git with Windows is much easier than it used to be. Perhaps moving Ruby development from SVN to Git would even serve as a strong motivator to improve the Windows port of Git!
Ilya Grigorik
+1
I would also strongly encourage github as an option, instead of running own servers. To me, the main benefit of the switch is not even necessarily in Git vs SVN as much as in the transparency that it would enable. Let's face it, most of us are on GitHub already, following a ton of projects. Having Ruby there would just make sense.
Luis Lavena
>
> I would also strongly encourage github as an option, instead of running own servers.
With Git it doesn't matter, is just another remote to pull/merge or
cherry-pick from.
> To me, the main benefit of the switch is not even necessarily in Git vs SVN as much as in the transparency that it would enable. Let's face it, most of us are on GitHub already, following a ton of projects. Having Ruby there would just make sense.
I follow Ruby SVN using RSS and I must say that doing that way really
confuses me.
The RSS links points to cvscgi views, while Redmine points to
integrated commits.
I think depends on the level of integration that can be achieved with
Redmine which is going to decide the "origin" repository.
Jon
> And windows port of git, msysgit, is still preview (cygwin port is not acceptable).
> So we can't move to git.
As a user of msysgit on Win2K, WinXP, and Vista machines I've found the current msysgit preview to be very usable. While I personally prefer Mercurial, I'm quickly becoming a big fan of Git and Github.
The only difficulty I've had so far is the age old issue of line endings, which is easily solved by setting "core.autocrlf = false" globally. I use an editor (gvim) that understands both styles of line endings and there are many other good editors (free and non-free) on Windows that do the same.
Have any of the Ruby-committers-living-on-Windows actually had any specific problems with msysgit?
Jon
Eric Hodel
> Feature #2033: Move Core Development to Git
> http://redmine.ruby-lang.org/issues/show/2033
>
> Author: Run Paint Run Run
> Status: Open, Priority: Normal
> Assigned to: Yukihiro Matsumoto
>
> Following from [ruby-core:21039], I formally propose that core
> development switches to Git. The obvious benefits include:
>
> * 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?
> * 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?
> * Complicated feature proposals would take the form of branches.
> This solves the current problem of patches rotting in Redmine
> because `rebase` and Git's superior merging capability allow the
> patch to be kept in step with the trunk. Further, this allows
> parties interested in the feature to collaborate on the branch; only
> submitting a pull request when they deem it mature.
Can't this be done now with git-svn?
> * Experimentation is encouraged because now anybody can branch, and
> contribute back that branch, with impunity.
Ditto.
> * 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.
Ilya Grigorik
Run Paint Run Run
>> 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/)
and the Linux kernel
(http://www.linuxfoundation.org/publications/whowriteslinux.pdf)
mirror those of other major projects which made the transition. If you
require numerical arguments to be convinced, I will endeavor to
assemble the requisite data.
>> * 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.
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.
>> * Complicated feature proposals would take the form of branches. This
>> solves the current problem of patches rotting in Redmine because `rebase`
>> and Git's superior merging capability allow the patch to be kept in step
>> with the trunk. Further, this allows parties interested in the feature to
>> collaborate on the branch; only submitting a pull request when they deem it
>> mature.
>
> Can't this be done now with git-svn?
Such an approach can be poorly approximated by an intermediate user of
said gateway. But as the MBARI patches, the recent interest in the
win32-unicode branch, my trifling work on Onigurma, and many more
cases in recent memory serve to illustrate, this process is clumsy and
inelegant.
Put simply, while git-svn may flawlessly translate SVN to Git; the
converse can never be true: Git users must degrade their work, casting
aside the rich metadata Git supplies, so SVN can stomach it. Your
argument may be more properly put if reversed: Can the few who prefer
to retain the SVN toolset be accommodated by git-svn in conjunction
with a Git repository? Why yes, they can.
>> * 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. :-)
Ilya Grigorik
Jeremy Kemper
> On Sep 2, 2009, at 11:19, Run Paint Run Run wrote:
>
>> Feature #2033: Move Core Development to Git
>> http://redmine.ruby-lang.org/issues/show/2033
>>
>> Author: Run Paint Run Run
>> Status: Open, Priority: Normal
>> Assigned to: Yukihiro Matsumoto
>>
>> Following from [ruby-core:21039], I formally propose that core development
>> switches to Git. The obvious benefits include:
>>
>> * 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?
That's a good line. I assume you're using it rhetorically. The
proposal deserves good-faith consideration.
An observation or three:
Rails saw a surge in number of contributors, number of patches, and
patch quality after moving to git. Several contributors naturally
emerged as vetters and integrators. This widened the patch-examination
bottleneck by naturally spreading the responsibility among other
trusted contributors. No organization was required; this pleasantly
emerged as a property of the system.
I think number of contributors and patches went up just due to
transparency, accessibility, and responsiveness. It's hard to say, but
GitHub had a significant role here. I think patch quality has
increased largely because rebasing a topic branch against the main
line is extremely easy. Old fixes don't go stale.
Furthermore, we recently had an incredible experience with the first
RailsBridge bug mash:
http://wiki.railsbridge.org/projects/1/wiki/BugMash. Git was by no
means the reason for its success, but it acted as a strong enabler.
New users understood the workflow and tools with little trouble;
within two days we'd see 37 first-time contributors' patches applied
to master and hundreds of others'. We hope to repeat the experiment
before every stable gem release.
I was skeptical about moving from svn to git, but it has paid off big
time and in ways I hadn't anticipated. I've completely come around.
>> * 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's more apparent work, of course, but broadly and naturally
distributed among contributors of varying skill and interest using
tools honed for just this purpose.
>> * Complicated feature proposals would take the form of branches. This
>> solves the current problem of patches rotting in Redmine because `rebase`
>> and Git's superior merging capability allow the patch to be kept in step
>> with the trunk. Further, this allows parties interested in the feature to
>> collaborate on the branch; only submitting a pull request when they deem it
>> mature.
>
> Can't this be done now with git-svn?
It can, with caveats. You have to shove everything back through the svn funnel.
>> * Experimentation is encouraged because now anybody can branch, and
>> contribute back that branch, with impunity.
>
> Ditto.
Same.
>> * 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.
For decentralized development, cheap, effective branching and merging
is awesome and desperately needed. Git and many other SCMs beat the
pants off Subversion in this respect, and this alone is worth it.
In the interest of productive discussion about the topic at hand --
moving from svn to git -- I think we're all be best off discontinuing
a vim/emacsish discussion of whether git is "your style."
Best,
jeremy
Nobuyoshi Nakada
Status changed from Open to Closed
http://wiki.github.com/shyouhei/ruby/committerhowto
Nobuyoshi Nakada
And http://wiki.github.com/shyouhei/ruby/noncommitterhowto
Marc-Andre Lafortune
I'll only add to the compelling arguments presented so far a very enthousiastic "+1".
Yukihiro Matsumoto
Assigned to changed from Yukihiro Matsumoto to Yuki Sonoda
I think there's need a lot of work to do, like better Windows git port, moving svn based tools to git, etc.
Luis Lavena
> Issue #2033 has been updated by Yukihiro Matsumoto.
>
> Assigned to changed from Yukihiro Matsumoto to Yuki Sonoda
>
> I think there's need a lot of work to do, like better Windows git port, moving svn based tools to git, etc.
Dear Matz,
I would really like to know what are the limitation experienced using
Git on Windows that this perception of "not good enough" keep
appearing repeated times?
Perhaps this happens in the japanesse list, so would love and
appreciate someone take a couple of minutes to express those in
english.
Maybe as a community we can help solve those and improve the Windows Git port.
Thank you.
Ron Mayer
+1
While I appreciate that I could (and did) already use git with ruby source
code through either git-svn or other people's conversions from SVN like
http://github.com/rubyspec/matzruby/tree/master , collaborations between
such repositories would be more pleasant if they all had an official
common ancestor.
Maybe as a small step in this direction the ruby project could first
publish an official svn->git conversion of their own (or adopt the
one on github.com/rubyspec) and insure that it's kept up-to-date?
The postgresql project has done similar, where http://git.postgresql.org
hosts an automated mirror of the cvs repository that is still the
place where their core team commits patches. It seems to me that
many of the patches submitted now come from individual developer's clones
of that git repository. IMHO this comes in especially useful during
code reviews, where patch reviewers sometimes interact with the patch
writers through such repositories:
http://archives.postgresql.org/pgsql-hackers/2008-11/msg00303.php
Yukihiro Matsumoto
In message "Re: [ruby-core:25313] Re: [Feature #2033] Move Core Development to Git"
on Thu, 3 Sep 2009 16:02:38 +0900, Ron Mayer <rm_r...@cheapcomplexdevices.com> writes:
|Maybe as a small step in this direction the ruby project could first
|publish an official svn->git conversion of their own (or adopt the
|one on github.com/rubyspec) and insure that it's kept up-to-date?
For various reasons, we cannot move to git at once, so as a small
step, use <git://github.com/shyouhei/ruby.git>. See
http://wiki.github.com/shyouhei/ruby/committerhowto
http://wiki.github.com/shyouhei/ruby/noncommitterhowto
matz.
Michal Suchanek
I guess that's a good start.
Recent experience with git and git-svn shows that there is a wide gap
between having an official upstream git repository and locally
mirroring an upstream svn with git-svn.
Thanks
Michal
James Edward Gray II
There is a typo in that document. This line:
% git checkout -b my_feature orogin/trunk
should be:
% git checkout -b my_feature origin/trunk
James Edward Gray II
Jon
>
> Thank you.
> --
> Luis Lavena
> AREA 17
I found the following blog helpful when I was first evaluating msysgit:
I initially avoid installers like the plague until they prove themselves by not trashing my system.
As such, I started with the 7-zipped PortableGit version and have had a very good experience with the following setup on my Windows systems (I've not used the msysgit installer so I have no advice one way or the other on it)
- unzip to any directory without a space in the pathname...<GIT_INSTALL> from now on.
- add <GIT_INSTALL>\cmd to %PATH%
- generate keys via "ssh-keygen" from the Git-Bash prompt using <GIT_INSTALL>\git-bash.bat. This correctly creates a ".ssh" dir containing your keys in the right place.
- set up global config with name, email, aliases, diff/merge tools like kdiff3, etc as well as set "core.autocrlf = false" (VERY IMPORTANT)
- upload keys to Github, gitorious, etc.
- start cloning, hacking, merging, branching...
- use either Git-Bash or standard cmd.exe for cmd line git
While I found some of Git's idioms and naming conventions strange at first, being able to type things like "git help reset" and have decent docs pop up in my browser have been great for shortening my learning curve.
So far so good for me as a user of both msysgit and git.
Jon
Run Paint Run Run
> I would really like to know what are the limitation experienced using
> Git on Windows that this perception of "not good enough" keep
> appearing repeated times?
Indeed. Windows support is seeming more and more like a paper tiger. We have experienced Windows developers telling us that the current situation is reasonable, and the anecdotes I've found online are along the same lines. Before this argument is repeated can it be clarified?
> moving svn based tools to git
Please could these tools be named? In the tool/ directory of trunk only make-snapshot appears to both rely on SVN and not support Git. Where are the others?
> I think there's need a lot of work to do
It would help if we could enumerate it. If we can compile a list we can determine our next steps.
Stephen Bannasch
I think moving to git would be great.
Some concerns expressed by Matz:
>> moving svn based tools to git
>> I think there's need a lot of work to do
> It would help if we could enumerate it. If we can compile a list we can determine our next steps.
One type of work is adapting or removing sections of code that use or depend on subversion keyword expansion.
See one example here:
fixed crash in lib/logger.rb from dependency on svn keywork expansion
http://redmine.ruby-lang.org/issues/show/1978
I don't think fixing these kind of problems is very hard ... but I haven't made any estimate of how big the task is.
Urabe Shyouhei
>> Some commiter of Ruby live on Windows.
>> And windows port of git, msysgit, is still preview (cygwin port is not acceptable).
>> So we can't move to git.
>
> As a user of msysgit on Win2K, WinXP, and Vista machines I've found the current msysgit preview to be very usable. While I personally prefer Mercurial, I'm quickly becoming a big fan of Git and Github.
That's not the point. The problem on msysGit is that it IS a preview. It's
not a matter of stability. We cannot believe a preview product especially when
that preview software is a fundamental tool to us, such as git.
Michal Suchanek
And if I made a new site that offered the same package and labeled it
final would you trust it then?
What is preview or final or stable is relative to the developer
releasing the package.
At the very least
- this preview package has been tested by people writing here (and
probably many more elsewhere) so it can be labeled final by popular
vote
- people who insist on doing so can still use a SVN mirror
Thanks
Michal
Urabe Shyouhei
> 2009/9/4 Urabe Shyouhei <shyo...@ruby-lang.org>:
>> Jon wrote:
>>>> Some commiter of Ruby live on Windows.
>>>> And windows port of git, msysgit, is still preview (cygwin port is not acceptable).
>>>> So we can't move to git.
>>> As a user of msysgit on Win2K, WinXP, and Vista machines I've found the current msysgit preview to be very usable. While I personally prefer Mercurial, I'm quickly becoming a big fan of Git and Github.
>> That's not the point. The problem on msysGit is that it IS a preview. It's
>> not a matter of stability. We cannot believe a preview product especially when
>> that preview software is a fundamental tool to us, such as git.
>>
>
> And if I made a new site that offered the same package and labeled it
> final would you trust it then?
I can then evaluate that software. You know, whether a release is final or not
is aside form whether I trust it or not.
> What is preview or final or stable is relative to the developer
> releasing the package.
Yes. Trusting a software includes trusting its developer. How can you trust
it when you cannot trust its creator? I suspect there're reasons for the
developer to say it's still a preview. And I trust she/he on that.
> At the very least
>
> - this preview package has been tested by people writing here (and
> probably many more elsewhere) so it can be labeled final by popular
> vote
Maybe. But can those people see to that? We are not choosing our wall clocks.
A source code management system is vital to an open source software community.
I know you remember our repository was once cracked when we used CVS.
> - people who insist on doing so can still use a SVN mirror
You're saying to move to Git while mirroring that Git repo with SVN? Can that
be possible?
Urabe Shyouhei
Rails, there should be problems. A problem may be the hardness for Rails to
catch-up with Ruby, when both of them are equally as agile.
So sorry but I don't like the idea for Ruby to move into a fully decentralized
development. There should be at least one single center of Ruby as we have
today. And as a centralized development tool, Subversion is the best thing we
have.
I think a centralized SVN repo + official git-svn mirror is the best way for
ruby because that should suit for its characteristics and development style.
Most claims from git enthusiasts can be met with a git-svn mirror I believe.
The only thing that cannot be met may be "to make ruby git based anyway" kind
of groundless request.
Ryan Davis
間違いない
Urabeさんは私の太陽、私の星、私の月です
Urabeさんが大好きです
Federico Builes
On Sep 3, 2009, at 6:44 PM, Urabe Shyouhei wrote:
> Ruby is a basic infrastructure that needs to be stable. If it goes
> as agile as
> Rails, there should be problems. A problem may be the hardness for
> Rails to
> catch-up with Ruby, when both of them are equally as agile.
Is this issue really related to the SCM that the project uses?
Many projects have had an increase in their number of collaborators
when they moved to Git, but that doesn't mean that no one will be in
charge and that it will be moving so fast that projects like Rails
won't be able to keep up with it (I'm not entirely sure that I got
your point there).
> So sorry but I don't like the idea for Ruby to move into a fully
> decentralized
> development. There should be at least one single center of Ruby as
> we have
> today. And as a centralized development tool, Subversion is the
> best thing we
> have.
Excuse my lack of knowledge in this matter, but what prevents ruby-
core from maintaining a canonical Ruby Git repository hosted in the
same servers that SVN resides in right now (or in Github if you don't
want to go through the admin. hassle)?
You can still give commit access only to your list of trusted members
and this "central" repository will be the one that everyone pulls off
when they want to get the official version.
What does SVN gives you that Git misses in this case?
> I think a centralized SVN repo + official git-svn mirror is the best
> way for
> ruby because that should suit for its characteristics and
> development style.
I would really appreciate it if you could be more specific in the
"characteristics and development style" that SVN fits so well and that
Git doesn't.
> Most claims from git enthusiasts can be met with a git-svn mirror I
> believe.
An official git-svn mirror would be greatly appreciated, it would be
better than the current situation, but can't we "have the cake and eat
it too"?
Thanks
--
Federico
Aaron Patterson
There is one: http://github.com/shyouhei/ruby/tree/trunk
---
Aaron Patterson
http://tenderlovemaking.com
Michal Suchanek
>> - people who insist on doing so can still use a SVN mirror
>
> You're saying to move to Git while mirroring that Git repo with SVN? Can that
> be possible?
That's certainly possible. SVN can store any code git can. It just
lacks the tools for working with the code and I would be surprised if
there was no tool for importing changesets from git to SVN.
However, there's not much difference between having a official SVN
repository and official git mirror or the other way around for the
outside world. Perhaps making git the primary repository would make it
easier for some of the core developers to use git's additional
features not available in svn. However, that's a decision for Ruby
core developers if they want these features or not.
Thanks
Michal
Eric Hodel
>>> * 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.
Urabe Shyouhei
> Hello Urabe,
>
> On Sep 3, 2009, at 6:44 PM, Urabe Shyouhei wrote:
>
>> Ruby is a basic infrastructure that needs to be stable. If it goes as
>> agile as
>> Rails, there should be problems. A problem may be the hardness for
>> Rails to
>> catch-up with Ruby, when both of them are equally as agile.
>
> Is this issue really related to the SCM that the project uses?
>
> Many projects have had an increase in their number of collaborators when
> they moved to Git, but that doesn't mean that no one will be in charge
> and that it will be moving so fast that projects like Rails won't be
> able to keep up with it (I'm not entirely sure that I got your point
> there).
Yes, it may not be directly a SCM issue. The history of ruby has been a
history of unmaintained codes. Even today without the chaos of distributed
development, there are many lines of codes in its repo which are not baby-sat.
When you want to increase number of contributions yet decrease number of
unmaintained codes, there should be some mechanism to enforce that. Ruby lacks
that now.
>> So sorry but I don't like the idea for Ruby to move into a fully
>> decentralized
>> development. There should be at least one single center of Ruby as we
>> have
>> today. And as a centralized development tool, Subversion is the best
>> thing we
>> have.
>
> Excuse my lack of knowledge in this matter, but what prevents ruby-core
> from maintaining a canonical Ruby Git repository hosted in the same
> servers that SVN resides in right now (or in Github if you don't want to
> go through the admin. hassle)?
> You can still give commit access only to your list of trusted members
> and this "central" repository will be the one that everyone pulls off
> when they want to get the official version.
> What does SVN gives you that Git misses in this case?
You're saying "there's no reason not to move to git"; but I'm saying "there's
no reason to move to git". Why you hate svn so much? It's perfect for us.
>> I think a centralized SVN repo + official git-svn mirror is the best
>> way for
>> ruby because that should suit for its characteristics and development
>> style.
>
> I would really appreciate it if you could be more specific in the
> "characteristics and development style" that SVN fits so well and that
> Git doesn't.
I was pointing to the fact that ruby development is centralized. Centralized
to matz. Have you ever seen a single line email from matz that just says
"commit that please"? Why ruby development do not scale is clear; matz is the
bottleneck. Decentralized development insist him (and us) to grately delegate
what he's doing now to our community. Perhaps that should make YOU happy, but
also make matz unhappy. If you want to hijack his / other committers' power
and authority, you should watch your step not to offend them. To protect their
sanctuary yet to make your path for contribution, a SVN repo + git-svn mirror
is the best way I believe.
Jeremy Kemper
I identify with this sentiment. I resisted moving away from svn too.
It wasn't until a few months of deeply using git that I began to
appreciate how it had changed my development style.
I think the git-svn mirror is a fine bridge. However, I encourage Ruby
core to use the bridge, too, even if just to experiment.
>>> I think a centralized SVN repo + official git-svn mirror is the best
>>> way for
>>> ruby because that should suit for its characteristics and development
>>> style.
>>
>> I would really appreciate it if you could be more specific in the
>> "characteristics and development style" that SVN fits so well and that
>> Git doesn't.
>
> I was pointing to the fact that ruby development is centralized. Centralized
> to matz. Have you ever seen a single line email from matz that just says
> "commit that please"? Why ruby development do not scale is clear; matz is the
> bottleneck. Decentralized development insist him (and us) to grately delegate
> what he's doing now to our community. Perhaps that should make YOU happy, but
> also make matz unhappy. If you want to hijack his / other committers' power
> and authority, you should watch your step not to offend them. To protect their
> sanctuary yet to make your path for contribution, a SVN repo + git-svn mirror
> is the best way I believe.
Ultimately, any development workflow may be accommodated, included
protected sanctuaries.
But I think the feeling is clear: no hasty moves for unneeded benefits.
Best,
jeremy
Leonard Chin
#2033] Move Core Development to Git" on IRCNet's %ruby from Thursday,
September 3rd beteween 10am and 2pm JST. I'm providing this translated
log on behalf of Yugui, and with the permission of the participants.
If nothing else, it will serve as a peek into the opinions of a few
people on the "other side".
== Who ==
- n0kada: aka nobu, Ruby Committer
- unak: aka usa, Ruby Committer (active contributer to the Windows version)
- yugui: Ruby 1.9 Release Manager
- eban: Ruby Committer (active contributer to the Windows version)
== Log ==
unak: [ruby-core:25280] He should have added that "unak doesn't read
English mails"
eban: would anyone actually know who unak is?
unak: true
n0koda: if you checkout win32-unicode-test and still don't know,
there's not much more you can do
unak: I don't think unak appears anywhere in that
n0kada: doesn't it appear in $Author$?
eban: usa
unak: it should be usa
n0kada: so it was usa. whatever
eban: "USA doesn't read English mails." would be surreal
----
eban: everyone seems to love git
unak: if they want to use git they should just use it
unak: why do they have to force it on other people?
n0kada: just git clone git://github.com/shyouhei/ruby.git
n0kada: and just linking that up with git svn should be enough?
unak: I'm pretty sure there was a clear explanation there too
n0kada: so pasting http://github.com/shyouhei/ruby/tree/trunk on the
ticket should close it?
unak: seems like nobody understands that converting the main
repository to git will only directly affect committers, not
non-committers
unak: 1) if you want to play with ruby's source using git, there are
already git repository (miirrors) so you can just do what you like
with them
unak: 2) it doesn't matter if the main repository is CVS or Subversion
or Git, it has nothing to do with any of you
n0kada: i don't think there was an explanation of git svn there...
unak: http://wiki.github.com/shyouhei/ruby/committerhowto
unak: you mean that link?
n0kada: that's the first time I've seen that
n0kada: I pasted that link and closed the ticket
eban: http://wiki.github.com/shyouhei/ruby/noncommitterhowto
unak: I think you should add it to the top of the (Ruby) wiki, but I
guess its fine just as a ticket
----
n0kada: runrun just keeps on talking
n0kada: but not with any arguments I haven't seen before
eban: where are you talking?
n0kada: on talk on freenode
unak: what are you talking about?
eban: git probably
n0kada: #2033
unak: why do they keep on trying to force other people to use git?
n0kada: <runpaint> Because for it to be successful there has to be a
snowball effect: a couple of people use it, which encourages more
people to use it, which changes the way in which those people are
organised, which encourages more people to use it, etc. A mirror can
be ignored. I'm not saying it couldn't work, merely that the
commenters in that thread supported moving development to Git; not
just a mirror.
unak: can you summarize it to 3 lines?
n0kada: we want to use it so you guys must use it too
unak: i can't see any explanation for why a mirror isn't sufficient
n0kada: I told him to explain that after reopening the ticket
n0kada: that was my reply to his reason
unak: "a mirror won't work. because it won't work."
unak: thats all he seems to be saying
unak: this is getting annoying. We should just close svn.ruby-lang.org
unak: that's basically the situation he's looking for, right?
n0kada: including the official mirror?
n0kada: <n0kada> now usa proposed to open the official mirror and to
close svn.ruby-lang.org :)
n0kada: <runpaint> :-D Success! :-)
unak: All we need to do now is to get Urabe to say that his mirror is
now "Official" and we're done
unak: So, who exactly benefits from not keeping svn.r.o alive?
n0kada: Who own's http://github.com/ruby ?
n0kada: that would make it look more official
unak: lame
n0kada: No, I mean the feeling of "official/unofficial"
n0kada: i think that's the problem
unak: and I'm saying that the problem of the "feeling" is lame
eban: then you should just state that and we'll be done
n0kada: I think that was the problem from the beginning, is what I'm saling
unak: so why do we have to do this just to make runrun feel better?
unak: if anything, you should be giving more priority to my feelings
n0kada: I'm sure he just wants to feel better without getting in the way
n0kada: It's true that there are lots of tickets that haven't been dealt with
n0kada: On bottleneck is that Urabe's mirror isn't refreshed frequently enough
unak: That's enough. Let's just close svn.r.o and make Urabe's git
mirror official and announce it and get it over with
n0kada: to close svn...
unak: Refresh frequency is only a problem when you can compare it to
commits. If all you can see is the mirror then it shouldn't be a
problem
yugui: I think that git's ability to stimulate community activity is
proven by the example of rails
yugui: So, I guess its fine as long as it doesn't get in the way of
development on svn?
unak: now that there is already a git mirror, I don't understand what
more they could want.
unak: So if the problem is that they can still see the svn repository,
then we should stopping showing it to them
unak: that's just the logical conclusion I arrived at
yugui: I think that what they are asking for is a way for branches
forked from the git mirror to be merged back into a tree for release
yugui: I'm against relying on commercial services like github
unak: but, I guess it should be enough for now
unak: "a way for branches forked from the git mirror to be merged back
in a tree for release"
unak: What ever you use, some kind of tool will be needed for that
yugui: svn's history and merge information is rather weak
yugui: you lose information
yugui: that gets in the way of managing further forks
yugui: I think its those kind of minor details that adversely affect
the activity of the community
unak: that's enough. please, just go and use git
yugui: I think the problem can be solved by using primary git
repository, and making svn a mirror of that
n0kada: what kind of information is lost?
yugui: n0kada: When you merge, information relating to the merge branch is lost
yugui: and if svn is used as the main repository, the hashes change
when you do a git svn dcommit
lchin: yugui: that problem is partially solved from svn 1.5 onwards
with svn:mergeinfo, though its kind of a hack
yugui: After merging a particular branch, merging other forks of that
particular branch becomes difficult
yugui: by difficult, i mean its basically impossible to do so while
keeping git-style history information from the merge point
yugui: I guess you could just rebase, but I think that communication
cost would kill the community
yugui: I just got a similar request from wycats
unak: In exchange I'll die, just hurry up and change over to git
n0kada: will everything be solved by having an svn mirror?
yugui: I think it would be a good idea to keep svn around as a branch
which offers a high probability of leading to a release
n0kada: releasing directly from git would be problematic
yugui: rather than considering svn as "the main place where releases
come from", considering it as "the branch where there is a high
probability of being merged into the master" makes it easier for other
developers to get into the flow of development
yugui: in that case, all the hard work gets left to the release manager
yugui: comitters who want to keep on using svn can keep on using it
n0kada: but if we get bug reports, how do we even know if its the
branch we know about?
n0kada: dying from just the bug tracking workload would suck
yugui: thats why there is a unique hash
yugui: if you can't identify the branch, you can just reject the bug
report and ask for the details of the branch
n0kada: I guess if we ignore versions compiled from git then...
yugui: I see. If we release from git, then people working on platform
dependency issues could have a hard time of it
n0kada: I don't object to having an entry point for git, and a
separate entry point from svn
yugui: how about you, unak?
unak: what?
yugui: are you ok with having both?
unak: whatever is ok
yugui: "whatever is ok" sounds more like a critical response to me
yugui: is that an objection to the proposal to stop using svn?
unak: I'll just fork it
n0kada: from git?
n0kada: [ruby-core:25309] what do they mean by "svn based tools"?
n0kada: i guess they mean tool/
yugui: I think make-snapshot is the only problem
eban: how about the auto-update of version.h
n0kada: i forgot about version.h
unak: personally, i don't care about "official", so you can do what
you want and just not worry about me
n0kada: the snapshot can just continue to be produced from the svn frontend
n0kada: with r12345 and r12346, its easy to see which is newer, but
with abc1234 and abcd4321 hashes, you can't easily tell which is newer
yugui: I think you'll get used to it
n0kada: I don't think I'll suddenly be able to understand raw hashes
yugui: at any rate, not having unak around will be a problem
unak: I'm sure there won't be any problem
unak: thanks to git, the patches will just roll in
yugui: that isn't a fair response. You know that there are lots of
subtleties with OSes that are really tricky to handle well
yugui: especially with windows, people willing to deal with that
platform are few and far between
unak: if its important, then someone will eventually deal with it
right? It's "open source"
n0kada: whatever the backend for svn is, whether fsfs or git or
whatever, I don't care. But I don't see any good reason to throw away
svn.
yugui: I can't deny that small details like revision number are a
pain, just like how having git mirror svn leads to lots of small,
problematic details that raise the bar for participation
yugui: unfamiliarity with git's collection of commands is another
undeniable issue
yugui: Anyway, could you please add a reply to the ticket about the
lack of a reason to get rid of svn?
yugui: the worst thing to have is a communication gap
----
== END OF TRANSLATION ==
--
Leonard Chin
Jon
I strongly agree with your point that a fundamental development tool must be stable for the core committers and their workflows. Quite frankly, anything else is waste of their precious and limited time.
Having trade in your SVN SuperHero utility belt for Git Grasshopper training wheels in the short term really is a developer tax that no one is really eager to pay.
That said, I felt strongly enough that the "preview" label to the current msysgit was incorrect that I came out of "lurk mode" to share my successful experience with msysgit on Windows, and hopefully encourage others to give it a try and decide for themselves. I also have no affiliation with the msysgit project other than a happy user.
One thing that may help minimize the developer tax of learning Git and evaluating whether msysgit in particular will meet the needs of the core developers using Windows, is to add a Committers Workflow Recipes page to your http://wiki.github.com/shyouhei/ruby
Similiar to your http://wiki.github.com/shyouhei/ruby/committerhowto the page would primarily focus on providing Ruby-specific Git workflows that help SVN-based committers quickly get productive with Git. For example, it could be used as a "whiteboard" of sorts in which a committer my post their favorite SVN time-saving trick "How do I do ... in Git?" and others with more Git expertise could answer.
Sure, one can use Google and find a bunch of useful Git tidbits, but having ruby-core Git usage specifics in one place is a value add.
The Committers Workflow Recipes wiki page does not address the perception of msysgit instability, but I think it could dramatically help lower the developer tax of switching to Git for ruby-core specifics. And it should help anyone evaluating msysgit's stability be able to quickly focus on whether msysgit is stable for their particular workflows.
Jon
Nikolai Weibull
> Having trade in your SVN SuperHero utility belt for Git Grasshopper training wheels in the short term really is a developer tax that no one is really eager to pay.
Enough with the fear, uncertainty, and deception.
This is (at least) the third time we’re discussing this. Can we, like
I also asked for last time to no avail, please skip the +1’s, the Git
> SVN, and the SVN = OK and focus on actual merits of switching (which
I am, incidentally, for)?
Nikolai Weibull
And yes, I realize now that I posted this to the absolutely most wrong
mail, given what followed that statement. Sorry, Jon.
Jim Weirich
On Sep 4, 2009, at 4:43 AM, Eric Hodel wrote:
> 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.
FYI: I've configured git to uses the perforce merge tool. I can send
you the config necessary for this if you are interested.
--
-- Jim Weirich
-- jim.w...@gmail.com
masayoshi takahashi
2009/9/3 Yukihiro Matsumoto <ma...@ruby-lang.org>:
> For various reasons, we cannot move to git at once, so as a small
> step, use <git://github.com/shyouhei/ruby.git>. See
>
> http://wiki.github.com/shyouhei/ruby/committerhowto
> http://wiki.github.com/shyouhei/ruby/noncommitterhowto
I like the phrase 'History repeats Itself.'
Subversion is not the first SCM for development of Ruby.
Ruby had used CVS in old days. I guess it is good thing
for us to know (or remember) when and how to move
from CVS to SVN.
On 2005-07-01, about 4 years ago, Shugo suggested to use SVN
as official SCM of Ruby. ([ruby-dev:26421])
At that time, some pros and cons were posted in ML.
1. In SVN, making branch is fast
2. In SVN, making diff to HEAD is fast too
3. WinCVS's graph function is good; TortoiseSVN's one is bad
4. TortoiseSVN in 1.14 is not stable(but 1.2.1 seems stable)
5. In SVN, commit is atomic; its commit log is useful when
many files are modified.
6. BerkleyDB backend is(was?) not stable. FSFS is stable(?)
We also talked about tools for Windows (as we do now for git).
Some people said TortoiseSVN seemed good but unstable,
and svn commandline client is stable and good for CLI people.
On 2005-07-03, Kouhei Sutou made an experimental repository
of Ruby used by cvs2svn. Some commiters used it and found
some functions of svn was slower than CVS, such as
annotate and log.
But for a while, CVS was continued to use as one true official
SCM tool of Ruby. I could not find the main reason of it.
On 2006-11-28 (more than one year later), usa wrote a summary
of 1.8, 1.9 and moving to SVN ([ruby-dev:29964]).
In the background of this, there was a problem how to merge
YARV into Ruby. Some thought It's the chance to move to SVN.
(cf. [ruby-core:9385])
On 2006-12-20, the mail '[ruby-dev:30039] CVS freeze' was posted
by Shugo. CVS repository was freezed.
On 2006-12-21, the mail '[ruby-dev:30043] SVN ready' was posted
by ko1. SVN repository was ready for use.
Since then, Ruby has used SVN as the official SCM.
That's all.
IMHO, the change of development environment of Ruby is not fast,
but when the chance has come, it happens at the end.
So, if git is better than SVN for Ruby, we will move to git some day.
Thanks,
Masayoshi Takahashi
Michal Suchanek
> Hi all,
Hello
> IMHO, the change of development environment of Ruby is not fast,
> but when the chance has come, it happens at the end.
> So, if git is better than SVN for Ruby, we will move to git some day.
>
At the same time it is necessary to speak about moving to git to get
the lists of pros and cons of the different SCMs as viewed by
different people involved with Ruby in different ways.
Also as a result of this talk we got the git mirror mentioned above
which may not be perfect but is certainly helpful.
Thanks
Michal
Eleanor McHugh
are missing is that the current core team are comfortable with SVN.
There has to be a compelling argument for how the change would support
their existing workflow but from what I've read the pressure is mainly
about how git will appeal to a broader community: a community that if
it were really so keen for extending development could already fork
MRI and take the codebase in new directions.
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Rick DeNatale
McHugh<ele...@games-with-brains.com> wrote:
> The point I suspect that a lot of those pushing for the move to git are
> missing is that the current core team are comfortable with SVN.
A very correct point, I'm in complete agreement.
> There has to
> be a compelling argument for how the change would support their existing
> workflow but from what I've read the pressure is mainly about how git will
> appeal to a broader community: a community that if it were really so keen
> for extending development could already fork MRI and take the codebase in
> new directions.
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.
I also should say something about the effect that github has had, by
adding 'social' features to git, making it easy for both project
owners and contributors to have visibility to what's happening on a
family of forks, github makes contributing to, and maintaining an open
source project much more pleasant, once you get used to how git and
github work.
My purpose here isn't to push or force anyone to 'move' to git, but I
hope it encourages more experimentation with it as a means of
self-education.
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Aaron Patterson
> The point I suspect that a lot of those pushing for the move to git
> are missing is that the current core team are comfortable with SVN.
> There has to be a compelling argument for how the change would
> support their existing workflow but from what I've read the pressure
> is mainly about how git will appeal to a broader community: a
> community that if it were really so keen for extending development
> could already fork MRI and take the codebase in new directions.
I agree. Git is not a magical potion that makes the patches roll in.
I use git for my OSS, but the fact that the core team uses SVN has in
no way hindered my contributions to Ruby. In fact, it doesn't even
stop me from using git to contribute to Ruby. If you look at my last
few patches, you'll notice they are from the git mirror.
Switching scm's is something for the core team to decide. We should
stop talking about this bike shed and pay more attention to stuff that
matters.
Joshua Ballanco
> The point I suspect that a lot of those pushing for the move to git
> are missing is that the current core team are comfortable with SVN.
> There has to be a compelling argument for how the change would
> support their existing workflow but from what I've read the pressure
> is mainly about how git will appeal to a broader community: a
> community that if it were really so keen for extending development
> could already fork MRI and take the codebase in new directions.
I just wanted to jump in and point out that this has, in fact, already
been happening. JRuby has Git as its official repo at http://github.com/jruby/jruby
, and MacRuby now has a Git repo that mirrors the core SVN repo at: git://git.macruby.org/macruby/MacRuby.git
(see the message at: http://lists.macosforge.org/pipermail/macruby-devel/2009-August/002261.html
for more information on that).
Cheers,
Josh
Yehuda Katz
The point I suspect that a lot of those pushing for the move to git are missing is that the current core team are comfortable with SVN. There has to be a compelling argument for how the change would support their existing workflow but from what I've read the pressure is mainly about how git will appeal to a broader community: a community that if it were really so keen for extending development could already fork MRI and take the codebase in new directions.
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
Ron Mayer
> However, there's not much difference between having a official SVN
> repository and official git mirror or the other way around for the
> outside world.
I believe one difference is that it'd be easy to keep as much (or
as little) of the history of changes made by developers between
checkins with GIT, while with SVN, I imagine much of that history
is lost.
For example look at the graphical view of the recent
Linux kernel commits...
http://repo.or.cz/git-browser/by-commit.html?r=linux-2.6.git
...and you see multiple commits on most of the branches that
get merged each day.
I imagine with SVN, it's only easy to preserve a single
commit for each of these short-lived branches.
Brent Roman
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.
mathew
For decentralized development, cheap, effective branching and merging
is awesome and desperately needed. Git and many other SCMs beat the
pants off Subversion in this respect, and this alone is worth it.
OK, so now explain why Git, and why none of the many other SCMs.
For example, bzr has a much simpler to understand interface than Git, and unlike Git it has a proper Windows version. It allows decentralized, disconnected development, and supports easy feature branching.
Bzr also has excellent integration with RedMine, and there's the option of using LaunchPad if something even more elaborate is needed.
So, why not bzr?
mathew
--
<URL:http://www.pobox.com/~meta/>
Luis Lavena
Been user of Bazaar for long time, dealing with projects in LaunchPad
and locally at our company.
Pros:
- Able to publish a repository over a dumb protocol make it easy to
share with others quick code.
- Extensible by plugins
Cons:
- Startup time of Bzr for command line commands is a a killer. To
solve that you need to use the Bzr shell.
- To switch between branches of a project you need to clone a
different working copy, unlike Git.
- LaunchPad information and distribution can be overwhelming for newcomers.
During my usage of Bazaar for development of RubyInstaller found a
series of performance penalties when dealing with the checkout tree
generated by all the tools and files the project generates.
After dealing with that slowness, did a test with Git and what is
considered a "preview" version of it for Windows. To my surprise,
performance was great, and scan of changed files, even on huge working
copies ended being even faster than subversion.
Anyhow, just my personal experience.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
Eero Saynatkari
>
> I agree. Git is not a magical potion that makes the patches roll in.
Actually, Git *is* a magical potion in the sense that a
sufficiently advanced sociology is indistinguishable from
magic.
There is, purely on technical merits, nothing wrong with
using SVN or any other version control system, but moving
to Git would undoubtedly increase interest in contributing
by a significant factor compared to any other solution for
some unknown reason.
One aspect that is not being adequately addressed has been
brought up as sort of a side note: Github. Say of it what
you will, but the current development model of Ruby, from
an outsider's view, is very Web 0.3. Can anyone tell me,
offhand, the sequence of links to click to view the latest
commits to Ruby 1.8.8 in the SVN repository? Add to this
the preceived opacity of the development process, and you
have all the ingredients needed to scare the more timid
among us off.
I personally have no desire whatsoever to be exposed to
the MRI codebase when it is not an absolute necessity,
and the actual benefits of having all kinds of yahoos
writing patches are probably debatable, but accessibility
*is* currently an issue.
> Switching scm's is something for the core team to decide. We should
> stop talking about this bike shed and pay more attention to stuff that
> matters.
I find "law of triviality" to be a better description than
"bike shedding," especially if it is ANSI-coloured green.
Eero
--
Magic is insufficiently advanced technology.
Eleanor McHugh
> I personally have no desire whatsoever to be exposed to
> the MRI codebase when it is not an absolute necessity,
> and the actual benefits of having all kinds of yahoos
> writing patches are probably debatable, but accessibility
> *is* currently an issue.
Agreed. I've occasionally considered getting involved in core
development but the whole process seems very opaque and as much of my
interest is in low-level uses of Ruby - which necessarily means
forking and extensive hacking - I've allowed myself to be daunted by
the uncertainty of the existing arrangements.
This is less an issue of tools than of social factors, and whilst
moving to git may change some of those it's not guaranteed to make a
difference.
Ron Mayer
Perhaps it'd be a nice compromise if the Ruby project
endorsed both an official Git and Bzr clone of the
svn repository; and see which one (if any) get a
critical mass of users.
It looks like there's already one (or two, if you
count the rubyspec one) officialish git clones.
Would you care to set up a Bzr one?
mathew wrote:
> OK, so now explain why Git, and why none of the many other SCMs.
> For example, bzr has a much simpler to understand interface than Git,
That's certainly a matter of opinion.
> and unlike Git it has a proper Windows version.
I was under the impression that the windows git fork is coming
along pretty well now.
> So, why not bzr?
One factor might be whether the software has a critical mass of
users -- both to make sure the software stays around and to have
a good chance community members are familiar with the software.
Personally I like Darcs best; but wouldn't recommend it
for Ruby simply because it's quite obscure compared to
Git (used by Linux, Gnome, Perl, Rails, X.org) or
Mercurial (Mozilla, Solaris, Java).
Who uses bzr? According to Wikipedia, Gnome's java
bindings (while Gnome itself uses git), Squid, MySQL,
and Mailman. That's nice, but still well short of Git
and Mercurial.
IMHO the fact that there's a decent overlap between
rails and ruby users, it'd be nice to use the same one
they use.
However it looks like core wants to stick with SVN for now
so git and bzr users will rely on conversions for a while
at least.
Apparently there's a recommended git-svn conversion for git
users at git://github.com/shyouhei/ruby.git and another one
at http://github.com/rubyspec/matzruby/tree/master .
Perhaps you could set up similar for bzr?
I think it'd be great if one of those links could be put at
http://www.ruby-lang.org/en/downloads/
so other people don't waste their efforts running
such conversions themselves.
Ron Mayer
> For various reasons, we cannot move to git at once, so as a small
> step, use <git://github.com/shyouhei/ruby.git>. See
Could such a link be put on
http://www.ruby-lang.org/en/downloads/
I wouldn't have found it if it weren't for this email discussion,
and it could save quite a bit of time of other people doing their
own git-svn conversions.
> http://wiki.github.com/shyouhei/ruby/committerhowto
> http://wiki.github.com/shyouhei/ruby/noncommitterhowto
cool!
James Edward Gray II
> Yukihiro Matsumoto wrote:
>> For various reasons, we cannot move to git at once, so as a small
>> step, use <git://github.com/shyouhei/ruby.git>. See
>
> Could such a link be put on
> http://www.ruby-lang.org/en/downloads/
I didn't mention it on:
http://www.ruby-lang.org/en/community/ruby-core/
That seems like a better place for it, to me.
James Edward Gray II
Jim Weirich
Eric suggested I blog this in case of wider interest. So, if you are
interested in using p4merge (or perhaps other merge tools) with git,
you can see http://onestepback.org/index.cgi/Tech/Git/UsingP4MergeWithGit.red
Rick DeNatale
Mayer<rm_r...@cheapcomplexdevices.com> wrote:
> mathew wrote:
>> OK, so now explain why Git, and why none of the many other SCMs.
>> For example, bzr has a much simpler to understand interface than Git,
>> So, why not bzr?
>
> One factor might be whether the software has a critical mass of
> users -- both to make sure the software stays around and to have
> a good chance community members are familiar with the software.
>
...
> Git (used by Linux, Gnome, Perl, Rails, X.org) or
And LOTs of open-source ruby projects
Many ruby projects formerly on rubyforge or other self hosted 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.
Rubyforge has provided git as an alternative to svn for some time
now. In the case of my RiCal gem, I have got github and Rubyforge
repositories containing it.
Rick DeNatale
> Eric suggested I blog this in case of wider interest. So, if you are
> interested in using p4merge (or perhaps other merge tools) with git, you can
> see http://onestepback.org/index.cgi/Tech/Git/UsingP4MergeWithGit.red.
Nice. I'll have to take that for a test drive.
What was the other redeeming aspect?
Run Paint Run Run
It would be a real shame if after all this discussion and enthusiasm we just maintained the status quo.
A possible compromise is to incrementally move to Git by splitting the stdlib into one Git repository per library. They could either be periodically merged back into SVN or, ideally, distributed as gems. This would:
* Begin the process of opening up Ruby development by bringing these libraries to the community.
* Encourage new maintainers by establishing a sense of ownership for libraries. This responsibility could be predicated on the creation of a full test suite and documentation.
* Drastically reduce the workload of the core maintainers by freeing them from many bug reports and maintenance headaches.
* Significantly lower the barrier to entry for would-be contributors.
* Reduce the number of people who need SVN access, thus benefiting security.
* Enable the core developers to retain current working practices.
* Free up resources to focus on how the stdlib should change for Ruby 2.
* Leave Ruby leaner.
This wouldn't need to be an all-or-nothing move. Libraries with active maintainers could remain in SVN at their discretion. Nor would it wrest anybody of control. Core developers would have commit access to each component and full control over what gets merged/bundled before a release. They would also exercise control over significant changes to the libraries, should they wish.
This thread shows that their is significant interest in making Ruby's development distributed and open. The Unmaintained Code thread shows that there are volunteer maintainers for want of asking, and that was without any publicity outside of ruby-core. RubyGems, Rake, and MiniTest show the utility of this approach.
There's passion here. Feed it.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2033
----------------------------------------
http://redmine.ruby-lang.org
Ryan Davis
On Sep 5, 2009, at 17:59 , Run Paint Run Run wrote:
> RubyGems, Rake, and MiniTest show the utility of this approach.
I'm really not comfortable with you using one of my projects as
justification for your idea. Especially since I'm completely against
your idea.
I should also point out that rubygems is on subversion and minitest is
on *gasp* perforce, so they should be considered counterexamples.
Rake is, I believe, officially on git... and yet, it seems to have had
far fewer releases (barring compatibility fix releases) and accepts
far fewer contributions than minitest or rubygems.
> There's passion here. Feed it.
We're WAY beyond passion. I don't think it should be fed.
There is nothing stopping you or anyone else from using git to work on
ruby. Indeed, it has been pointed out several times in this thread,
yet that seems to be ignored continuously. There is no reason for you
or anyone else to be pushing git on others.
This zealotry is tiring.
zealot |ˈzelət|
noun
a person who is fanatical and uncompromising in pursuit of their
religious, political, or other ideals.
• ( Zealot) historical a member of an ancient Jewish sect aiming at a
world Jewish theocracy and resisting the Romans until ad 70.
DERIVATIVES
zealotry |-ətrē| noun
ORIGIN mid 16th cent. (in the sense [member of an ancient Jewish
sect] ): viaecclesiastical Latin from Greek zēlōtēs, from zēloun
‘be jealous,’ from zēlos (seezeal ).
THE RIGHT WORD
An enthusiast displays an intense and eager interest in something (: a
sky-diving enthusiast).
A fanatic is not only intense and eager but possibly irrational in his
or her enthusiasm; fanatic suggests extreme devotion and a willingness
to go to any length to maintain or carry out one's beliefs (: a fly-
fishing fanatic who hired a helicopter to reach his favorite stream).
A zealot exhibits not only extreme devotion but vehement activity in
support of a cause or goal (: a feminist zealot who spent most of her
time campaigning for women's rights).
An extremist is a supporter of extreme doctrines or practices,
particularly in a political context (: a paramilitary extremist who
anticipated the overthrow of the government).
But it is the bigot who causes the most trouble, exhibiting obstinate
and often blind devotion to his or her beliefs and opinions. In
contrast to fanatic and zealot, the term bigot implies intolerance and
contempt for those who do not agree (: a bigot who could not accept
his daughter's decision to marry outside her religion).
Jim Weirich
On Sep 5, 2009, at 10:13 PM, Ryan Davis wrote:
> I should also point out that rubygems is on subversion and minitest
> is on *gasp* perforce, so they should be considered counterexamples.
>
> Rake is, I believe, officially on git... and yet, it seems to have
> had far fewer releases (barring compatibility fix releases) and
> accepts far fewer contributions than minitest or rubygems.
Yes, rake is on git. And since the move we have had more
contributions from more diverse audience than before the switch. I
find it far easier to review potential patches now that we are using
git.
I can't compare to any of your projects, but the lack of releases has
more to do with my available free time than reflecting on the switch
to git.
Florian Gilcher
> It would be a real shame if after all this discussion and enthusiasm we just maintained the status quo.
Sorry, but long discussions usually show that the proposal didn't find widespread acceptance. I think that it is far more important that this move not be taken lightly.
> A possible compromise is to incrementally move to Git by splitting the stdlib into one Git repository
> per library. They could either be periodically merged back into SVN or, ideally, distributed as gems.
> [...]
Actually, SVN is quite good to manage a standard lib in the style that is present. You can checkout subtrees, etc. All those things are not possible with GIT.
You are proposing a significant change in the way ruby is organized. Someone would have to check for changes in other repositories regularly. Where are those repositories hosted? What if one of them is down? Do rules that apply to ruby trunk/master also apply to their trunk/master? Also, the number of people with indirect, possibly unchecked access to stdlib libraries could rise.
I don't know whether you followed the GHC 'move' to GIT. (Long story short: it didn't really happen) I wouldn't want that in Ruby.
How to you merge history if anyone working on stdlib uses a different VCS?
> This wouldn't need to be an all-or-nothing move. Libraries with active maintainers could remain in SVN
> at their discretion. Nor would it wrest anybody of control.
This would mean splitting stdlib into (at least) two kinds of libraries that have to be handled differently.
> This thread shows that their is significant interest in making Ruby's development distributed and open.
It also shows that there is interest in keeping it under control.
> There's passion here. Feed it.
I don't like passion as a technical argument. I for example dislike git. It is a great implementation of a distributed filesystem with no good client, mediocre man pages, arcane behaviour (fast-forwarding branches for example) and far too many ways to shoot yourself in the foot. Feed it.
Actually, I really like the way development on darcs works: Patches are send to a mailing list, reviewed, and potentially merged. There are not a lot of people that are actually allowed to pull patches into main. So the repos is really closed down, but all patches are offical (and can be pulled by anyone).
mathew
> Many ruby projects formerly on rubyforge or other self hosted 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.
> Rubyforge has provided git as an alternative to svn for some time
> now. In 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
<rm_r...@cheapcomplexdevices.com> wrote:
> Who uses bzr? According 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 sources.
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 http://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. They understand why distributed revision control is so
awesome, and they attribute this awesomeness to Arch (and now GIT)
rather than realising that it’s an inherent property of any such
system. The learning curve is pretty damned steep, so there’s 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."
mathew
Eric Wong
> Actually, I really like the way development on darcs works: Patches
> are send to a mailing list, reviewed, and potentially merged. There
> are not a lot of people that are actually allowed to pull patches into
> main. So the repos is really closed down, but all patches are offical
> (and can be pulled by anyone).
That's exactly how development on git itself and the Linux kernel works.
--
Eric Wong
Michal Suchanek
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
Brian Mitchell
> 2009/9/6 mathew <me...@pobox.com>:
I was originally going to stay silent on this but I guess it wouldn't
hurt to voice my thoughts a little since I think this thread has lost
its clarity.
First, I think it is primarily up to the core developers on what tools
they use. As it has been pointed out, there is nothing keeping people
from contributing. If it is harder than it could be, then lets work on
fixing that. I don't think we need to draw the conclusion that
changing the core's SCM is the only way to solve these problems. If
I'm wrong, then lets work that out when its shown to be so. I have no
doubt that this community can be more creative in solving this
conflict than we give ourselves credit for.
Second, I do think we are presupposing much more on the suitability of
all of these tool than is necessary. To remedy this, we should
encourage experimentation. If that means that official mirrors should
be designated and infrastructure put in place, great! We should be
able to try new things without resorting to chaos. Having official
blessings and likewise, the publication or labeling of such things
existing will help avoid confusion. I've been unsure which git repo to
base my work from but from this thread it seems we might have one,
lets make it clear and help stop guessing games.
Finally, for those who'd like to get more people using certain tools,
it would be more helpful if we were to set these things up and
document things. Help and encourage your fellow developers to try
things. If it doesn't work for them, don't insist they are wrong.
I think it will be much more likely that people will be happy to
switch later if they find things to be ready, but again, it isn't the
community's choice. I think the core team knows what the preferences
are but even better will be observation of how these experiments work
out.
Thank you / ありがとうございます,
Brian.
Ron Mayer
That's not true, is it?
http://www.opensolaris.org/os/community/tools/scm/
"The opensolaris.org website supports two SCM solutions:
* Mercurial (hg) is the default. It was chosen for a
distributed SCM (DSCM) solution ...
* Subversion (SVN) is provided for exceptions. It was
chosen for a centralized solution..."
You can read their analysis of bzr here. It fared OK, but
they like Mercurial over it:
http://www.opensolaris.org/os/community/tools/scm/bzr-eval/
> 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).
+1. As for me, I'm happy using Git or Darcs or Mercurial; but can
tolerate the rest mostly by using tools like git to convert the others to
one of those :-)
ISTM the tools to convert to convert from one to another are getting
better. Now that I know about the official-ish conversion from svn
to git; I'm pretty happy. If enough people use it, it may one day become
the default. Perhaps it'd be nice if there were maintained bzr and/or
mercurial conversions too - if enough people want to use those.
> 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. They understand why distributed revision control is so
> awesome, and they attribute this awesomeness to Arch (and now GIT)
> rather than realising that it’s an inherent property of any such
> system. The learning curve is pretty damned steep, so there’s 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."
I don't think that's true - or at least it wasn't early on.
I bet most early GIT users were Bitkeeper and/or TeamWare users (both
proprietary distributed systems) and appreciated the extra
flexibility offered by GIT (for example, the stash and the index)
even though there's some learning curve for those who want to access
the extra flexibility. IMHO if you don't want to use the extra
features in GIT, the learning curve's quite gentle.
Nobuyoshi Nakada
At Mon, 7 Sep 2009 01:24:30 +0900,
mathew wrote in [ruby-core:25439]:
> loss of metadata and history if you rename a file,
This is not true, try `git log --follow'.
> visible SHA-1 hashes as revision names,
I hate this too.
--
Nobu Nakada
Shyouhei Urabe
Status changed from Open to Closed
Closing this issue because it's aged, out of date. Please open another one if you still need it.