Forum: Ruby-core Happy new year and... moving Ruby development to Git?

Happy new year everyone.
A question to Matz and all the Ruby contributors: are there any real
reasons to use Subversion and not Git for Ruby development?

I don't want to turn this into "centralized VCSs suck, distributed
VCSs rock" kind of discussion, but seriously: many large open source
projects moved to DVCS in last year or two (as large as OpenJDK,
OpenSolaris, MySQL, Zope, Firefox, Perl 5), and some of them (Ruby on
Rails is the most obvious example) have seen dramatically increased
number of contributions from the outside of the "core team", because
with DVCS, experimentation of all sorts is so much easier. Others that
did not are considering a move and in process of evaluation of
different options: FreeBSD and (again, I may be totally wrong) Emacs
(leaning towards Bazaar?).

A number of well known projects in the Ruby space use Git now: from
Rails and Merb to RSpec to DataMapper to Rubinius to even Rake I
believe (I may be wrong here). RubySpec uses Git, by the way.

Recently series of patches by Brent Roman reminded me again how
different the process of evaluating of different forks/experiments/
patches with Subversion is. Yeah, download 7 files, apply them in
order, with diff-mode in Emacs helps. I mean, it is not *really* hard
but it wasn't a no brainer either. Pulling from a person who came up
with something I may be interested in using Git (and GitHub obviously)
is so much easier, that you start feeling the difference once you get
used to DVCS process.

Of course, there is git-svn and hg-svn and bzr-svn of all sorts, and
they all work fine, but people seems to use what official repository
uses. Probably because they don't want to bother converting their
patches, or maybe because converters like git-svn look fragile to
them, it does not matter much.

What do you think? Is there a way for community to help with this
transition, if you decide it makes sense?

MK

On Jan 1, 2009, at 6:42 AM, Michael Klishin wrote:

> A question to Matz and all the Ruby contributors: are there any real  
> reasons to use Subversion and not Git for Ruby development?

Subversion is nice for the central repository and the wider support.
I think that makes it the ideal pick for Ruby's main repository.

Luckily, that doesn't hinder us git fans.  You can just pull the
central git repository down with git-svn (which ships with git) and
you get all the advantages of git locally.

It's the best of both worlds.

James Edward Gray II

On Thu, Jan 1, 2009 at 11:22 AM, James Gray <james@grayproductions.net> 
wrote:
> advantages of git locally.
>
> It's the best of both worlds.

I wonder if there would be in the Ruby community any interest in
setting up an "official git mirror" of the subversion repository on
GitHub.  (Similar to the official mirror of Perl:
http://github.com/blog/276-perl-mirror-on-github.
)  Thus anyone who takes an interest in playing with the ruby source
has a well-known point to fork from.  Considering the ease of directly
using git-svn straight from the source, I do somewhat the usefulness
of the suggestion.

But, it may be useful in the case that multiple GitHub users
independently use git-svn; now there may be some confusion on the part
of "casual hackers": 'Hmm... which one of these 7 ruby repositories
(returned in a GitHub search) is the best/most reliable/most
trust-worthy/etc.'

brabuhr@gmail.com writes:
 > I wonder if there would be in the Ruby community any interest in
 > setting up an "official git mirror" of the subversion repository on
 > GitHub.

Vladimir Sizikov set up a MRI repository for the Rubyspec project at
http://github.com/rubyspec/matzruby/. It contains branches for all the
current branches in the SVN repository so don't be afraid if you see it 
empty.

 > 'Hmm... which one of these 7 ruby repositories
 > (returned in a GitHub search) is the best/most reliable/most
 > trust-worthy/etc.'

We've been using it for 5-6 months now with no issues, so take a look 
and let
us know if you find it useful.

brabuhr@gmail.com wrote:
> independently use git-svn; now there may be some confusion on the part
> of "casual hackers": 'Hmm... which one of these 7 ruby repositories
> (returned in a GitHub search) is the best/most reliable/most
> trust-worthy/etc.'

We have a read-only Git mirror set up at git://git.phusion.nl/ruby.git
This mirror is updated automatically 3 times a day.

Quoting Michael Klishin <michael.s.klishin@gmail.com>:

> with DVCS, experimentation of all sorts is so much easier. Others that
> forks/experiments/patches with Subversion is. Yeah, download 7 files,
> it does not matter much.
>
> What do you think? Is there a way for community to help with this
> transition, if you decide it makes sense?
>
> MK

I'm really not an expert on revision control systems, but just off the
top of my head it seems like there are just too many of them, and
there's bound to be some kind of "market shakeout", leaving a "Big
Three". Right now, I'd guess that those three would be Subversion, Git
and one other. I really don't know whether CVS will survive -- there
are still quite a few projects using it, but I can't actually name
one. And I don't know if Mercurial, Darcs, and Bzr have enough
momentum to be worth thinking about.

My experiences with Git for my own small projects have been, shall we
say, less than satisfactory after about six months, compared with
about two years of Subversion and about ten years using ClearCase at
my day job. But that's just a learning curve issue, I think. Clearly
to be an open-source hacker, one *must* be Git-savvy, and all of my
new projects are going to Github.

One other question for the community, though -- is there room for
*another* version control system specific to the Ruby community,
tailored to our unique needs?

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P), WOM

I've never met a happy clam. In fact, most of them were pretty steamed.

On 01.01.2009, at 20:50, brabuhr@gmail.com wrote:

> Similar to the official mirror of Perl:
> http://github.com/blog/276-perl-mirror-on-github.
>


JFYI, Perl 5.x has moved to Git in last December:
http://use.perl.org/articles/08/12/22/0830205.shtml

MK

On 01.01.2009, at 21:00, Federico Builes wrote:

> Vladimir Sizikov set up a MRI repository for the Rubyspec project at
> http://github.com/rubyspec/matzruby/. It contains branches for all the
> current branches in the SVN repository so don't be afraid if you see  
> it empty.


And it's great and useful. The question is, if a lot of people in the
community do use Git extensively already, and at least with Rails and
Merb it proven itself being worth the switch because aspiring
contributors *do* find it easier to contribute, what really holds Ruby
core team from making this move? I just want to understand.

At least in the part of the Ruby community that works on web stuff, it
is way easier to find a person who uses and likes Git than a person
who does not.
And I am pretty confident doing such a bold statement. What I
personally found out is, if someone pokes you with a question like
"hey did you see this library X that popped up recently?" you are
likely not going to be wrong, if you search it on the GitHub first,
not google.

I cannot think of an interesting project in the Ruby space that
appeared in 2008 and does not use Git. Either I have a sick metric of
whether project is interesting (it sure may be so), or Git already
reigns supreme in the Ruby universe, and I am sure there is a reason
to it, and MRI development can benefit from the switch.

MK

On 02.01.2009, at 1:36, Michael Klishin wrote:

> I cannot think of an interesting project in the Ruby space that  
> appeared in 2008 and does not use Git.


Ok, other than Ryan Davis' RubyParser and Flay, but I believe Ryan
uses Perforce for all his projects anyway. I just don't want it sound
like "Flay and RubyParser are not interesting" ;)

MK

On 01.01.2009, at 19:22, James Gray wrote:

> You can just pull the central git repository down with git-svn  
> (which ships with git) and you get all the advantages of git locally.


True, but I still think there is a barrier about "what is official".
The alternative I can see is to have a Subversion mirror of git
repository's long living branches. What about this? Still best of both
worlds, but I am sure it will faster the experimentation Dave Thomas
has been talking about at RubyConf 2008.

MK

On Jan 1, 2009, at 7:42 AM, Michael Klishin wrote:

> A number of well known projects in the Ruby space use Git now: from  
> Rails and Merb to RSpec to DataMapper to Rubinius to even Rake I  
> believe (I may be wrong here). RubySpec uses Git, by the way.


Rake switched to git during the Ruby Hoedown (while I was sitting
about 5 seats down from defunkt).  I have seen the number of
contributions to Rake skyrocket after the switch.

And using git makes the evaluation of those third party contributions
much easier to check out.  You create a branch and pull in the patches
(which is really easy if the patches come form another git repo).  If
they look good, that temp branch gets merged with the main.  If I
don't like something with the patch, I just delete the branch and all
is good.

It was an uncomfortable two weeks while I got used to the "git
way" (which is quite different from the "svn way").  But once past the
initial learning curve, I'm very happy to be using git and would
choose git over svn for any new project where given the choice.

Quoting Michael Klishin <michael.s.klishin@gmail.com>:

> And it's great and useful. The question is, if a lot of people in the
> community do use Git extensively already, and at least with Rails and
> Merb it proven itself being worth the switch because aspiring
> contributors *do* find it easier to contribute, what really holds Ruby
> core team from making this move? I just want to understand.

You'd have to ask them that. Given the sheer number of Ruby core
developers working on MRI and KRI in Subversion at the moment, I think
there would need to be a *compelling* reason to switch.

> I cannot think of an interesting project in the Ruby space that
> appeared in 2008 and does not use Git. Either I have a sick metric of
> whether project is interesting (it sure may be so), or Git already
> reigns supreme in the Ruby universe, and I am sure there is a reason to
> it, and MRI development can benefit from the switch.

Well, all of my *new* projects are being done in Git (and on Github!),
but I'm not sure it's worth the effort to migrate the ones in
Subversion on RubyForge. But the main reason I switched is that my
projects tend to so much non-Ruby stuff (R, Perl, PostgreSQL,
LyX/LaTeX, bash, and Linux itself) that I don't really consider myself
a "Ruby developer" in a very pure sense. And I wanted to learn Git.
And Github is built on / by EngineYard. And Git was invented by Linus
Torvalds. :)

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P), WOM

I've never met a happy clam. In fact, most of them were pretty steamed.

Michael Klishin writes:
 >
 > On 01.01.2009, at 21:00, Federico Builes wrote:
 >
 > > Vladimir Sizikov set up a MRI repository for the Rubyspec project 
at
 > > http://github.com/rubyspec/matzruby/. It contains branches for all 
the
 > > current branches in the SVN repository so don't be afraid if you 
see
 > > it empty.
 >
 > And it's great and useful. The question is, if a lot of people in the
 > community do use Git extensively already, and at least with Rails and
 > Merb it proven itself being worth the switch because aspiring
 > contributors *do* find it easier to contribute, what really holds 
Ruby
 > core team from making this move? I just want to understand.

Just for the record, I totally agree with you on this. I think that the
"open" nature of Git gives people the impression that they can 
experiment and
that a repository is there for you to play, to play, to improve, not to 
read
the code and keep it as a sacred vault.

With regards to the centralized nature of Subversion (I think James Gray
brought it up), remember we can have a central copy (the original 
repository)
who'd be controlled by the current ruby-core and then people can start
forking from there and we'd have all the benefits of both SVN and Git.

Hi,

In message "Re: [ruby-core:21053] Re: Happy new year and... moving Ruby 
development to Git?"
    on Fri, 2 Jan 2009 08:49:49 +0900, znmeb@cesmail.net writes:

