Git allows you to define a custom hunk-header which'll be used by git diff as the context line in diff hunks. Git includes presets for several languages but no presets for Perl and Perl 6. I'd like to change that.

If you have no idea what these are, consider a file that contains this code:

sub foo {
    my $x = "a";
    my $y = "b";
    my $z = "c";
    my $poem = <<"POEM";
This is a
Long string
In a heredoc
POEM
    I'm::On::A::Horse();
}

Now, if you change the last statement in that subroutine to something more clever and run git diff you'll get this:

diff --git a/file.pl b/file.pl
index 7ed4207..ffb1ff9 100644
--- a/file.pl
+++ b/file.pl
@@ -7,5 +7,5 @@ This is a
 Long string
 In a heredoc
 POEM
-    I'm::On::A::Horse();
+    The::Tickets::Are::Now::Diamonds();
 }

In that diff this is the context line:

@@ -7,5 +7,5 @@ This is a

Having "This is a" there doesn't provide very useful context, but that can be changed with userdiff, just add this to .gitattributes:

*.pl diff=perl

And this to .git/config:

[diff "perl"]
      xfuncname = "^\\s*(sub.*)"

And the hunk context is now more useful, and shows the name of the subroutine that's being changed:

@@ -7,5 +7,5 @@ sub foo {

I'd like to extend the Git defaults to include Perl, but I'm probably forgetting some cases where something is subroutine-ish that doesn't match simply "\\s*(sub.*)". Other cases I can think of are:

• The package statement
• my $x = sub { ... } (needs a complex regex to match `my/our ...)
• The BEGIN/INIT/END etc. routines
• Maybe "method ..." from MooseX::Declare and friends? It shouldn't hurt to include this
• Something else?

Then there's the issue of Perl 6. I'm completely unfamiliar with it, but I can add it while I'm at it if I'm given some examples.

The userdiff facility also has support for defining a "word" for the --word-diff option to git diff. I don't use this option, but I wouldn't be surprised if it did the wrong thing for Perl code.

In May I decided to stop using Debian's perl 5.10.1 in favor of using a 5.13.1 built with perlbrew, and CPAN modules built with cpanminus. It's been great, here's how I did it.

Before switching over I ignored Debian's perl library packages, and installed everything with cpanm into /usr/local. But since I wanted to use the new post-5.10 features of Perl I thought I might as well replace all of it and use a newer perl.

What I did:

• Created a v-perlbrew user. All users on the server can use this centrally managed Perl and its modules
• Added this to everyone's .bashrc: test -f ~/perl5/perlbrew/etc/bashrc && source ~/perl5/perlbrew/etc/bashrc
• Made a list of CPAN modules that I need. When I upgrade the perlbrew perl I can just run grep -v ^# cpan-modules | cpanm to get all the required modules with the new perl.
• Ran around changing PATH in crontabs, Apache settings etc. so that everything that isn't internal to Debian itself uses perlbrew's perl instead of /usr/bin/perl.

Getting the PATHs right everywhere turned out to be the hardest part. A lot of things in Debian have a path like /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin. I haven't found out how to change that, presumably some of them are hardcoded into executables like bash.

To get around that I have to hardcode the PATH to perlbrew in every crontab that uses perl. For a full list of these and other changes I've made the output of git --git-dir /etc/.git log -p --reverse -Sperlbrew available as a Gist.

The only caveat I've encountered is that there's one global perlbrew bashrc in ~/perl5/perlbrew/etc/bashrc. So if I can't use perlbrew switch to only switch some users onto a given perl. It would be neat if perlbrew supported having the current symlinks in a local ~/perl5 while the actual binaries and modules were in ~v-perlbrew/perl5.

I have an RFC patch series to Git to add gettext localization support to it. So that eventually you'll be able to configure Git to e.g. shout error messages at you in German. Won't that be a nice variant of the current abuse? I think so.

Here's the latest version of the patch series I posted to the Git mailing list.

For the Perl side of things (Git is partially implemented in Perl) I'm using libintl-perl's Locale::Messages. It was very pleasant to work with it. I wonder why more Perl projects don't use it instead of Perl-y libraries like Locale::Maketext.

Maybe it's just the GNU gettext dependency they're trying to get rid of, although libintl-perl includes a Pure-Perl version of the tools it provides .mo, so probably not.

Actually the way most open source projects do localization is "not at all". I don't blame them, I certainly can't be bothered most of the time. But I wonder to what degree we're losing potential users & contributors because of this.

There was a recent-ish study of social networks on GitHub where it was evident that a lot of Japanese Perl users had formed a social-ghetto amongst themselves. I've seen a few trending Perl repositories that only have README files in Japanese.

Maybe better localization tools - and most of all - a commitment to use them would help to bridge some of that.