[ruby-core:21039] Happy new year and... moving Ruby development to Git?

[Eric Hodel]

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.

[Stephen Bannasch-3]

At 6:06 AM +0900 1/3/09, Charles Oliver Nutter wrote:

>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.

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.

[Charles Oliver Nutter-2]

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

[Nikolai Weibull-11]

On Sat, Jan 3, 2009 at 00:34, Eric Hodel <drbrain@...> 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?

[evolving_jerk]

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

[Hongli Lai-2]

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@...> 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.

--
Giuseppe "Oblomov" Bilotta

[evolving_jerk]

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@...> 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.

--
Giuseppe "Oblomov" Bilotta

[Jason Roelofs]

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

[Shane Emmons]

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.

--
Shane Emmons

[M. Edward (Ed) Borasky]

Michael Klishin wrote:

> 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.

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!

[M. Edward (Ed) Borasky]

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.

[Nikolai Weibull-11]

On Sat, Jan 3, 2009 at 21:40, M. Edward (Ed) Borasky <znmeb@...> 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.

[Eustáquio Rangel-2]

On Sat, Jan 3, 2009 at 6:40 PM, M. Edward (Ed) Borasky
<znmeb@...> 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,

[M. Edward (Ed) Borasky]

Nikolai Weibull wrote:

> On Sat, Jan 3, 2009 at 21:40, M. Edward (Ed) Borasky <znmeb@...> 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.

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.

[Nikolai Weibull-11]

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

> Nikolai Weibull wrote:

>> On Sat, Jan 3, 2009 at 21:40, M. Edward (Ed) Borasky <znmeb@...> 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@...> 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.

--
Giuseppe "Oblomov" Bilotta

[Marcelo Castellani]

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

[Joel VanderWerf]

Giuseppe Bilotta wrote:
> On Sat, Jan 3, 2009 at 10:39 PM, M. Edward (Ed) Borasky
> <znmeb@...> 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

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407