|You'd have to ask them that. Given the sheer number of Ruby core  
|developers working on MRI and KRI in Subversion at the moment, I think  
|there would need to be a *compelling* reason to switch.

We already set up quite a few tools around Subversion, so we need to
port them to support git.  Yugui (who uses git herself) is in charge
of the issue.  You can contact (and offer help to) her.

              matz.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 2, 2009, at 2:32 PM, Yukihiro Matsumoto wrote:

> Hi,
>
> We already set up quite a few tools around Subversion, so we need to
> port them to support git.  Yugui (who uses git herself) is in charge
> of the issue.  You can contact (and offer help to) her.
>
>               matz.
>

In addition to that, I want to mention that Windows support of GIT is
still sub-standard. I'm using the cygwin-build on a daily basis[1] and
can
speak out of personal experience.
Configuring everything beyond the most simple things gets arcane and
hard.
If "ease of use" is the argument, it doesn't hold true on win.

In the light of this, I would suggest an "official" mirror.

Regards,
Florian Gilcher

[1]: Yes, I also tried the msysgit, which is even worse.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkleMH8ACgkQyLKU2FMxSOIxeQCghIO4rGSxpuVcJuAdIqVbqi57
RoIAoKt8ed3dRI2E3P22suZt5nIBejLF
=kGji
-----END PGP SIGNATURE-----

On Fri, Jan 2, 2009 at 12:18 PM, Florian Gilcher <flo@andersground.net> 
wrote:
>> of the issue.  You can contact (and offer help to) her.
> In the light of this, I would suggest an "official" mirror.
>

I would disagree on that topic.

I use on a daily basis msysGit (1.5.5 and 1.6.0) without issues. Uses
notepad as editor or bundled vim too.

Also, for the record, configured to use ssh and plink (PuTTY) and both
work without issues.

One important thing: disable autocrlf (false) since is the worse
default msysGit developers could have introduced.

We can fork this discussion to ruby-talk if you need help. I use it
for several open source projects and my compnay projects too without
issues (and sharing the environment with Mac and Linux users).

As for the Ruby on Git official support will be really really helpful.
More if GitHub is used as official mirror or hosting, since they are
building around it a lot of tools that ease contribution (namely: fork
queue).

> Regards,
> Florian Gilcher
>
> [1]: Yes, I also tried the msysgit, which is even worse.

Again: which part is worse? It lacks things like git-serve, but I can
live without the need to "host" git repositories in my own computer.

My opinion:

Git is currently the flavor of the month. It's getting adopted for 
reasons
which amount to fashion rather than legitimate technical merit. It has a
horrible user interface, and a fundamentally broken model.

[
http://blogs.gnome.org/newren/2007/12/08/limbo-why-users-are-more-error-prone-with-git-than-other-vcses/]

I use bazaar, which has all the decentralized goodness of git, but with 
an
easy UI and proper multi-platform support. Plus, it doesn't need 
anything
special running on the server, so I can host a repository anywhere.


mathew

On Fri, Jan 2, 2009 at 2:55 PM, mathew <meta@pobox.com> wrote:
> I use bazaar, which has all the decentralized goodness of git, but with an
> easy UI and proper multi-platform support. Plus, it doesn't need anything
> special running on the server, so I can host a repository anywhere.

I'm playing with both git and hg for some side projects; so far, I'm
preferring hg.

-austin

mathew wrote:
> My opinion:
> 
> Git is currently the flavor of the month. It's getting adopted for 
> reasons which amount to fashion rather than legitimate technical merit. 
> It has a horrible user interface, and a fundamentally broken model.

I'm not as negative about git, since for my limited scm-fu hg and git
are just svn with a local repo, but I definitely agree with the "flavor"
statement. Between minor versions git has changed command-line options,
added and removed commands, and introduced bugs. Don't get me wrong, I
like it, but I don't like it enough to go through the pain of moving an
existing large project to it without a very good reason. Add to that
what Matz said about wider tool support and it's really not compelling.

JRuby will probably be making a move to Mercurial soon, and our reason
for doing so is that we're moving to the JRuby-on-Rails-based kenai.com
project-hosting site Sun built over the past couple years. If we're
moving there, we'll need to migrate SCM anyway, so we might as well
migrate to DSCM. Hg is the current likely candidate simply because it's
well supported by kenai and by the tools we use (namely, NetBeans).

An official up-to-the-hour git mirror would probably be the nicest way
to support git for ruby-core right now, and I think github even supports
git-svn clones in a smart way now. I run off a copy of Vladimir's
git-svn mirror myself, and I use git-svn for JRuby work, so that would
be my recommendation, at least until git support is rock solid and
relatively consistent across all the usual platforms and tools.

- Charlie

My two cents:

On Fri, Jan 2, 2009 at 5:55 PM, mathew <meta@pobox.com> wrote:
> Git is currently the flavor of the month. It's getting adopted for reasons
> which amount to fashion rather than legitimate technical merit. It has a
> horrible user interface, and a fundamentally broken model.

I'm a CVS user who was not seduced enough to migrate my projects to
Subversion, but now I'm migrating to Git, because I really liked its
features. I cannot agree with you about the technical merits, user
interface etc, but agree with the "fashion" thing.
Please forget the "Rails loves Git neons" for a moment, remember that
Git is used to keep projects like the Linux kernel and take a look
again on it. I think it would be cool (ops) to have the Ruby source
code on a git repository.

Regards,

On Jan 1, 2009, at 04:42 AM, Michael Klishin wrote:
> A question to Matz and all the Ruby contributors: are there any real  
> reasons to use Subversion and not Git for Ruby development?

My experience working on Rubinius lead me to believe that git wants to
stab me in the back at every turn then laugh at me in foreign
languages while I try to figure out just what it did to my
repository.  (I'm sure I'm being insulted but I'm not sure how strong
an insult git is using.)

> Others that did not are considering a move and in process of  
> evaluation of different options: FreeBSD

FreeBSD just completed a move to subversion after many months of work,
but primary development has been happening in perforce for a couple
years now.  Switching to a DVCS was not likely at any time soon (next
few years) according to mail I read.  FreeBSD doesn't get developed
the way Linux does, Rubinius didn't, and I don't think Ruby does either.

git is the most user-unfriendly a piece of software I've had the
misfortune of using.  While subversion has until recently lacked the
ability to easily merge separate branches, at least it has been
reasonably user friendly when I'm trying to pull in code from the main
repository.

Maybe in a couple years git will be friendly enough for me to use.

At 6:06 AM +0900 1/3/09, Charles Oliver Nutter wrote:
>"flavor" statement. Between minor versions git has changed 
>as well migrate to DSCM. Hg is the current likely candidate simply 
>because it's well supported by kenai and by the tools we use 
>(namely, NetBeans).
>
>An official up-to-the-hour git mirror would probably be the nicest 
>way to support git for ruby-core right now, and I think github even 
>supports git-svn clones in a smart way now. I run off a copy of 
>Vladimir's git-svn mirror myself, and I use git-svn for JRuby work, 
>so that would be my recommendation, at least until git support is 
>rock solid and relatively consistent across all the usual platforms 
>and tools.

I have enjoyed learning about and using git. I find it very fast.

I can't imagine not working with a complete local repository anymore.
I have a git clone of the ruby and jruby repositories -- the ability
for me to easily use git bisect to find the changeset that caused a
regression makes it much easier to either create a good bug report or
find and fix the problem myself.

The changeset visualization I used to do with trac or fisheye is so
much faster locally in various git visualization tools (I use GitX on
the Mac).

I almost always use git-svn to clone code in subversion repositories
instead of svn. Being able to trivially follow changesets locally
makes it much easier to understand other people's code.

I use JRuby and I've been playing with jgit, the java implementation
of git, in making some applications in which distributed content is
part of the functionality. The fact that I can use the DSCM I use
most often for source code for application functionality is a big
plus.

There is a good Ruby gem that works with the C version of git called 
grit.

Scott Chacon's free screencasts of git are great.

Git integration with textmate is good and integration with eclipse
and netbeans is getting better.

The pattern where I make a branch, end up making a bunch of commits
that fix a problem or add a feature -- and then when the change is
working and tested combine the commits together to make it available
as a patch or push it to a public repo for others to try out works
well.

I think the fact that it appears to be much easier to use Ruby to
interact with git than with other DSCMs like hg or bazzar a big plus
and likely to lead to more interesting new applications.

Eric Hodel wrote:
> git is the most user-unfriendly a piece of software I've had the 
> misfortune of using.  While subversion has until recently lacked the 
> ability to easily merge separate branches, at least it has been 
> reasonably user friendly when I'm trying to pull in code from the main 
> repository.

I tend to feel about git the same way I feel about Linux. They're both
fast, fully-functional tools, but often rather blunt and imposing...too
"opinionated" for my taste, perhaps. They both are very scriptable,
extendable, infinitely tweakable...but there's all these wires and shit
sticking out all over the place, wires I'm worried I'll touch and get a
nasty shock, or accidentally short out and blow the whole thing apart.
Maybe it's a learning curve thing, but in both cases I feel like things
are done differently for difference's sake, and unless you're in the
elite club that already thinks like Linus, you live in pain.

The local repo is obviously awesome, but after all I have my five
commands I use in git, and I rarely stray. And every time one of those
wires shocks me, I find myself less and less enamored with git.

- Charlie

On Sat, Jan 3, 2009 at 00:34, Eric Hodel <drbrain@segment7.net> wrote:

> git is the most user-unfriendly a piece of software I've had the misfortune
> of using.

Enough with the comments without actual substance already.  This is
getting us nowhere.

Do some actual research, or take part of some of the research that has
already been done by people who actually know what they're talking
about, for example, http://whygitisbetterthanx.com/#easy-to-learn.

I don't really care what SCM the MRI developers use and I don't
understand why everyone seems to think that they are entitled to an
opinion about it, but it's time to get over this meaningless and
repeated discussion.  (Check, for example,
http://listlibrary.net/ruby-core/2006/11/0066A0F8, in which I go off
the deep end and, ironically, you, Eric, mail me an off-list "thank
you" (or should I perhaps call it a ""thank you""?).  I guess the
Haskellesque joke in this is that even history is recursive.)

So can we please have a long discussion about how people like me
shouldn't try to stifle discussions on mailing lists instead?

Or at least get our facts straight and present valid cases for the
SCMs that we prefer?

On 02.01.2009, at 22:55, mathew wrote:

> I use bazaar, which has all the decentralized goodness of git, but  
> with an easy UI and proper multi-platform support. Plus, it doesn't  
> need anything special running on the server, so I can host a  
> repository anywhere.


Please don't turn it into "bzr vs git" or "svn vs git" flame war.
Bazaar is great, and so is Mercurial, and Darcs. But significant part
of the Ruby community for whatever reason picked git, so moving to git
was the question.

MK

I think being a fashion is good enough reason to adopt Git over another
DVCS. The goal of switching to a new VCS is, first and foremost, to
boost development. Using a fashionable/popular VCS should lower the
barrier to entry for contributors.

Hello,

On Fri, Jan 2, 2009 at 2:32 PM, Yukihiro Matsumoto <matz@ruby-lang.org> 
wrote:
>
> We already set up quite a few tools around Subversion, so we need to
> port them to support git.  Yugui (who uses git herself) is in charge
> of the issue.  You can contact (and offer help to) her.

I don't know how much free time I will have in the following days, but
I'm willing to give a hand in helping porting the scm toolchain to
git.

On 03.01.2009, at 4:25, Nikolai Weibull wrote:

> Or at least get our facts straight and present valid cases for the
> SCMs that we prefer?


I use Git and Mercurial every day: Git for work and open source
projects, and Mercurial for all my personal
documents, emacs.d, tools, configuration files. I happened to use
Darcs for about a month. Now here is my perspective.

First, don't trust me when I say something about Windows support below,,
simply because I do not use Windows. I can't say if msysGit still has
significant problems or not,
I'd trust Luis Lavena on this.

Another note: I am 10000% ok with using Hg instead of Subversion
or Bzr instead of Subversion, but because this thread moved to "git vs
hg vs bzr vs darcs vs git-is-for-nerds-well-not-really vs freebsd-is-
not-linux-you-mofos,
I just want to waste some time and tell my personal experience with
them.

if you are really interested in a summary, read Learning curve section
and the last section. Others
are mostly noise.


Learning curve vs. Feature richness:

Git has learning curve, but once you get it, it *is* as simple to use
as any other VCS. But
when you hit the wall and you need an "advanced" feature
(from "what commit introduced this issue" to "what subcomponents of
the project change
more often and thus need more attention"), it literally can do
wonderful things.

Mercurial is easier to learn, and it feels more like home for
Subversion users. Even commands are
pretty much the same, though bringing in some new concepts and trying
to tie them to existing
vocabulary of the SVN world leads to more confusion in certain cases
(ex.: update/merge).
It has pretty much any feature Git has, but sometimes you have to go
and install plugins to get them.
And some plugins are plain stupid, hg log does not use pager by
default, but a pager plugin forces
*every* single command to go through a pager, which is not really what
you want. But in general,
I have no plans of moving my personal stuff from Mercurial.

Won't pretend to know the Bazaar situation, but I think it is on par
with Mercurial, and is quite
friendly, and has everything you possibly may need either built in or
as plugins.

Darcs is quite friendly and interactive, which looks very nice at
first, but later when you try to
merge with the rest of the team, and screaw up with all this "pick a
hunk" interactive awesomeness, you either
try to avoid all this interactive stuff, or it brings as much
irritation as pleasure initially. So
Darcs is the most nerdy, not Git.


Branching and merging:

Git stores all the local branches in a single working copy, and you
can switch between them,
delete them, rename them, etc in one physical directory on your HD.
I always preferred this approach to say what Mercurial has, though it
is not crucial.
Since branching/merging is essential part of the process Git was
created for, it has
all the features in the world related to branching, and more: fetch/
pull to confuse people who
barely know how "push" is different from "commit"; rebase so you have
a way to screaw up
even if you think of yourself as of advanced user; and other fun
things ;)
But 95% of the time you can do the job without them, and Git brancing/
merging can be distilled to like 3-4
commands you can easily explain in a contributors guide.


Darcs has idea of "every branch is a separate directory" (or used to
have it). I can't
say it is a problem but you will end up having 3-5 copies of the
pretty much the same
code, and if you repository is 600 megs, not all movies you try to
download from iTunes may
fit into your HD.


Mercurial has local repository branches, but you... cannot delete them
without touching
your nose with yout foot first! There are special plugins that try to
provide this sort of
functionality, and none of them really did what Git has when I tried.
So, for long living
branches you end up having directory copies, just like with Darcs, and
like I said,
it sounds like an ugly thing to me. Again, we are sacrificing that hot
new Angelina Jolie
movie downloaded by iTunes/Miro, so maybe it is a big deal for some.

I cannot really judge bazaar here, but looks like again, it is
directory copies here
and there. Maybe this thing is some golden standard of DVCS world Git
developers had
no idea about.



Sharing of repositories:

I only mean technical aspect here, GitHub vs. the rest of the world
discussion comes
at the end of this message. All git, darcs, bzr, hg can use SSH and
HTTP to sync with
remote repositories, and have
some sort of web UI if you really need it. What else would you wnat?



Really useful features vs Crap you never use:

bisection, a *very* useful feature, is supported by each and every of
them. Stashed
commits, squashed commits (merge 100 commits as one large) and
rebases, things that
advanced users like for a real reason, are supported by every system I
think.

The rest is something 99% of the population does not use.


Performance:

I don't know why people who maintain projects even of Rails size care
so much about Git
being super fast, it should be a problem for KDE and gcc and not Ruby
libraries.

But. Git performs the best, Mercurial and Bazaar are very fast, too.
Mercurial, in fact,
is so fast I used it on a very old (5 years or so) machine and never
though that it is
written, to large extent, in a very high level language. Darcs is
probably slowest,
but not too slow anyway.

So unless MRI grows to the size of gcc, which I hope will never
happen, they all perform
reasonably well or better.



UI front ends and tools support:

A note for Emacs users: vcs-mode backends are available for at least
git/hg/bzr, and the
keymap is the same. So, you may not even notice that you have hg and
not git under the hood.
magit, gitsum and a bunch of Hg modes available for those who need it.
Win!

Vim users may chill out and stop screaming "we have it too, and
better!!!", we all know ViViVi is The Devil's Editor,
and one day the higher power will remind us of our sins, but I am sure
vim has a counter part for every
Emacs feature ;)

