The big advantage of Git::Wrapper is that it wraps the binary version of git, which keeps your perl and git independent. Upgrade perl and not git? Add Git::Wrapper and you're done. Upgrade git while keeping your existing perl? No problem. If you get your git from an OS distribution package, but roll your own perl, then Git::Wrapper is for you!

Git::Wrapper just makes it really easy to pass git commands and get back useful data. It really shines on "git log" commands, as it parses each commit message into Git::Wrapper::Log objects with accessors for id, author, date, and message. For everything else, it's not much more than a wrapper around qx(), but it returns arrays of lines and throws exceptions when things go wrong, which just saves a little time and code.

Here is a short example that I whipped up recently to automate the process of adding a github repository remote for someone when they send me a pull request. (It also uses my Getopt::Lucid module, but as the name suggests, it should be clear what that does.)

#!/usr/bin/env perl
use 5.010;
use strict;
use warnings;
use autodie;
use Git::Wrapper;
use Getopt::Lucid qw/:all/;

# USAGE: github-remote [-r REPO] [NAME]
#     NAME -- a github user name (or defaults to 'dagolden')
#     REPO -- a github repository path (or is parsed out of my private origin repo)

my $opts = Getopt::Lucid->getopt([
  Param('repo|r'),
]);

my $who = shift @ARGV;

# Get a wrapper for the current directory
my $git = Git::Wrapper->new(".");

