Perl Migrates To the Git Version Control System

Posted by Soulskill on Sunday January 4, 2009 @04:53AM from the git-on-up dept.

On Elpeleg writes "The Perl Foundation has announced they are switching their version control systems to git. According to the announcement, Perl 5 migration to git would allow the language development team to take advantage of git's extensive offline and distributed version support. Git is open source and readily available to all Perl developers. Among other advantages, the announcement notes that git simplifies commits, producing fewer administrative overheads for integrating contributions. Git's change analysis tools are also singled out for praise. The transformation from Perforce to git apparently took over a year. Sam Vilain of Catalyst IT 'spent more than a year building custom tools to transform 21 years of Perl history into the first ever unified repository of every single change to Perl.' The git repository incorporates historic snapshot releases and patch sets, which is frankly both cool and historically pleasing. Some of the patch sets were apparently recovered from old hard drives, notching up the geek satisfaction factor even more. Developers can download a copy of the current Perl 5 repository directly from the perl.org site, where the source is hosted."

2 of 277 comments (clear)

Min score:

Reason:

Sort:

Re:But... is Perl now historical only? by berend+botje · 2009-01-04 05:00 · Score: 5, Insightful

I take it you have volunteered to help finish P6?
Re:I'd rather seen they moved to Subversion by timeOday · 2009-01-04 06:10 · Score: 5, Insightful

"you're saying they should use a big, slow, central server, as a single point of failure, crippling offline development..."
I am intrigued git and adoption by a major project like Perl is a big endorsement, so please don't take this as a rhetorical question: isn't centralization the heart of source code management? As a project lead, I'm reluctant to have repositories sprouting like mushrooms everywhere and everybody having their own little "trunk," and developers arguing who should have to merge with whom before each release. Is this reluctance totally unfounded, or easily solved administratively, or a valid concern with a peer-to-peer SCM model?