NetBeans has support for Hg out of the box, Eclipse has plugins I
cannot really judge... not sure how many MRI contributors
use those behemoths.

Git has like 3 or 4 standalone UI programs for OS X, a couple for
Linux and probably has no UI tools
on Windows.

Mercurial said to have a good Windows tool (TortoiseHg), but on OS X
and Linux it is a
completely different story. I never really used a UI tool on OS X, but
I know some people
who were looking for one, and what they found was miserable.

I have no idea what Bazaar has but it probably does better than Hg
since Canonical cares about less technical users.
Darcs seems to be lacking UI tools altogether.



There will be bugs:

If something goes wrong with Git, you have a very vibrant community
support, and bug fixing
process is pretty fast. Mercurial and Darcs are in Python, which
means, you even can
even try to fix the problem yourself in a reasonable amount of time.
Darcs is in Haskell,
and has the smallest community of them all, so unless you are functional
programming geek, the first time you come around a bug, it is probably
gonna be the last time you used Darcs.



Availability of Github:

Now, to the crucial part. Everything you read above simply does not
really matter.
Because GitHub is only available for Git. Hg, bzr, darcs all lack
github.
They may have launchpads, space ships and invented a way to store bits
in a bitbucket, but they lack
GitHub. And GitHub totally changes the way people work on open source,
the way it should be.

Open source is about project ecosystem and how parts (developers,
companies) of that ecosystem
interact. With GitHub you don't have to invent ways of collaboration,
tools to visualize
what you want to see, and simply poking that guy who created that cool
thing but introduced
a bug that you fixed and want to push upstream.

Bitbucket and Launchpad may be both great code silos, provide wikis,
trackers and so forth,
but they miss the crucial point: forking, pull requests and merging
should be so simple
13 y/o can do it, and GitHub gets this part right.

Seriously, what made a lot of projects in the Ruby community switch to
Git? The fact that
it is "new hotness"? Performance? The fact that Hg and bzr are in
Python? Linus Torvalds
fanatism? Marking efforts of Chris, Tom, PJ and co?
No. Ease of collaboration that is not really possible without GitHub
at this moment.

MK

On Sat, Jan 3, 2009 at 4:48 AM, Michael Klishin
<michael.s.klishin@gmail.com> wrote:
>
> I use Git and Mercurial every day: Git for work and open source projects,
> and Mercurial for all my personal
> documents, emacs.d, tools, configuration files. I happened to use Darcs for
> about a month. Now here is my perspective.

[snip]

A short note to say that I share an opinion with most of what you said
on git and mercurial. I started from mercurial on Windows (because at
the time git was everything BUT cross-platform), but when I switched
to Linux and started using git I gave up on mercurial and I must
saying that when I have to use it now I find it clumsy, limited and
irrational in some of its stuff (tags being the most obviously
ridiculously implemented thing). So I would really prefer Ruby went
the git way.

As far as cross-platformness goes, I have never used git on Windows,
but from what I read on the git ml the msys port is perfectly usable
these days, aside from the default choice of automatic conversion of
crlf which introduces more bugs than it tries to resolve. There is
also now a TortoiseGit project which I hear is (at least minimally)
functional.

My two cents, and my vote for git.

Just want to reiterate something that more people need to realize.

I'm an  Ex-diehard SVN user. I saw the benefits of DSCM tools, but
said benefits didn't seem like enough to warrant a switch.

What made me finally make the move to git, and *love* it?

GitHub.

Sorry, but nothing compares to GitHub. This one tool is the biggest
reason that Rails finally made the move to git, and why so many others
are also making the jump.

Source code collaboration. Distributed development that almost
couldn't be made simpler.

So until Hg, Bazaar, etc have a similar tool, and is getting as
popular as GitHub, I won't even consider them but as toy tools for
people who suffer from NIH syndrome. GitHub is the IMO best thing
that's ever happened to Open Source development, so I choose git.

Jason

I just wanted to say, I have been using git with windows on a daily 
basis
since late summer and have had no problems. I has pretty good ui tools, 
but
the command line is still where all the power is.

Michael Klishin wrote:
> and one day the higher power will remind us of our sins, but I am sure
> 
> Mercurial said to have a good Windows tool (TortoiseHg), but on OS X and
> Linux it is a
> completely different story. I never really used a UI tool on OS X, but I
> know some people
> who were looking for one, and what they found was miserable.
> 
> I have no idea what Bazaar has but it probably does better than Hg since
> Canonical cares about less technical users.
> Darcs seems to be lacking UI tools altogether.

I use Komodo as my main IDE. It has full support for Perforce, CVS and
SVN, and "partial" support for Git, Bazaar and Mercurial. I don't have a
full definition for "partial", but for Git, you have to do your own "git
push". I don't use Perforce, CVS, Bazaar or Mercurial, so I can't
comment on them. In any event, ActiveState is committed to improving
support for Git, etc., so I wouldn't rule out Git on this basis. But as
of about 15 minutes ago, Subversion wins this one against Git.

I think if you have Tcl/Tk installed on your Windows box, you can use
the Tk-based GUI tools that come with Git. And of course, there's always
Cygwin-X. <ducking> On Macs, isn't Textmate still the "gold standard"
for Rubyists? How well does Textmate support all the revision control
systems?

