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 10 Comments More | Login | Reply /

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

  • 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.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.