Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Perl5 should switch to using Git as its main source control 14 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I've been involved with the git community since the beginning, and in fact serve as the "canary in the mine" when it won't work cleanly on OpenBSD or OSX, and provide occasional guidance for the small parts that are written in Perl (the remainder is in C and some shell).

    I have been using git to track the Perl6 docs and Parrot development trees (similar to the way people use svk) so that I can see the entire project history when I'm offline (like at 30K feet in an airplane).

    To come up to speed quickly on

    --
    • Randal L. Schwartz
    • Stonehenge
    • Encouraging a Native Win32 would be really useful. Projects that are platform agnostic (as many non OS project are) need portability in general and with Win32 specifically because of its market penetration.

      I realize asking a bunch of Linux people to keep Win32 development in mind is hardly politically popular, but it would go a long way to making Git more appropriate for projects like Perl. Consider we have active contributors doing dev and testing on pretty much everything you can imagine. The more widely

  • While Perforce's readonlyness and the limited supply of licenses bothers me too (rsync just does not cut it, while I have patches waiting in my tree), doing something that makes it even more difficult for Win32 programmers to participate seems to me to be a very bad idea.

    I can barely get feedback from Win32 users on my pure-Perl modules; it's difficult to believe that there are any Win32 programmers interested in using Perl and willing to install both Cygwin and Git to get at the source code.

    • All I can say in reply to that is that Im one of a very small group of active contributors to Perl5 that uses Win32. And if it doesnt bother me, I'm not too sure why it should bother anybody else. Egotistical I guess, but hey, disk space is cheap, and installing cygwin is easy.

      Also, I tend to think that anybody doing serious OpenSource dev on Win32 has Cygwin installed anyway. Its just too useful and too much of pain to get the required toolsets working from elsewhere.

      But, I have to say I dont see how we ge

      • I have to agree that if you want to change it then whatever you replace it with needs to be Win32 friendly and not the "cygwin" variety of Win32.

        • Id love to know why. I mean, whats the difference between installing an app that links against the cygwin dll's and something that links against some custom active-x object or whatnot?

          From a end user experience, I go to the Cygwin setup tool, select git, procede with the install and I'm done. I then go to my shell and follow the tutorial for using git and it all apears to work just fine.

          So whats the objection?
          • My personal objection to Cygwin is that it seems to mess with both Windows- and Unix specific line endings. Sometimes it just gets it wrong, and then you're in deep shit. A lot of the trouble people appear to be having specifically under Cygwin, appear to be linked to this issue.

            One step back, please, Cygwin seems to go just a bit too far.

            And I actually like bash. I don't know the difference with the other Unix shells, but I do like it.

            • I've seen issues when you use the "use windows line endings" option, but otherwise not. And afaik git treats all files as binary blobs so it shouldnt mess with line endings at all.

              • afaik git treats all files as binary blobs so it shouldnt mess with line endings at all.

                That's not my definition of "properly handling line endings". A version control system that doesn't treat a change of line endings as a simple file attribute change (a meta change), is not doing the proper thing, IMO. And many don't. Most treat this as a change on every single line.

                It's simple enough. If an assumed text file contains plenty LF characters and not a single CR character, then it's a Unix file. If it only contains pairs of CR+LF characters, no other bare CR nor LF characters, then it's a "DOS"

                • How relevent is this tho? All the perl source files use unix line endings, even the win32 specific ones.

          • I hate the way Cygwin tries to map the Windows drive letter fiasco to a Unixoid filesystem hierarchy. It grates on my sensitivities every step of the way when I try to use Cygwin.

            • Well, I've noticed that this seems to be shell related. If you use cmd /most/ apps seem to cope with windows paths properly. I'm not sure what the story is exactly. All I can say is that in my use patterns I encounter it rarely.

      • The last time I did any work on Windows, I used Cygwin as well, but that's because I was much more comfortable with Unix than Windows. I don't know if long-time Windows developers who've never really used Unix would feel the same need to install Cygwin that I did (and I can only guess at your background).

        I just feel leery about switching to a tool that doesn't yet have a native version on such an important platform where we don't attract many contributors. (I can only guess at how Git works on OS/2 and

        • The VMS crowd, however, is very stable minority of users. Unfortunately, they cannot use Perforce natively on recent VMS versions, specifically on Itaniums. There is actually a very limited number of platforms that can natively use the most recent version of Perforce. For example, support for AIX, OpenBSD, and IRIX seems to be dropping off. The lack of git on Win32, however, is much more concerning issue as this effects a large number of Perl users.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.