> Availability of Github:
> 
Amen, amen and amen!

Eustáquio Rangel wrote:
> remember that
> Git is used to keep projects like the Linux kernel and take a look
> again on it.

I am remembering a line from AWDR -- something about everything being
done for historical reasons. That's precisely why there is a Git and why
the Linux kernel uses it. The Linux kernel used to be maintained in a
system called BitKeeper. Linus Torvalds asked the developer(s) of
BitKeeper to release it as an open source project. They either couldn't
or wouldn't, so Linus developed Git as a replacement.

The point is that the Ruby community is different from the Linux
community in SCM use cases, community structure, etc. So the argument
that it's used for the Linux kernel doesn't impress me.

> I think it would be cool (ops) to have the Ruby source
> code on a git repository.

"A Git repository?" I think the original poster had Github as one of the
primary motivators for the switch. I don't think "any old Git
repository" would be acceptable.

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P), WOM

I've never met a happy clam. In fact, most of them were pretty steamed.

On Sat, Jan 3, 2009 at 21:40, M. Edward (Ed) Borasky <znmeb@cesmail.net> 
wrote:

> I am remembering a line from AWDR -- something about everything being
> done for historical reasons. That's precisely why there is a Git and why
> the Linux kernel uses it. The Linux kernel used to be maintained in a
> system called BitKeeper. Linus Torvalds asked the developer(s) of
> BitKeeper to release it as an open source project. They either couldn't
> or wouldn't, so Linus developed Git as a replacement.

How quickly history gets distorted.  Please see
http://en.wikipedia.org/wiki/Git_(software)#Early_history for the
actual turn of events that led to Git being created.

On Sat, Jan 3, 2009 at 6:40 PM, M. Edward (Ed) Borasky
<znmeb@cesmail.net> wrote:

> Eustáquio Rangel wrote:
>> remember that
>> Git is used to keep projects like the Linux kernel and take a look
>> again on it.
> I am remembering a line from AWDR -- something about everything being
> done for historical reasons. That's precisely why there is a Git and why
> the Linux kernel uses it. The Linux kernel used to be maintained in a
> system called BitKeeper. Linus Torvalds asked the developer(s) of
> BitKeeper to release it as an open source project. They either couldn't
> or wouldn't, so Linus developed Git as a replacement.

Yeah, I know the history. Btw, Is a good one on how making the things
works when there are no options left on the way you think they should
be.

> The point is that the Ruby community is different from the Linux
> community in SCM use cases, community structure, etc. So the argument
> that it's used for the Linux kernel doesn't impress me.

Don't know, after all, they are all developers, if we're talking about
the people who hack the Ruby source code or even get the source to
build from it. The intent was not to impress you, just to give some
more points out of the "Rails world", if the problem is the "fashion"
thing about it.

>> I think it would be cool (ops) to have the Ruby source
>> code on a git repository.
> "A Git repository?" I think the original poster had Github as one of the
> primary motivators for the switch. I don't think "any old Git
> repository" would be acceptable.

Github is a Git repository with *very good* tools. And even if we have
a "old Git repository", for me it will be acceptable enough to store
the Ruby source code. If you don't agree, no problem. As I told on the
previous message, it was my two cents. Take easy, man. ;-)

Regards,

Nikolai Weibull wrote:
> http://en.wikipedia.org/wiki/Git_(software)#Early_history for the
> actual turn of events that led to Git being created.
> 
> 

Even before the events described in the Wikipedia article, there were
"tensions" between Linus and Larry McVoy over the fact that BitKeeper
was proprietary. I'd have to go hunting in the Linux kernel mailing list
to find the messages, but Linus was "concerned" that BitKeeper wasn't
open source and thus the project was vulnerable to what ended up 
happening.

And my point was that Git was tailored to the Linux kernel use cases and
community structure. There might be something better for *Ruby*
developers than either SVN or Git. The original poster's argument for
Git hinges on the Github project management infrastructure, not just
Git. I wouldn't be participating in this discussion if Github wasn't
part of the "package".


--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P), WOM

I've never met a happy clam. In fact, most of them were pretty steamed.

On Sat, Jan 3, 2009 at 22:39, M. Edward (Ed) Borasky <znmeb@cesmail.net> 
wrote:

> Nikolai Weibull wrote:

>> On Sat, Jan 3, 2009 at 21:40, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

>>> I am remembering a line from AWDR -- something about everything being
>>> done for historical reasons. That's precisely why there is a Git and why
>>> the Linux kernel uses it. The Linux kernel used to be maintained in a
>>> system called BitKeeper. Linus Torvalds asked the developer(s) of
>>> BitKeeper to release it as an open source project. They either couldn't
>>> or wouldn't, so Linus developed Git as a replacement.

>> How quickly history gets distorted.  Please see
>> http://en.wikipedia.org/wiki/Git_(software)#Early_history for the
>> actual turn of events that led to Git being created.

> Even before the events described in the Wikipedia article, there were
> "tensions" between Linus and Larry McVoy over the fact that BitKeeper
> was proprietary. I'd have to go hunting in the Linux kernel mailing list
> to find the messages, but Linus was "concerned" that BitKeeper wasn't
> open source and thus the project was vulnerable to what ended up happening.

Seriously, you distorted the history of Git.  Whether or not the
events you mention actually took place doesn't matter.

On Sat, Jan 3, 2009 at 10:39 PM, M. Edward (Ed) Borasky
<znmeb@cesmail.net> wrote:
> And my point was that Git was tailored to the Linux kernel use cases and
> community structure.

Sorry but I seriously fail to see what exactly makes git specifically
tailored for the Linux kernel use case and community structure.
Although there is little doubt that it was created for the specific
purpouse of managing the Linux kernel codebase and it ships with
complimentary scripts that ease that particular workflow, there is
absolutely nothing that limits it to that. In fact, one of the upside
of git vs all other scms, distributed or not, is that its enormous
flexibility allows many different kinds of workflows and project
management strategies.

Jason Roelofs wrote:
> What made me finally make the move to git, and *love* it?
>
> GitHub.
>   

Me too. GitHub is a great tool, but git is very hard to use in 
beginning.

I don't know if everybody have time to learn git and develop Ruby and
[put here everything you do in your life].

Marcelo Castellani

Giuseppe Bilotta wrote:
> On Sat, Jan 3, 2009 at 10:39 PM, M. Edward (Ed) Borasky
> <znmeb@cesmail.net> wrote:
>> And my point was that Git was tailored to the Linux kernel use cases and
>> community structure.
> 
> Sorry but I seriously fail to see what exactly makes git specifically
> tailored for the Linux kernel use case and community structure.

And now we can compare ruby with perl instead of linux:

  Perl Migrates To the Git Version Control System
  http://developers.slashdot.org/article.pl?sid=09/01/04/1610256

On Sun, Jan 4, 2009 at 12:14, Joel VanderWerf 
<vjoel@path.berkeley.edu>wrote:

> And now we can compare ruby with perl instead of linux:
>

Yes, we should definitely take advice on working practices from the 
people
developing Perl 6...


mathew

On 04.01.2009, at 21:53, mathew wrote:

> Yes, we should definitely take advice on working practices from the  
> people developing Perl 6...


If you read the post, it was Perl 5 that moved to Git.

MK

On Fri, Jan 2, 2009 at 4:18 PM, Florian Gilcher <flo@andersground.net> 
wrote:

> In addition to that, I want to mention that Windows support of GIT is
> still sub-standard. I'm using the cygwin-build on a daily basis[1] and can
> speak out of personal experience.
I never had any issues with Mercurial between my Windoze and Linux
boxes. I do not know, however how Mercurial acts under high load.
Cheers
Robert

On Sun, Jan 4, 2009 at 20:08, Michael Klishin
<michael.s.klishin@gmail.com> wrote:

> On 04.01.2009, at 21:53, mathew wrote:

>> Yes, we should definitely take advice on working practices from the people
>> developing Perl 6...

> If you read the post, it was Perl 5 that moved to Git.

I'd say, with the same conviction that everyone else posting on this
topic seems to have, that this is proof positive that no one actually
reads what everyone else is writing on this topic and everyone is
simply spewing out their own opinion on the matter and claim that
anyone who doesn't agree is wrong and is therefore a moron (sometimes
cleverly hiding this statement behind sarcasm).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 2, 2009, at 5:59 PM, Luis Lavena wrote:

>>> We already set up quite a few tools around Subversion, so we need to
>> Configuring everything beyond the most simple things gets arcane  
>
> Also, for the record, configured to use ssh and plink (PuTTY) and both
> work without issues.
>
> One important thing: disable autocrlf (false) since is the worse
> default msysGit developers could have introduced.

Well, thanks for the proposed help. At the moment, it works good for
my uses
(as a better perforce client). My point is: all this is too much.
Subversion is:
install => use.

git takes a lot of thought to set up on windows. If it runs, it runs,
thats true.
But it's not a tool that i would suggest any non-command-line-lover to
use.
And Windows users usally are just that.

Also, it sometimes has the tendency of biting you in the back. In my
first
installation, the default hook to deny commits with trailing
whitespace was on.
Combined with the fact that it treated CRLF-endings as trailing
whitespace,
this really messed my windows development up. Sure, thats treatable.
But it
raises a lot of questions for the uninitiated.

Thats why I said: sub-standard. Its not entirely broken or unusable.
It just
feels like an afterthought (might be because of the fact that the whole
windows shell feels like an afterthought).

>>
>> [1]: Yes, I also tried the msysgit, which is even worse.
>
> Again: which part is worse? It lacks things like git-serve, but I can
> live without the need to "host" git repositories in my own computer.

The constant crashes. I don't know whether it works now. I stuck with
the cygwin version.

Regards,
Florian
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAklhzXoACgkQyLKU2FMxSOIjMACgrHhz7XOlnQE2J64AuP/VV+lg
8YgAnA8bHJU2E15Gg2tw3sQSTMUTqtDV
=aE1W
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAklhzaMACgkQyLKU2FMxSOJObQCdH5z952HwYiHA5e6GjQus+3Dv
Q20AoI+yd7qR0DUS1Uu6bGrx+TK7RtTU
=K4h/
-----END PGP SIGNATURE-----

On Mon, Jan 5, 2009 at 10:06 AM, Florian Gilcher 
<flo@andersground.net>wrote:

[...]

[1]: Yes, I also tried the msysgit, which is even worse.
>>>
>>
>> Again: which part is worse? It lacks things like git-serve, but I can
>> live without the need to "host" git repositories in my own computer.
>>
>
> The constant crashes. I don't know whether it works now. I stuck with
> the cygwin version.


I played around with msysGit 1.5 and 1.6 yesterday on winXP and had a 
very
bad experience. 'git pull' ends up in an endless loop asking for the
passphrase which makes it completely unusable.

The cygwin git packages work like a charm.

Both msysGit and cygwinGit come with a tk gui which is helpful for
visualization of branches and all but it is not quite user friendly IMO.