# Locate the origin repository URL
my ($origin) = grep { /origin/ } $git->remote("-v");
die "Couldn't determine origin\n" unless $origin;
$origin =~ s/^origin\s+//;
$origin =~ s/\s+\(.*$//;

# Parse out the repository path
my $repo = $opts->get_repo;
unless ( $repo ) {
  # me@git.example.com:my-repo-name.git
  ($repo) = $origin =~ m/^[^:]+:(.+)$/;
}

# Set up someone else's github repo
if ( $who ) {
  $git->remote("add", $who, "git://github.com/${who}/${repo}");
}
# Or set up my own github mirror
else {
  $git->remote("add", "github", "git\@github.com:dagolden/${repo}");
}

That's it. I admit the program is a little crufty because of how I manage my repositories with a private origin that I mirror to a github repository, but there's almost no cruft around interactions with git. Consider this:

  $git->remote("add", $who, "git://github.com/${who}/${repo}");

If the command fails (if there's already $who as a remote name), an exception will be thrown. That means I don't have to write any error handling myself, which is perfect for a simple automation program like this one.

The new repository is available publicly on github.com:

• Browse the repository
• Clone it: git://github.com/dagolden/module-build.git

I have done my best to clean up the merge/branch/tag history, but have not bothered to clean up empty commits left over from the original cvs2svn conversion. If anyone sees any glaring errors please let me know.

I hope this migration makes it easy for people to contribute to Module-Build. I was pleasantly surprised to find that within 12 hours of it being publishing on github, it's already being watched by several people.

At the very least, it will make working on feature branches much easier to manage, which will make it easier to experiment with new ideas without affecting the main line of development.

If anyone would like to start applying patches from the Module::Build bug queue, or creating patches for other open tickets, that would be huge help.

I will be "closing out" the old Subversion repository with a pointer to the new location shortly.

Once I had taught git to ignore .svn directories and taught svn to ignore .git and .gitignore, I imported the whole project to git and proceeded with my normal workflow, creating separate branches for different things I was working on.

Once I was back online, I wanted to merge my work back to the subversion tree, while still preserving the commit history from when I was offline. A short bit of Perl programming later and I was done. For each of the git branches I had created, I generated a series of patch emails with "git format-patch". Then, after having subversion revert all files back to the latest commit, I passed the patches on the command line to this program:

#!/usr/bin/env perl
use 5.010;
use strict;
use warnings;
use Email::Simple;
use Path::Class;
use File::Temp;

die "$0: This is not an svn repo\n"
  unless -d '.svn';

for my $f (sort @ARGV) {
  say "*** $f ***";
  # try to apply patch
  system("patch -p1 < $f");
  die "Patch failed!  Aborting!\n" if $?;

  # extract commit info
  my $email = Email::Simple->new( scalar file($f)->slurp );
  my $subject = $email->header("Subject");
  $subject =~ s{^\[PATCH[^\]]*\]\s+}{};
  my $body = $email->body;
  $body =~ s{\A(.*?)---.*$}{$1}ms;

  # write commit info to tempfile and commit it
  my $temp = File::Temp->new;
  say {$temp} $subject;
  print {$temp} "\n$body" if $body;

  system("svn commit -F $temp");
  die "Commit failed!  Aborting!\n" if $?;
}

I wouldn't want this kind of hybrid VCS to be part of my regular workflow, but in a pinch when I wanted offline version control, it worked remarkably well.

• ExtUtils::CBuilder -- This is the complement to ExtUtils::ParseXS, which I described converting last week. Anyone interested in working on it, please see the bug queue.
• The CPAN META.yml spec -- this isn't exactly a module, but extracting it from the Module::Build repository is a first step towards some needed improvements. I have some things in development on that front that I hope to announce in a week or so.

I don't know if that's the start of a trend or not, but it's food for thought for anyone who questions whether git makes contributing easier.  As a publisher, git means no need to centrally administer repository access.  As a contributor, it means no need to request repository access (and wait for it to be granted).  And for both, it means no need to manage patches outside the VCS.  I'm convinced that making it easier for people to contribute means greater odds of getting contributions.

On the technical side, this was not the easiest conversion and I learned a lot about git history rewriting during the cleanup.  Some of the highlights:

• I used a modified clone of Schwern's svn2git.pl port of the ruby svn2git program
• I manually fixed up "tag branches" where the history was confused, but I could identify the release point.  (Confirmed by identifying where there was no diff between tag branch and a point on the trunk branch)
• I rewrote historical commits to fix empty commit messages

This latter one was a multi-part fix.  Some commit entries said "*** empty log message ***'.  Others were literally empty.   Worse, the very first commit was the "*** empty ..." one.  git rebase is the normal tool for fixing up history, but rebase can't change the root commit.  I worked around it following these instructions:

• I created an empty commit on a new branch as a rebase target
• I cherry-picked the first commit from the trunk onto the new branch
• I interactively rebased the trunk onto the new branch (picking up everything after the cherry picked commit)

The interactive rebase gave me a list of commits and message synopses.  I changed all the "*** empty ..." ones from "pick" to "edit".  For the entirely empty ones, they showed up strangely in the rebase list, where ce86d39 was the empty commit and parent to f4a7235  with the log message shown:

pick ce86d39 >f4a7235 blah blah blah

It turns out the way to rebase this is to just break them apart:

edit ce86d39
pick f4a7235 blah blah blah</pre>

Then, during the rebase run, when it would stop on "*** empty ..." commits, I would amend the commit message with a list of files changed (a lazy fix, I'll admit) and continue:

$ git diff --name-only HEAD^ | \
  perl -E 'say "Updated " . join(q{, }, map { chomp; $_} <>)' | \
  git commit --amend --file=- && git rebase --continue

Voila -- very lazy empty log editing.  In the blank message cases, the rebase commit itself fails due to the empty message, but I could do a direct  "git commit" (not amend because the rebase cherry-pick commit failed), give an appropriate log message, and then "git rebase --continue".

After that was done, the history was great, but the tags were still on the old messy branch.  But that was easy to fix with a little Perl programming:

• I wrote a program to take a list of commits and tags and migrate the tags to the new branch where a commit in the new branch matches a previously tagged commit (i.e. in the old branch)

This would have been more complex if there had been merges to consider and I'm glad there weren't.  But the end result was a nice clean, well-tagged git history.