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

On Sun, Sep 6, 2009 at 19:20, Michal Suchanek<[e-mail]> wrote:
> 2009/9/6 mathew <[e-mail]>:
> It's true that git could use some polishing. It's not that hard to
> walk the tree and assign a monotonic revision numbers to each commit
> (as long as you have a sane single-rooted repo).
> The major disadvantage is that git is not really a high-level tool so
> you can (and must) see some of the low-level state of git even if you
> do not really want to, even for usual workflows. I can imagine this
> could be hidden with additional tools but these do not come with the
> standard distribution.
>
> However, git has some advantages over other tools. First it comes with
> the distributed awesomeness, of the distributed VCSs it is one of the
> more well known, it can switch between branches in one repo (which is
> not only space efficient but also better supports some workflows that
> would be harder if this was not possible) and it can intelligently
> call a pager like less when the output of a command requires it (which
> is still not possible with mercurial afaik).
>
> I think that git (or any half-decent distributed VCS) really makes the
> life easier for contributors because
> =C2=A0- rebase feature allows keeping small patches up to date really
> easily, and that's where a contributor typically starts
> =C2=A0- even large changes can be split to multiple patches that are easi=
er
> to keep up to date with rebase and easier to apply upstream separately
>
> With centralized VCS you typically get just one huge "local changes"
> patch which makes working with multiple changes quite hard.
>
> Unfortunately, git with its imperfections is probably going to be the
> de-facto standard for open-source development until some 5 years from
> now somebody finds they are really spending too much time working
> around small and larger deficiencies of the various VCS tools nobody
> cares to fix and writes a VCS v 2.1 ( in the sense CVS being around
> 1.0, SVN ~ 1.1, and git ~ 2.0).

I was originally going to stay silent on this but I guess it wouldn't
hurt to voice my thoughts a little since I think this thread has lost
its clarity.

First, I think it is primarily up to the core developers on what tools
they use. As it has been pointed out, there is nothing keeping people
from contributing. If it is harder than it could be, then lets work on
fixing that. I don't think we need to draw the conclusion that
changing the core's SCM is the only way to solve these problems. If
I'm wrong, then lets work that out when its shown to be so. I have no
doubt that this community can be more creative in solving this
conflict than we give ourselves credit for.

Second, I do think we are presupposing much more on the suitability of
all of these tool than is necessary. To remedy this, we should
encourage experimentation. If that means that official mirrors should
be designated and infrastructure put in place, great! We should be
able to try new things without resorting to chaos. Having official
blessings and likewise, the publication or labeling of such things
existing will help avoid confusion. I've been unsure which git repo to
base my work from but from this thread it seems we might have one,
lets make it clear and help stop guessing games.

Finally, for those who'd like to get more people using certain tools,
it would be more helpful if we were to set these things up and
document things. Help and encourage your fellow developers to try
things. If it doesn't work for them, don't insist they are wrong.

I think it will be much more likely that people will be happy to
switch later if they find things to be ready, but again, it isn't the
community's choice. I think the core team knows what the preferences
are but even better will be observation of how these experiments work
out.

Thank you / =E3=81=82=E3=82=8A=E3=81=8C=E3=81=A8=E3=81=86=E3=81=94=E3=81=96=
=E3=81=84=E3=81=BE=E3=81=99,
Brian.