-- henon

On Mon, Jan 5, 2009 at 8:08 AM, Meinrad Recheis
<meinrad.recheis@gmail.com> wrote:
>> The constant crashes. I don't know whether it works now. I stuck with
>> the cygwin version.
>
> I played around with msysGit 1.5 and 1.6 yesterday on winXP and had a very
> bad experience. 'git pull' ends up in an endless loop asking for the
> passphrase which makes it completely unusable.

That's because you tried to checkout a private (ssh) repository and
lack the proper ssh authorization and keys?

I had that working with PuTTY (Pageant) and even with the bundled ssh
without issues.

> The cygwin git packages work like a charm.

Yes, a beautiful and charming snail.

> Both msysGit and cygwinGit come with a tk gui which is helpful for
> visualization of branches and all but it is not quite user friendly IMO.

gitk is great for quick looking, is not like TortoiseSVN or anything 
like that.

Anyhow, what is the point of this discussion? How many Windows users
will hack in the Ruby source code?

And those who does, I guess they are quite command-line savvy.

I know Git has a complex and less userfriendly command line interface,
but the whole discussion was not Git alone but the set of tools around
it.

On 04.01.2009, at 21:14, Joel VanderWerf wrote:

> And now we can compare ruby with perl instead of linux:
>
> Perl Migrates To the Git Version Control System
> http://developers.slashdot.org/article.pl?sid=09/01/04/1610256


http://www.python.org/dev/peps/pep-0374/

MK

Michael Klishin wrote:
> 
> On 04.01.2009, at 21:14, Joel VanderWerf wrote:
> 
>> And now we can compare ruby with perl instead of linux:
>>
>> Perl Migrates To the Git Version Control System
>> http://developers.slashdot.org/article.pl?sid=09/01/04/1610256
> 
> 
> http://www.python.org/dev/peps/pep-0374/

I have this odd feeling they're going to pick Mercurial over Git.

Just a hunch. ;)

Regards,

Dan

On Mon, Jan 5, 2009 at 12:29 PM, Michael Klishin
<michael.s.klishin@gmail.com> wrote:
> http://www.python.org/dev/peps/pep-0374/
>

Very nice approach to make a switch (look at the comparison!). I think
that there should be similar talk in ruby-core (very technical and
informative).

On Mon, Jan 5, 2009 at 12:40 PM, Daniel Berger <djberg96@gmail.com> 
wrote:
> I have this odd feeling they're going to pick Mercurial over Git.

It doesn't matter, they choose what they think is the best (even if
"the best" mean "must be written in python").

--
Pozdrawiam

Radoslaw Bulat

On 05.01.2009, at 16:10, Radosław Bułat wrote:

> Very nice approach to make a switch (look at the comparison!). I think
> that there should be similar talk in ruby-core (very technical and
> informative).


Ruby needs PEP like process badly for virtually anything, but it is a
whole different story.

MK

On Mon, Jan 5, 2009 at 12:09 PM, Luis Lavena <luislavena@gmail.com> 
wrote:

> >>> live without the need to "host" git repositories in my own computer.
> lack the proper ssh authorization and keys?
No, it floods the screen with prompts without waiting for input. Its a 
bug
that happens in certain environments and I saw on the net that others 
had
experienced the same thing.

-- henon

On Mon, Jan 05, 2009 at 10:22:49PM +0900, Michael Klishin wrote:
> Ruby needs PEP like process badly for virtually anything, but it is a  
> whole different story.
>
> MK

Time for a question from the community-newb:

What is it that's prevented an 'REP' from being established? I've seen 
the above
sentiment tossed around a lot, so if it were a matter of "we don't have 
anywhere
to post them" then I'm surprised someone hasn't thrown together a quick 
little
webapp to take care of that. Am I just hearing a vocal minority, or is 
there
something else going on there?

--Tommy M.
http://www.duwanis.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 5, 2009, at 2:36 PM, Tommy Morgan wrote:

> sentiment tossed around a lot, so if it were a matter of "we don't  
> have anywhere
> to post them" then I'm surprised someone hasn't thrown together a  
> quick little
> webapp to take care of that. Am I just hearing a vocal minority, or  
> is there
> something else going on there?
>
> --Tommy M.
> http://www.duwanis.com
>



Ruby had something called RCR (Ruby Change Request)[1]. I can't tell
you why,
but it didn't seem to work out and ruby-core is now the place to speak
about
changes.

If you are interested in that, you should fork the discussion :).

[1]: http://rcrchive.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkliEA8ACgkQyLKU2FMxSOKY2ACfXJTk1Gb7tAt5nA3isTIOpO9+
sYIAnjcR1o8Fs1xjjIaT/GlLnWTZxwL3
=e0Eq
-----END PGP SIGNATURE-----

On 05.01.2009, at 16:36, Tommy Morgan wrote:

> What is it that's prevented an 'REP' from being established? I've  
> seen the above
> sentiment tossed around a lot, so if it were a matter of "we don't  
> have anywhere
> to post them" then I'm surprised someone hasn't thrown together a  
> quick little
> webapp to take care of that. Am I just hearing a vocal minority, or  
> is there
> something else going on there?


I think that if someone puts together a small merb app or rack app or
whatever,
and helps Matz and co deploy it, nobody would object about having a
more organized way
to propose language/process/stdlib changes.

It would require a shift in perspective about the process though. My
observations so far (3+ years with Ruby)
are that Ruby people are a bit like children (in a good sense, and
myself included). They like playing and not necessary like keeping
things organized.

Python people are more "boring", and this is why — IMO — they have PEP
and really well thought out process of 2.5 => 3.0 migration,
  and we don't have REP and any 1.8.x => 1.9.x migration plans. I am
not bitching/complaining here, I just want to say, this would be a way
more significant move for Ruby community that a switch from Subversion
to Git. This is it.

MK

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 5, 2009, at 2:59 PM, Michael Klishin wrote:

>> is there
>> something else going on there?
>
>
> I think that if someone puts together a small merb app or rack app  
> or whatever,
> and helps Matz and co deploy it, nobody would object about having a  
> more organized way
> to propose language/process/stdlib changes.

Why so big? Ruby already uses Redmine (http://redmine.ruby-lang.org),
which itself has a wiki that can directly be linked by the Ticket
tracker. No need for a merb application, the infrastructure is there.
Everyone can get an account and edit.

I think if someone seriously wants to garden an RCR-Wiki and propagate
it, no one will hold him back.

Regards,
Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkliFVYACgkQyLKU2FMxSOJutACeOvGDI6i7osyftVLV4/849qa3
ec4An3ZO/NOY1mi7R1sAtTVg0N69Ziun
=vsSO
-----END PGP SIGNATURE-----

Tommy Morgan wrote:
> to post them" then I'm surprised someone hasn't thrown together a quick little
> webapp to take care of that. Am I just hearing a vocal minority, or is there
> something else going on there?
> 
> --Tommy M.
> http://www.duwanis.com
> 
> 

There have been a couple of attempts at something like this for the
language itself. There was a Ruby Change Request web site and a few
others that I've forgotten. But I don't recall anything on the support
infrastructure. Meanwhile, the "language itself" discussion seem to take
place (in English, anyhow) here on ruby-core. Maybe there should be a
"ruby-infrastructure" list for those who want to talk about workflows,
benchmark suites, test suites, version control systems, etc.

On Sat, Jan 03, 2009 at 12:48:09PM +0900, Michael Klishin wrote:
> Darcs has idea of "every branch is a separate directory" (or used to
> have it). I can't say it is a problem but you will end up having 3-5
> copies of the pretty much the same code, and if you repository is 600
> megs, not all movies you try to  download from iTunes may fit into
> your HD.

The bigger problem with keeping separate copies of each branch is that
it forces the user to do a full recompile when a new branch is made (*).
This discourages short-lived development branches.

Paul


(*) at least, this is true when using make -- a build system that uses
md5sums makes this less of an issue

On 05.01.2009, at 18:11, M. Edward (Ed) Borasky wrote:

> eanwhile, the "language itself" discussion seem to take
> place (in English, anyhow) here on ruby-core. Maybe there should be a
> "ruby-infrastructure" list for those who want to talk about workflows,
> benchmark suites, test suites, version control systems, etc.


Obviously Python development discussions take place on python-dev the
similar way.
But! They got eventually posted as PEPs and everyone can read a
summary instead of digging in the mailing list.

Why cannot Ruby do the same, getting away with a wiki and a common
format for these proposals (so they don't turn into disorganized mess)?
It is why PEPs are useful: summary and "official response" for every
significant change ever proposed can be found by everyone on the web.

MK

Luis Lavena wrote:

> 
Well, the whole "Ruby on Windows" discussion probably needs its own
mailing list. :) And *your* repository is already on Github, so I count
that as a strong vote in favor of Git(hub).

By the way, I had occasion to poke around on my Github repo last night
and discovered that I'm at 13 MB of my 100 MB free account limit. 100 MB
ain't a whole lot of disk space. It's probably fine for my two tiny
projects, but I think Ruby might need more. So "financial support" is
going to be a consideration in any repo migrations.

On Jan 5, 2009, at 9:20 AM, M. Edward (Ed) Borasky wrote:

> By the way, I had occasion to poke around on my Github repo last night
> and discovered that I'm at 13 MB of my 100 MB free account limit.  
> 100 MB
> ain't a whole lot of disk space. It's probably fine for my two tiny
> projects, but I think Ruby might need more. So "financial support" is
> going to be a consideration in any repo migrations.

Github will usually raise the limit for open source projects.  All we
need to do is ask.

James Edward Gray II

On Tue, Jan 06, 2009 at 12:20:12AM +0900, M. Edward (Ed) Borasky wrote:
> By the way, I had occasion to poke around on my Github repo last night
> and discovered that I'm at 13 MB of my 100 MB free account limit. 100 MB
> ain't a whole lot of disk space. It's probably fine for my two tiny
> projects, but I think Ruby might need more. So "financial support" is
> going to be a consideration in any repo migrations.

It's hard to say, but it looks like Github did the official perl mirror 
pro
bono: http://github.com/blog/276-perl-mirror-on-github

Of course, I think the perl repo is only 80MB, judging from the 
comments.

A good point, though. If we get there, we may want to discuss options 
directly
with the Github guys - they may do something better than make ruby buy 
an
appropriately-sized account.

--Tommy M.
http://www.duwanis.com

On 05.01.2009, at 18:12, Paul Brannan wrote:

> The bigger problem with keeping separate copies of each branch is that
> it forces the user to do a full recompile when a new branch is made  
> (*).
> This discourages short-lived development branches.


If you do a lot of work on multiple branches, yes. I am not sure how
often it is the case, and for two branches (1.8.x and 1.9.x) one can
use two local Git clones.
Two, not 5 or 6.

MK

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 5, 2009, at 4:12 PM, Paul Brannan wrote:

> This discourages short-lived development branches.
>
> Paul
>
>
> (*) at least, this is true when using make -- a build system that uses
> md5sums makes this less of an issue

Darcs still has no concept of branches. I quite like that. It gives a
better overview on your file system. Every "branch" is still laid out
like you would have it in SVN or something like that.

I would mark that problem as a problem of you build-system or you
workflow.

If I want to branch, I usually don't create a new repos as my branch
and start working there, instead I put the momentary state away in
another repos and continue working on my active repos. Then, I push
patches back to the "old repository" or pull patches from somewhere
else. This ensures that all "temporary data" is still in my active
"working repository". Sure, it only goes so far until I merge the
branches changes back into the "old repository", but thats when I
prefer to do a full check (and eventually rebuild) anyways.

My biggest problem with Darcs is that I have yet to run into the
dreaded merge problem. It is said not to be rather tame in > 2.0, but
I have yet to experience it. So I can't make an assessment on that.
The Darcs command line interface is one of the best I ever
experienced. At least when it comes to my workflow, you mileage may
(and will!) vary.

Regards,
Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkliLl4ACgkQyLKU2FMxSOK7DQCeL8g0i05pEclkmW79MfoIa86x
2ggAnRsmdx+RutwBGjTdt9DFPjlqfZGX
=K54Y
-----END PGP SIGNATURE-----

On Mon, Jan 5, 2009 at 4:59 PM, Florian Gilcher <flo@andersground.net> 
wrote:
> Darcs still has no concept of branches. I quite like that. It gives a better
> overview on your file system. Every "branch" is still laid out like you
> would have it in SVN or something like that.

Although I've never used darcs, the inability to properly handle
branches was actually one of the reasons why I gladly moved away from
mercurial (my first dscm).

The upside of git is that it doesn't _force_ you to work with separate
checkouts for separate branches, although you _can_ do it: just clone
the local repo --git is even smart enough to hardlink blobs when
possible. I say this is a strong vote in favour of git, as it allows
both branching workflows (in-place and separate checkout).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 5, 2009, at 5:29 PM, Giuseppe Bilotta wrote:

> mercurial (my first dscm).
>
> The upside of git is that it doesn't _force_ you to work with separate
> checkouts for separate branches, although you _can_ do it: just clone
> the local repo --git is even smart enough to hardlink blobs when
> possible. I say this is a strong vote in favour of git, as it allows
> both branching workflows (in-place and separate checkout).

I'm on the "i don't want to think to much about it" or "lazy bastard"
side. For example, one of my main reasons for darcs is it's nice
cherry-picking interface that is the _default_ way of handling it.
Sure, i could use git cherry-pick and friends, but Darcs gives me the
collection of features I really like at my fingertips.
Also, I tend not to play with branches too much, but only push the
patches I really want back to upstream/trunk. Thats the default way in
darcs.
Sure, I could push git into my workflow, but that would mean I would
have to costumize git everytime I change computers. It does a lot, but
i only need half of it and it always takes me time to figure out which
half I wanted to use.

Also, if you allow both workflows, which link will you put on your
website? ;)

