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

> 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 <[e-mail]> 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.
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