As I said before: your mileage may vary. I don't like git that much
and I also have a problem with hypes. So I would tend to wait until
the "revolution" is over.
But I support the democratic process ;).

Regards,
Florian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkliRyQACgkQyLKU2FMxSOJzcwCgh9c5WlHX8LOcImLFpBRMY3qD
qVkAnjX/3PbnABGSog7IaZnjC37TvXef
=dhTY
-----END PGP SIGNATURE-----

M. Edward (Ed) Borasky wrote:
> system called BitKeeper. Linus Torvalds asked the developer(s) of
> BitKeeper to release it as an open source project. They either couldn't
>   
> or wouldn't, so Linus developed Git as a replacement.
>   

[Off-topic but the drama of the BitKeeper wars compells me]

Not to nitpick, but Linus never asked Bitkeeper to open source itself.

 From my armchair, with a snifter of Cognac,  I would read the BitKeeper
threads on LKML when I wanted a soap opera.

Linus knew the Bitkeeper guy and the Bitkeeper guy decided to let Linus
use Bitkeeper free (as in beer).  All other developers could get a free
copy of the client so long as they agreed to some licensing terms.  Some
people (Tridgell) felt it was heinious to build a GPL kernel using a
commerical SCM.   They also did not like the terms of the free license
of BitKeeper (like if you use it you cannot work on your own SCM).   So
people kept trying to reverse engineer Bitkeeper protocols and inner
workings and it eventually boiled to a head when the BitKeeper guy
(Larry?) decided no more free licenses (especially to OSDL where Linus
and Tridgel worked).   This forced Linus into a corner, because up until
that point because he only liked BitKeeper.  That was the seed for Git.

I suspect there were some technical motivations for git getting created
as well, but I personally think it was mostly Linus just getting fed up
with the endless BitKeeper wars.

-Tom

On Jan 2, 2009, at 17:25 PM, Nikolai Weibull wrote:
> about, for example, http://whygitisbetterthanx.com/#easy-to-learn.
>
> I don't really care what SCM the MRI developers use and I don't
> understand why everyone seems to think that they are entitled to an
> opinion about it, but it's time to get over this meaningless and
> repeated discussion.

I think I'm entitled to an opinion on the subject because I am a
committer, and I cited my experiences in forming my opinion.  (It
turns out that I'm not alone in this opinion.)

> So can we please have a long discussion about how people like me
> shouldn't try to stifle discussions on mailing lists instead?

I think your email is useful and relevant.

> Or at least get our facts straight and present valid cases for the
> SCMs that we prefer?

Part of one paragraph in the message you responded to straightened
facts.  I prefer that things stay as they are (using subversion).

At 22:59 09/01/05, Michael Klishin wrote:

>It would require a shift in perspective about the process though. My  
>observations so far (3+ years with Ruby)
>are that Ruby people are a bit like children (in a good sense, and  
>myself included). They like playing and not necessary like keeping  
>things organized.

Very well put. Also, the whole PEP business doesn't exactly match
agile development. From http://agilemanifesto.org/:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
Sometimes, it's important to think something through very well
and to have everybody agree. Sometimes, it's important to fix
something quickly. For some things, there are only very few
people who care, or who understand what's involved. Sometimes
(often), it's easier or more important to actually try things
out than to describe them in detail.

For some changes, in particular for the move to Strings tagged
with Encoding when going from 1.8 to 1.9, there have been
very detailled wiki pages, but they were less formal than
PEPs, and they were in Japanese.


>Python people are more "boring", and this is why $BM
(BIMO $BM
(Bthey have PEP  
>and really well thought out process of 2.5 => 3.0 migration,
>  and we don't have REP and any 1.8.x => 1.9.x migration plans. I am  
>not bitching/complaining here, I just want to say, this would be a way  
>more significant move for Ruby community that a switch from Subversion  
>to Git. This is it.

Another difference is that Python is basically monolingual (only 
English),
but Ruby development is bilingual (Japanese and English). Currently,
this seems to work reasonably well for bugs: People have an idea
of who might be responsible for a bug, and accordingly post in English
or Japanese. Most Japanese developers read English well enough to feel 
okay
with English bug reports (a good bug report usually has very little 
text,
and lots of data).

For PEP-like proposals, my guess is that it would be quite a different
story. Abstract text takes quite a bit more time to read and digest
in a foreign language, and proposals tend to be way longer than bug
reports.

Code is one way to lower language barriers!

A third point is that the Ruby community doesn't have an unlimited
amount of resources (read: people). It's not just a question of
doing REPs or not doing REPs, but of doing REPs or doing something
else (such as testing, bug fixing, additional features, better 
docu,...).

My conclusion is that something REP-like could work for some aspects
of Ruby development, but expecting that every change in the language
is documented by a REP is going way too far.

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp

> I think I'm entitled to an opinion on the subject because I am a  
> committer, and I cited my experiences in forming my opinion.  (It turns 
> out that I'm not alone in this opinion.)

Of course, but the experience of being a non-committer who still tries
to improve ruby is also important. Honestly, I think it is even more
important. The basic asymmetry of centralized VCSs makes the workflow of
a committer always much better than the one of a non-commiter since the
non-commiters have little access to the VCS services. And one experience
of one non-committer is: it sucks badly.

This is mainly because non-trivial patches (and even trivial ones) tend
to stay quite long in the bug tracker. Which means that you basically
have, as a non-committer, to update your patch over and over again to
the newest HEAD. I did that with svn, it is horrible (you have to do it
by hand). I do that now with git and it works like a charm (thanks to
rebase).

Another thing: maintaining the ChangeLog file. This thing looks very
stupid, and makes merging horrible (you basically always have a conflict
on ChangeLog, for obvious reasons). I thought first that it was a
workaround from the good'ol days of CVS and even started to write a
script that would generate it. Then I realized that it was not doable
with SVN since there are no merges. Stupid.

Sylvain

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 6, 2009, at 10:29 AM, Sylvain Joyeux wrote:

> script that would generate it. Then I realized that it was not doable
> with SVN since there are no merges. Stupid.

I don't know about you specific problems with that, but SVN 1.5 knows
about
merging. I don't know which version the ruby repos is running, but
this is
one of the best reasons for 1.5.

Regards,
Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkljNVUACgkQyLKU2FMxSOLb8QCglOIqXCGmC+5FZQP4vjY/jxb9
s6IAnRxRNmcLEpldGpG/0Z8cQU2AeCGS
=ndcr
-----END PGP SIGNATURE-----

On Sun, Jan 4, 2009 at 13:08, Michael Klishin
<michael.s.klishin@gmail.com>wrote:

> On 04.01.2009, at 21:53, mathew wrote:
>
>> Yes, we should definitely take advice on working practices from the people
>> developing Perl 6...
>>
>
> If you read the post, it was Perl 5 that moved to Git.


Well, in that case... We should definitely take advice on working 
practices
from the people maintaining a project which is in maintenance mode and 
no
longer undergoing heavy refactoring.

On Mon, Jan 5, 2009 at 05:09, Luis Lavena <luislavena@gmail.com> wrote:

> Anyhow, what is the point of this discussion? How many Windows users
> will hack in the Ruby source code?
>
> And those who does, I guess they are quite command-line savvy.
>

I nominate you to tell Austin Ziegler that he needs to start using 
Cygwin.
I'll be over here behind the plexiglass shielding.


mathew

+1

Sylvain describes my situation exactly.
I'm a CVS dinosaur whose recently realized that I've got to evolve to
survive.
And, like many other Ruby "non-committers", the hassle of tracking the
moving target
at HEAD seriously dampens my enthusiasm.

Git may or may not be the best distributed source management tool, but 
it
would
be silly to choose some other DSCM for the core interpreter given that
many of the large Ruby apps and libraries have already moved to git.

- brent

P.S.  Can anyone suggest a good, gentle introduction to git for mere
mortals, lest
I repeat Eric Hodel's negative experiences with it?

Brent Roman wrote:
> P.S.  Can anyone suggest a good, gentle introduction to git for mere
> mortals, lest
> I repeat Eric Hodel's negative experiences with it?

It comes with a tutorial and manual, which are not too bad. I'm getting
started with it too. Maybe we can move this discussion to a thread on
ruby-talk, and get a little git-for-rubyists support group going?

On Jan 6, 2009, at 12:16 PM, Brent Roman wrote:

> P.S.  Can anyone suggest a good, gentle introduction to git for mere
> mortals, lest
> I repeat Eric Hodel's negative experiences with it?

Here's what I liked:

http://blog.grayproductions.net/articles/getting_git_thanks_to_peepcode

James Edward Gray II

Hi,

In message "Re: [ruby-core:21165] Re: Happy new year and... moving Ruby 
development to Git?"
    on Tue, 6 Jan 2009 18:29:44 +0900, Sylvain Joyeux 
<sylvain.joyeux@m4x.org> writes:

|This is mainly because non-trivial patches (and even trivial ones) tend
|to stay quite long in the bug tracker. Which means that you basically
|have, as a non-committer, to update your patch over and over again to
|the newest HEAD. I did that with svn, it is horrible (you have to do it
|by hand). I do that now with git and it works like a charm (thanks to
|rebase).

As far as I believe issues and patches posted Redmine need not to
update to the latest.  The committers will do.  Most of left out
changes are just posted to the list.

|Another thing: maintaining the ChangeLog file. This thing looks very
|stupid, and makes merging horrible (you basically always have a conflict
|on ChangeLog, for obvious reasons). I thought first that it was a
|workaround from the good'ol days of CVS and even started to write a
|script that would generate it. Then I realized that it was not doable
|with SVN since there are no merges. Stupid.

We have a tool to do the ChangeLog merge, so let us do the merge, just
post the ChangeLog entry for the patch.

None the less, we could prepare the git repository synchronized with
the central repository.  Yugui already has one anyway.

              matz.

> As far as I believe issues and patches posted Redmine need not to
> update to the latest.  The committers will do.
I'm not seeing a committer update 100+ lines of code that are 6 to 12
months old (or he will ignore it right away, because it is too much
work). Yes, that's how long some patches bit-rot on the bugtracker.

And given that I actually *use* the patches I post, I still have to
update it if I want to benefit from new Ruby version. You still see
everything from the point of view of core Ruby. Patches bitrot for long.
Some functionalities are experimental (the MBARI patches or my own GC
patches) and cannot be committed. We can't commit them on SVN because we
are not SVN committer.  Still, we need to keep them up to date, because
*we use them* and because it would be too much work for committers to
update them (and therefore the patches will be thrown away after a
while).

It is perfectly sensible to reduce the commit rights to the core
repository, but the use of a centralized VCS is an "all-or-nothing":
either you are committer, or you can't use the VCS.

> None the less, we could prepare the git repository synchronized with
> the central repository.  Yugui already has one anyway.
Fine, I'll just rebase mine on it then ...

Sylvain

On 07.01.2009, at 3:59, Yukihiro Matsumoto wrote:

> None the less, we could prepare the git repository synchronized with
> the central repository.


Matz,

But what repository will core committers check into? Subversion or
Git? Read-only clone of Git is far less useful than a Git repository
where development happens,
because it means changes are still shared as patches, so when people
apply them, there is no history of changes, and it is always a lot of
manual work for people
who want to try out those changes.

I just decided to ask so there are no fault expectations set.

MK

Hello,

On Wed, Jan 7, 2009 at 1:59 AM, Yukihiro Matsumoto <matz@ruby-lang.org> 
wrote:
> |rebase).
>
> As far as I believe issues and patches posted Redmine need not to
> update to the latest.  The committers will do.  Most of left out
> changes are just posted to the list.

Of course, git makes the work easier for the committers too (git
patches are often able to automatically resolve conflicts doing the
appropriate three-way merges). And the patch author gets the benefit
of his or her name in the log ;-)

> |Another thing: maintaining the ChangeLog file. This thing looks very
> |stupid, and makes merging horrible (you basically always have a conflict
> |on ChangeLog, for obvious reasons). I thought first that it was a
> |workaround from the good'ol days of CVS and even started to write a
> |script that would generate it. Then I realized that it was not doable
> |with SVN since there are no merges. Stupid.
>
> We have a tool to do the ChangeLog merge, so let us do the merge, just
> post the ChangeLog entry for the patch.

With git, the changelog can be easily created automatically.

By the way, are these tools (such as the ChangeLog merge tool you
mentioned) available somewhere?

> None the less, we could prepare the git repository synchronized with
> the central repository.  Yugui already has one anyway.

There are also a couple of git mirrors of the svn repository on
github.  It would be nice to have e.g. Yugui's repo (or any other)
elected to be the official mirror and pubished somewhere (possibly on
github and/or gitorious too), with a link from
http://www.ruby-lang.org/en/community/ruby-core/

(by the way, http://www.ruby-lang.org/en/downloads/ still mentions CVS
instead of SVN)
(by the way #2, http://kitenet.net/~joey/rfc/rel-vcs/ proposes a <link
rel=vcs> microformat to add to webpages the reference repositories,
you might want to consider adding it)

Hello,

On Wed, Jan 7, 2009 at 1:55 PM, Michael Klishin
<michael.s.klishin@gmail.com> wrote:
> Read-only clone of Git is far less useful than a Git repository where
> development happens,
> because it means changes are still shared as patches, so when people apply
> them, there is no history of changes, and it is always a lot of manual work
> for people
> who want to try out those changes.
>
> I just decided to ask so there are no fault expectations set.

I'm not Matz, but I would say that an official git mirror of the svn
repository is a necessary first step to begin a possible transition to
the new vcs. As has already been mentioned in this discussion,
switching to a different vcs is not something you do snapping your
finger, so there has to be a transition period where the new one is
nothing more than a mirror of the old one.

On 07.01.2009, at 16:14, Giuseppe Bilotta wrote:

> I'm not Matz, but I would say that an official git mirror of the svn
> repository is a necessary first step to begin a possible transition to
> the new vcs


There are already read-only mirrors. They make little sense: the
reason to switch is that with git and github even complex flow of
patches simpler to handle that simple cases like Brett's patches with
SVN/diff/patch.

diff/patch do not have history of changes, so a person who does the
merge must take care and keep that history in one's head. It stops a
lot of people from even trying to contribute, since they unconsciously
feel how fun it's gonna be for others to manage a couple of giant
patches (remember, you have no local commits).

This happens unconsciously. With Git, you just fork Ruby on GitHub, do
the work incrementally and send a link to your branch to ruby-core,
and people have all the history provided by the tool, and don't have
to keep patches order and who sent them in their heads.

This is my personal perspective of the way things are. I may be
totally wrong. But I still think that keeping main repository in
Subversion and providing "official git mirror" makes no sense at all,
since it won't really change the way contributions are made.

MK

On Wed, Jan 7, 2009 at 3:04 PM, Michael Klishin
<michael.s.klishin@gmail.com> wrote:
> handle that simple cases like Brett's patches with SVN/diff/patch.
> order and who sent them in their heads.
>
> This is my personal perspective of the way things are. I may be totally
> wrong. But I still think that keeping main repository in Subversion and
> providing "official git mirror" makes no sense at all, since it won't really
> change the way contributions are made.

Sorry, I don't agree. Having one single official mirror of the ruby
repository, instead of a number of unofficial, community-provided
repository means that you can in fact start working on your own github
forks: even though obviously the full power of the git and github
tools cannot be exploited for the patch workflow, it would still be
possible for e.g. Brent to keep his MBARI patchset in a branch of his
fork of the official git mirror, easying access to the rest of the
community.

Of course it wouldn't be the perfect solution until the full
transition to git is done, but, as I said, it's a necessary first
step. Moreover, as the git mirror would probably get a LARGE user base
to switch, it's likely to be a big point in favour of the switch.

On Tue, Jan 6, 2009 at 2:43 PM, mathew <meta@pobox.com> wrote:
> Well, in that case... We should definitely take advice on working practices
> I nominate you to tell Austin Ziegler that he needs to start using Cygwin.
> I'll be over here behind the plexiglass shielding.
>
>

My statement was a sarcasm. I myself send fixes to Ruby C code that
doesn't behave properly on native Windows (not cygwin).

Those who do that are quite savvy in the command line, not noobs. I
use msysGit on a daily basis and perform almost all the tasks that can
be done, including committing using the Git GUI.

So... I personally don't see Git on Windows a limitation anymore, even
less than certain MinGW patches were integrated in Git 1.6 and later.

On Mon, Jan 5, 2009 at 6:45 PM, Florian Gilcher <flo@andersground.net> 
wrote:
>> both branching workflows (in-place and separate checkout).
>
> I'm on the "i don't want to think to much about it" or "lazy bastard" side.

Me too.

> For example, one of my main reasons for darcs is it's nice cherry-picking
> interface that is the _default_ way of handling it. Sure, i could use git
> cherry-pick and friends, but Darcs gives me the collection of features I
> really like at my fingertips.

Out of curiosity, what's so special about darcs cherry-picking 
interface?

> Also, I tend not to play with branches too much, but only push the patches I
> really want back to upstream/trunk. Thats the default way in darcs.

The default in darcs is that you have to choose which commits to push
upstream everytime you push? And that's a plus? 8-D

> Sure, I could push git into my workflow, but that would mean I would have to
> costumize git everytime I change computers. It does a lot, but i only need
> half of it and it always takes me time to figure out which half I wanted to
> use.

Why would you need to customize git? Having a different workflow with
it doesn't mean having to change git parameters, it just means using
it in a different way.

> Also, if you allow both workflows, which link will you put on your website?
> ;)

That's definitely up to whoever maintains the website 8-D

> As I said before: your mileage may vary. I don't like git that much and I
> also have a problem with hypes. So I would tend to wait until the
> "revolution" is over.
> But I support the democratic process ;).

Honestly, I don't see this whole "hype" thing about git.

If anything, I see a lot of FUD being spread about it, like for
example its being extreeeeeemely complex and unfriendly and with an
unfamiliar interface, which is something totally opposite to my
experience: I didn't find it less friendly or less familiar than, say
mercurial (of course there's the clear distinction between committing
and pushing, but that's shared by all distributed vcs so it's only
unfamiliar to people used to working with centralized vcs only); in
fact, I found myself more comfortable with it than with hg.

It *is* to be said that my experience with git started with 1.5.x
versions, which (from what i've read), made gigantic steps forward in
the UI from 1.4.x and earlier, so I possibly spared myself the initial
scare ealry adopters might have had. So maybe the revolution is
already over ;-)

On Jan 7, 2009, at 7:04 AM, Giuseppe Bilotta wrote:

> (by the way, http://www.ruby-lang.org/en/downloads/ still mentions CVS
> instead of SVN)

Fixed.

James Edward Gray II

On Wed, Jan 07, 2009 at 04:03:12AM +0900, James Gray wrote:
> Here's what I liked:
>
> http://blog.grayproductions.net/articles/getting_git_thanks_to_peepcode
>
> James Edward Gray II

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET 
/articles/getting_git_thanks_to_peepcode.

Reason: Error reading from remote server

On Jan 7, 2009, at 12:17 PM, Paul Brannan wrote:

> On Wed, Jan 07, 2009 at 04:03:12AM +0900, James Gray wrote:
>> Here's what I liked:
>>
>> http://blog.grayproductions.net/articles/getting_git_thanks_to_peepcode
>>
>> James Edward Gray II
>
> Proxy Error

The links seems to work for me right now.  I'm not super what's up
there. Try again is my best suggestion.

James Edward Gray II

On Thu, Jan 08, 2009 at 03:49:13AM +0900, James Gray wrote:
> The links seems to work for me right now.  I'm not super what's up  
> there. Try again is my best suggestion.
>
> James Edward Gray II

Working for me now too, thanks. :)

Paul

> It *is* to be said that my experience with git started with 1.5.x
> versions, which (from what i've read), made gigantic steps forward in
> the UI from 1.4.x and earlier, so I possibly spared myself the initial
> scare ealry adopters might have had. So maybe the revolution is
> already over ;-)
I can tell you that it is the case. I have actually been scared away 
from git
because a friend of mine told me about it in the 1.4 time (I was using 
darcs
at the time). Then later on I tried it again. Much MUCH better.

Sylvain

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 7, 2009, at 5:23 PM, Giuseppe Bilotta wrote:

>> picking
>> interface that is the _default_ way of handling it. Sure, i could  
>> use git
>> cherry-pick and friends, but Darcs gives me the collection of  
>> features I
>> really like at my fingertips.
>
> Out of curiosity, what's so special about darcs cherry-picking  
> interface?
>

Nothing really special, just that it flows nicely and is the default
way of interaction. So you don't have to decide to cherry-pick, you
have to decide _not_ to cherry-pick. It's not "advanced usage". If it
was, I wouldn't use it (see the "lazy bastard" ;) ).

>> Also, I tend not to play with branches too much, but only push the  
>> patches I
>> really want back to upstream/trunk. Thats the default way in darcs.
>
> The default in darcs is that you have to choose which commits to push
> upstream everytime you push? And that's a plus? 8-D

It is. Thats their way of doing "quick branches". Say, you somehow
developed two independent features in parallel on the same branch, you
can then opt not to include one of them on the upstream. As long as
they are independent, you are totally allowed to do that.

It also forces you to somehow think about your patches again. So the
typical problem with "oh ****, I accidentally included a patch I
didn't want to push" vanishes.

> it in a different way.
Well, pushing some features into view more prominently, like having an
alias for "git cherry-pick" and so on. In my experience, git has a
pretty equal distribution for all workflows. That means that my
preferred one doesn't really stand in the back, but it's also not up
front. I am a fan of specialized software. So I want one where my
workflow stands in front ;).
So git doesn't fit my needs, darcs does. No offense.

But in general, the darcs CLI is very though out and infomative. Thats
what i like about it.

>> Also, if you allow both workflows, which link will you put on your  
>> website?
>> ;)
>
> That's definitely up to whoever maintains the website 8-D
>

So, that means that an interested committer has to adapt that.

> unfamiliar interface, which is something totally opposite to my
> experience: I didn't find it less friendly or less familiar than, say
> mercurial (of course there's the clear distinction between committing
> and pushing, but that's shared by all distributed vcs so it's only
> unfamiliar to people used to working with centralized vcs only); in
> fact, I found myself more comfortable with it than with hg.

I didn't say that its extremly complex or explicitly unfriendly. I
have a lot of stuff that I actually like about git (the vast
collection of transports to other upstreams, for example). But I also
have the impression that user friendlyness is not one of the gits main
goals (which - considering the type of programmer it was written for,
is not very surprising).

I also know that there is some backlash happening at the moment, at
least in the set of people I often interact with. A not so small
number of people I know jumped on the git-wagon and moved back. Thats
a typical sign of a hype.

I don't want to argue that git is bad. I just don't see it as the
pinnacle of VCS evolution as some people try to sell it.[1] My example
with darcs was to prove a point: the git glove doesn't fit for
everyone. The SVN glove doesn't, as well.[2] Same goes for hg and bzr.

Another word to the discussion. Switching to git doesn't fix the
biggest problems in patch interaction. I forked some projects and sent
patches to their core, just to find out that they were inable to
discuss the problems at hand. In that respect, the o so nice
distributed model kind of never worked for me, because the theory
didn't match with reality. If I see people complaining about patches
that never get applied: thats no SVN problem.

If they have to maintain their own branch and rebase it on head: git-
svn solves this problem already. So I don't see the point where git
and only git suddently makes ruby better.

Regards,
Florian

[1]: For example "Why git is better than X", where you still have to
skim through the HTML comments to see whats actually _bad_ about
git ;). And it states windows support.
[2]: But I also don't buy that it is worthless.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkll3oMACgkQyLKU2FMxSOJWDQCfcA8EtT3KkOB5FhiQOURb3j66
gm4AnRtPf6ojguNLBUBgsiD45sda0Pyl
=pXUN
-----END PGP SIGNATURE-----

On Thu, Jan 8, 2009 at 12:07 PM, Florian Gilcher <flo@andersground.net> 
wrote:
>>>
>> Out of curiosity, what's so special about darcs cherry-picking interface?
>>
>
> Nothing really special, just that it flows nicely and is the default way of
> interaction. So you don't have to decide to cherry-pick, you have to decide
> _not_ to cherry-pick. It's not "advanced usage". If it was, I wouldn't use
> it (see the "lazy bastard" ;) ).

As I said, I haven't used darcs, but it being the default way of
interaction means what? That the most documented function to transfer
patches is cherry-pick instead of (semi)automatic merge?

> you are totally allowed to do that.
>
> It also forces you to somehow think about your patches again. So the typical
> problem with "oh ****, I accidentally included a patch I didn't want to
> push" vanishes.

That makes pushing more work, so I suspect you're not so lazy really ;-)

>> it in a different way.
>
> Well, pushing some features into view more prominently, like having an alias
> for "git cherry-pick" and so on. In my experience, git has a pretty equal
> distribution for all workflows. That means that my preferred one doesn't
> really stand in the back, but it's also not up front. I am a fan of
> specialized software. So I want one where my workflow stands in front ;).
> So git doesn't fit my needs, darcs does. No offense.

None taken. It's not like git is a religion for me ;-) I don't quite
see the point of having an alias for a command, unless you mean that
you would prefer a shorter form (git cp instead of git cherry-pick)
... aliases make sense for abstruse subcommands, not for commands in
plain view.

Maybe what would be nice to have is a "git for darcs users"
intro/tutorial that summarizes the git commans equivalent to the darcs
commands tipically used in the darcs workflow?

> But in general, the darcs CLI is very though out and infomative. Thats what
> i like about it.

I'm sure the git developers wouldn't mind a couple of patches to bring
darcs on part with darcs in terms of usability. Also, what version of
git do you have experience with? I recently switched to 1.6 which is
even better than 1.5 which (as I'm told) is light years ahead of 1.4,
in terms of UI.

>>> Also, if you allow both workflows, which link will you put on your
>>> website?
>>> ;)
>>
>> That's definitely up to whoever maintains the website 8-D
>>
>
> So, that means that an interested committer has to adapt that.

Assuming ruby WILL switch to git, I'm pretty sure that a contribution
to that patch describing the darcs-style workflow would be appreciated

>> experience: I didn't find it less friendly or less familiar than, say
>> mercurial (of course there's the clear distinction between committing
>> and pushing, but that's shared by all distributed vcs so it's only
>> unfamiliar to people used to working with centralized vcs only); in
>> fact, I found myself more comfortable with it than with hg.
>
> I didn't say that its extremly complex or explicitly unfriendly.

It wasn't directed at you, but a general remark about some comments
I've been reading in this list and elsewhere.

> I have a
> lot of stuff that I actually like about git (the vast collection of
> transports to other upstreams, for example). But I also have the impression
> that user friendlyness is not one of the gits main goals (which -
> considering the type of programmer it was written for, is not very
> surprising).

As I mentioned, user friendlyness is being worked on, and proceeds
very fast, especially since Linus isn't the lead developer anymore
;-).

If you happen to use git for some projects, I recommend you to switch
to 1.6+ as soon as possible, and if you have any additional
suggestions about how it could be even more user friendly, asking on
the git mailing list and/or the #git channel on freenode is likely to
gather some attention.

> I also know that there is some backlash happening at the moment, at least in
> the set of people I often interact with. A not so small number of people I
> know jumped on the git-wagon and moved back. Thats a typical sign of a hype.

That would lead me to think that those people switched to git without
taking the time to learn to use the tool properly, but that may just
be my impression ;-)

> I don't want to argue that git is bad. I just don't see it as the pinnacle
> of VCS evolution as some people try to sell it.[1] My example with darcs was
> to prove a point: the git glove doesn't fit for everyone. The SVN glove
> doesn't, as well.[2] Same goes for hg and bzr.

Hm. As far as hg goes, and from my experience, I can't think of
anything that hg offers that git doesn't, both in terms of features
and in terms of UI, so I wouldn't be so sure. I can't talk about brz
(like I can't talk about darcs) because I have never used them. SVN
has the big deficit of not being distributed, which is an essential
point IMHO.

> Another word to the discussion. Switching to git doesn't fix the biggest
> problems in patch interaction. I forked some projects and sent patches to
> their core, just to find out that they were inable to discuss the problems
> at hand. In that respect, the o so nice distributed model kind of never
> worked for me, because the theory didn't match with reality. If I see people
> complaining about patches that never get applied: thats no SVN problem.

Ah, that's for sure. No tool can supplant the availability of
developers at incorporating patches from the outside. However, git
_does_ make it easier to (1) keep private branches (2) rebase them (3)
publishing the changes for others.

> If they have to maintain their own branch and rebase it on head: git-svn
> solves this problem already. So I don't see the point where git and only git
> suddently makes ruby better.

Well, git-svn doesn't solve the problem optimally, as it's somewhat
clumsier to use than plain git, so having a git repository to begin
with is definitely better, even if you just have to keep your own
patches there forever. It also makes it easier for _others_ to rely on
your changes on top of the official git (not svn) repository. This is
why I say that having an official git repository, even if for the time
being it's just a mirror of the svn repo, is an important step in the
right direction.

On 08.01.2009, at 15:24, Giuseppe Bilotta wrote:

> As I said, I haven't used darcs, but it being the default way of
> interaction means what? That the most documented function to transfer
> patches is cherry-pick instead of (semi)automatic merge?


Imagine that in git all the commands that take -i switch (commit,
merge, rebase, ...) use it by default,
and you pick hunks/patches all the time.

I personally found it annoying, but some like it.

MK