[PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing

From: Benoit Person <redacted>

The #7 issue on git-mediawiki's issue tracker [1] states that the ability to
preview content without pushing would be a nice thing to have.

This commit is a first attempt to achieve it. It adds a new git command,
named `git mw`. This command accepts the subcommands `help` and `preview`
for now.

The default behaviour for the `preview` subcommand is:
1- Find the remote name of the current branch's upstream and check if it's a
wiki one with its url (ie: mediawiki://)
2- Parse the content of the local file (given as argument) using the distant
wiki's API.
3- Retrieve the current page on the distant mediawiki.
4- Merge those those contents.
5- Convert relative links to absolute ones.
6- Save the result on disk.

The command also accepts argument for more controls:
  --autoload | -a tries to launch the newly generated file in the user's 
                  default browser
  --remote | -r provides a way to select the distant mediawiki in which the 
                user wants to preview his file.
  --output | -o enables the user to choose the output filename. Default output 
                filename is based on the input filename in which the extension
                `.mw` is replaced with `.html`.

It works but a couple of points trouble me: 
1-  I had to copy two functions from `git-remote-mediawiki.perl`, I don't 
    really know how we could "factorize" those things ? I don't think it makes 
    much sense to create a package just for them ?
2-  The current behavior is to crash if the current branch do not have an
    upstream branch on a valid mediawiki remote. To find that specific remote, 
    it runs `git rev-parse --symbolic-full-name @{upstream}` which will return 
    something like `/refs/remotes/$remote_name/master`.
  2a-  maybe there is a better way to find that remote name ?
  2b-  would it be useful to add a fallback if that search fails ? searching 
       for a valid mediawiki remote url in all the remotes returned by 
       `git remote` for instance ?
3-  The current idea of merging the content of the mediawiki's current page 
    with new content fails when the page is a local creation. (Hence the 
    error message when we get a bad result from the `get` call l.129). I 
    thought about two ways to overcome this:
  3a-  Use the wiki's homepage for the template.
  3b-  A two-step process:
       - first we create a general template (based on the wiki's homepage) 
         with a specific flag at the content position. This step is done only 
         if that template do not exists locally.
       - replace the specific flag with the newly parsed content.
       The downfall of those two "solutions" is on links like 'talk', 
       'view source' etc ... those will need to be updated to. And evven then, 
       it will still fails for page created only locally.
4-  In the Makefile, there is certainly a more "Makefily" way to do it but I 
    had no luck finding it and still preserving the factorization for the 
    `build`, `install` and `clean` target. I ended up with something like this:

    build: $(BUILD_SCRIPTS)
    $(BUILD_SCRIPTS):
        $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$@ \
                build-perl-script

    install: ...
    clean: ...

    but clearly, for only two scripts, it's more a refucktoring than a 
    refactoring :/ .

[1] https://github.com/moy/Git-Mediawiki/issues/7


Signed-off-by: Benoit Person <redacted>
Signed-off-by: Matthieu Moy <redacted>

---
 contrib/mw-to-git/Makefile    |   4 +
 contrib/mw-to-git/git-mw.perl | 249 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 253 insertions(+)
 create mode 100644 contrib/mw-to-git/git-mw.perl

diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index f149719..0cba1e3 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile

@@ -5,13 +5,17 @@
 ## Build git-remote-mediawiki
 
 SCRIPT_PERL=git-remote-mediawiki.perl
+SCRIPT_PERL_MW=git-mw.perl
 GIT_ROOT_DIR=../..
 HERE=contrib/mw-to-git/
 
 SCRIPT_PERL_FULL=$(patsubst %,$(HERE)/%,$(SCRIPT_PERL))
+SCRIPT_PERL_MW_FULL=$(patsubst %,$(HERE)/%,$(SCRIPT_PERL_MW))
 
 all: build
 
 build install clean:
 	$(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
                 $@-perl-script
+	$(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_MW_FULL) \
+                $@-perl-script

\ No newline at end of file

diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
new file mode 100644
index 0000000..a92c459
--- /dev/null
+++ b/contrib/mw-to-git/git-mw.perl

@@ -0,0 +1,249 @@
+#! /usr/bin/perl
+
+# Copyright (C) 2013
+#     Benoit Person <benoit.person@ensimag.imag.fr>
+#     Celestin Matte <celestin.matte@ensimag.imag.fr>
+# License: GPL v2 or later
+
+# Tools attached to git-remote-mediawiki (help, preview ...)
+# Documentation & bugtracker: https://github.com/moy/Git-Mediawiki/
+
+use strict;
+use warnings;
+
+use Git;
+use MediaWiki::API;
+
+use Getopt::Long;
+use HTML::TreeBuilder;
+use URI::URL qw(url);
+use IO::File;
+use LWP::Simple;
+use Carp;
+use Readonly;
+
+# Constants
+# Mediawiki filenames can contain forward slashes. This variable decides by which pattern they should be replaced
+Readonly::scalar $SLASH_REPLACEMENT => "%2F";
+
+# Vars
+my $file_name;
+my $wiki;
+my $remote_url;
+
+my $remote_name = '';
+my $preview_file_name = '';
+my $autoload = 0;
+
+my %commands = (
+	'help' =>
+		[\&help, {}, \&help_help],
+	'preview' =>
+		[\&preview, {
+			'<>' => \&file,
+			'output|o=s' => \$preview_file_name,
+			'remote|r=s' => \$remote_name,
+			'autoload|a' => \$autoload
+		}, \&preview_help]
+);
+
+sub file {
+	$file_name = shift;
+	return $file_name;
+}
+
+# Search for sub-command
+my $cmd = $commands{'help'};
+for (my $i = 0; $i < @ARGV; $i++) {
+	if (defined $commands{$ARGV[$i]}) {
+		$cmd = $commands{$ARGV[$i]};
+		splice @ARGV, $i, 1;
+		last;
+	}
+};
+GetOptions( %{$cmd->[1]},
+	'help|h' => \&{$cmd->[2]});
+
+# Launch command
+&{$cmd->[0]};
+
+######################## Sub-Commands #############################
+sub preview {
+	my $wiki_page_name;
+	my ($content, $content_tree, $template, $html_tree, $mw_content_text);
+
+	# file_name argumeent is mandatory
+	if (! defined $file_name) {
+		croak "File not set, see `git mw help` \n";
+	}
+
+	if (! -e $file_name) {
+		croak "File $file_name does not exist \n";
+	}
+
+	# Default preview_file_name is file_name with .html ext
+	if ($preview_file_name eq '') {
+		$preview_file_name = $file_name;
+		$preview_file_name =~ s/\.[^.]+$/.html/;
+	}
+
+	# Transform file_name into a mediawiki page name
+	$wiki_page_name = mediawiki_smudge_filename($file_name);
+	$wiki_page_name =~ s/\.[^.]+$//;
+
+	# Find or verify remote name
+	if ($remote_name eq '') {
+		$remote_name = git_cmd_try {
+			Git::command_oneline('rev-parse', '--symbolic-full-name', '@{upstream}') }
+			"%s failed w/ code %d";
+		$remote_name =~ s/refs\/remotes\/(.+)\/(.+)/$1/
+			or croak "Could not find remote name";
+	} else {
+		my @remotes = git_cmd_try {
+			Git::command('remote') }
+			"%s failed w/ code %d";
+		grep { $_ eq $remote_name } @remotes
+			or croak "$remote_name is not a remote";
+	}
+
+	# Find remote url
+	$remote_url = git_cmd_try {
+		Git::config("remote.$remote_name.url") }
+		"%s failed w/ code %d";
+	$remote_url =~ s/mediawiki::(.*)/$1/
+		or croak "Current remote is not a mediawiki";
+	$remote_url = url($remote_url)->canonical;
+
+	# Create and connect to the wiki if necessary
+	$wiki = MediaWiki::API->new;
+	$wiki->{config}->{api_url} = "$remote_url/api.php";
+	mw_connect_maybe();
+
+	# Read file content
+	open my $fh, "<", $file_name
+		or croak "could not open $file_name: $!";
+	my $document = do { local $/ = undef; <$fh> };
+	close $fh;
+
+	# Load template page
+	$template = get("$remote_url/index.php?title=$wiki_page_name")
+		or croak "You need to create $wiki_page_name before previewing it";
+	$html_tree = HTML::TreeBuilder->new;
+	$html_tree->parse($template);
+
+	# Load new content
+	$content = $wiki->api({
+		action => 'parse',
+		text => $document,
+		title => $wiki_page_name
+	}) or croak 'No response from distant mediawiki';
+	$content = $content->{'parse'}->{'text'}->{'*'};
+	$content_tree = HTML::TreeBuilder->new;
+	$content_tree->parse($content);
+
+	# Replace old content with new one
+	$mw_content_text = $html_tree->look_down('id', 'mw-content-text');
+	$mw_content_text->delete_content();
+	$mw_content_text->push_content($content_tree);
+
+	# Transform relative links into absolute ones
+	for (@{ $html_tree->extract_links() }) {
+		my ($link, $element, $attr) = @$_;
+		my $url = url($link)->canonical;
+		$element->attr($attr, URI->new_abs($url, $remote_url));
+	}
+
+	# Save the preview file
+	$fh = IO::File->new($preview_file_name, O_WRONLY|O_CREAT)
+		or croak "Could not open: $!";
+	$fh->print($html_tree->as_HTML);
+
+	# Auto-loading in browser
+	if ($autoload) {
+		open(my $browser, "-|:encoding(UTF-8)", "xdg-open ".$preview_file_name);
+		my $res = do { local $/ = undef; <$browser> };
+		close($browser);
+	} else {
+		print "preview file saved as: $preview_file_name\n";
+	}
+
+	exit;
+}
+
+######################## Help Functions ###########################
+
+sub help {
+	print <<'END';
+usage: git mw <command> <args>
+
+git mw commands are:
+    Help        Display help information about git mw
+    preview     Render a local file into an HTML file
+END
+	exit;
+}
+
+sub help_help {
+	print <<'END';
+usage: git mw help
+END
+	exit;
+}
+
+sub preview_help {
+	print <<'END';
+usage: git mw preview [--remote|-r <remote name>] [--autoload|-a]
+                      [--output|-o <output filename>] <filename>
+
+    -r, --remote    Specify which mediawiki should be used
+    -o, --output    Name of the output file
+    -a, --autoload  Try to autoload the page in the default browser
+END
+	exit;
+}
+
+########################## Functions ##############################
+
+sub mediawiki_smudge_filename {
+	my $filename = shift;
+	$filename =~ s/\//@{[$SLASH_REPLACEMENT]}/gx;
+	$filename =~ s/ /_/g;
+	# Decode forbidden characters encoded in mediawiki_clean_filename
+	$filename =~ s/_%_([0-9a-fA-F][0-9a-fA-F])/sprintf("%c", hex($1))/gex;
+	return $filename;
+}
+
+sub mw_connect_maybe {
+	my ($wiki_login, $wiki_password, $wiki_domain);
+
+	git_cmd_try {
+		$wiki_login = Git::config("remote.$remote_name.mwLogin");
+		$wiki_password = Git::config("remote.$remote_name.mwPassword");
+		$wiki_domain = Git::config("remote.$remote_name.mwDomain");}
+		"%s failed w/ code %d";
+
+	if ($wiki_login) {
+		my %credential = (
+			'url' => $remote_url,
+			'username' => $wiki_login,
+			'password' => $wiki_password);
+		Git::credential(\%credential);
+		my $request = {
+			lgname => $credential{username},
+			lgpassword => $credential{password},
+			lgdomain => $wiki_domain};
+		if ($wiki->login($request)) {
+			Git::credential(\%credential, 'approve');
+			print STDERR "Logged in mediawiki user \"$credential{username}\".\n";
+		} else {
+			print STDERR "Failed to log in mediawiki user \"$credential{username}\" on $remote_url\n";
+			print STDERR "  (error " .
+				$wiki->{error}->{code} . ': ' .
+				$wiki->{error}->{details} . ")\n";
+			Git::credential(\%credential, 'reject');
+			exit 1;
+		}
+	}
+
+	return;
+}

\ No newline at end of file
-- 
1.8.3.rc3.7.gc2f33ed.dirty

On Fri, Jun 07, 2013 at 11:50:31PM +0200, benoit.person@ensimag.fr wrote:

The #7 issue on git-mediawiki's issue tracker [1] states that the ability to
preview content without pushing would be a nice thing to have.

Sounds like a useful goal.

The default behaviour for the `preview` subcommand is:
1- Find the remote name of the current branch's upstream and check if it's a
wiki one with its url (ie: mediawiki://)
2- Parse the content of the local file (given as argument) using the distant
wiki's API.

Makes sense.

3- Retrieve the current page on the distant mediawiki.
4- Merge those those contents.

I'm not sure what these steps are for. You are trying to preview not
just your local version, but pulling in any changes that have happened
upstream since the work you built on top of?

It seems like that is a separate, orthogonal issue, and git would be the
right place to do that merge. IOW, as a user, your workflow would be
something like:

  1. git fetch, pulling down the latest copy from the server

  2. make your changes on top

  3. use this command to preview your changes

  4. use git fetch to check whether anything else happened on the
     server.

       a. If not, go ahead and push.

       b. If upstream changed, use "git diff" to inspect the changes to
          the wiki source. Merge or rebase your changes with respect to
          what's on the server. Goto step 3 to make sure they look good.

I also wonder if it would be useful to be able to specify not only files
in the filesystem, but also arbitrary blobs. So in 4b above, you could
"git mw preview origin:page.mw" to see the rendered version of what
upstream has done.

It works but a couple of points trouble me: 
1-  I had to copy two functions from `git-remote-mediawiki.perl`, I don't 
    really know how we could "factorize" those things ? I don't think it makes 
    much sense to create a package just for them ?

You could make a Git::MediaWiki.pm module, but installing that would
significantly complicate the build procedure, and potentially be
annoying for users. One trick I have done in the past is to concatenate
bits of perl script together in the Makefile, like this:

  foo: common.pl foo.pl
          { \
            echo '$(PERL_PATH_SQ)' && \
            for i in $^; do \
              echo "#line 1 $src" && \
                cat $src \
            done \
          } >$@+
          mv $@+ $@

That would conflict a bit with the way we chain to git's Makefile,
though. I suspect you could do something complicated like build "foo.pl"
from "common.pl" and "foo-main.pl", then chain to git's Makefile to
build "foo" from "foo.pl".

2-  The current behavior is to crash if the current branch do not have an
    upstream branch on a valid mediawiki remote. To find that specific remote, 
    it runs `git rev-parse --symbolic-full-name @{upstream}` which will return 
    something like `/refs/remotes/$remote_name/master`.
  2a-  maybe there is a better way to find that remote name ?

If you just care about the remote name and not the name of the local
branch, you can just ask for

  my $curr_branch = `git symbolic-ref HEAD`;
  my $remote = `git config "branch.$curr_branch.remote"`;
  my $url = `git config "remote.$remote.url"`;

Of course you would want some error checks and probably some chomp()s in
there, too.

  2b-  would it be useful to add a fallback if that search fails ? searching 
       for a valid mediawiki remote url in all the remotes returned by 
       `git remote` for instance ?

That is probably OK as long as there is only one such remote, and it
would help the case where you have branched off of a local branch (so
your upstream remote is ".").  If there are two mediawiki remotes,
though, it would make sense to simply fail, as you don't know which to
use. But I'd expect the common case by far to be that you simply have
one such remote.

-Peff

On 9 June 2013 08:08, Jeff King [off-list ref] wrote:

I also wonder if it would be useful to be able to specify not only files
in the filesystem, but also arbitrary blobs. So in 4b above, you could
"git mw preview origin:page.mw" to see the rendered version of what
upstream has done.

Hum, so `git mw preview origin:page.mw` would just do the get
request to the remote mediawiki, save it locally and - maybe - load it
in the browser ? Is it really better than just opening the browser and
typing the right URL ?

Currently, this URL is one click away when you have preview file loaded
in a web browser.

quoted

It works but a couple of points trouble me:
1-  I had to copy two functions from `git-remote-mediawiki.perl`, I don't
    really know how we could "factorize" those things ? I don't think it makes
    much sense to create a package just for them ?

You could make a Git::MediaWiki.pm module, but installing that would
significantly complicate the build procedure, and potentially be
annoying for users. One trick I have done in the past is to concatenate
bits of perl script together in the Makefile, like this:

  foo: common.pl foo.pl
          { \
            echo '$(PERL_PATH_SQ)' && \
            for i in $^; do \
              echo "#line 1 $src" && \
                cat $src \
            done \
          } >$@+
          mv $@+ $@

That would conflict a bit with the way we chain to git's Makefile,
though. I suspect you could do something complicated like build "foo.pl"
from "common.pl" and "foo-main.pl", then chain to git's Makefile to
build "foo" from "foo.pl".

ok, thanks a lot.

quoted

2-  The current behavior is to crash if the current branch do not have an
    upstream branch on a valid mediawiki remote. To find that specific remote,
    it runs `git rev-parse --symbolic-full-name @{upstream}` which will return
    something like `/refs/remotes/$remote_name/master`.
  2a-  maybe there is a better way to find that remote name ?

If you just care about the remote name and not the name of the local
branch, you can just ask for

  my $curr_branch = `git symbolic-ref HEAD`;
  my $remote = `git config "branch.$curr_branch.remote"`;
  my $url = `git config "remote.$remote.url"`;

Of course you would want some error checks and probably some chomp()s in
there, too.

The fact is, `git symbolic-ref HEAD` result would have to be parsed in order
to extract the current branch name like I currently extract the remote name.
So, is it really better than `git rev-parse --symbolic-full-name @{upstream}` ?

quoted

  2b-  would it be useful to add a fallback if that search fails ? searching
       for a valid mediawiki remote url in all the remotes returned by
       `git remote` for instance ?

That is probably OK as long as there is only one such remote, and it
would help the case where you have branched off of a local branch (so
your upstream remote is ".").  If there are two mediawiki remotes,
though, it would make sense to simply fail, as you don't know which to
use. But I'd expect the common case by far to be that you simply have
one such remote.

Well, I thought that `git mw preview` could provide an interactive mode
where, if the first search fails, it would find all the mediawiki remotes, and
offers to the user a way to choose the remote ?

Benoit Person

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sun, Jun 09, 2013 at 02:35:45PM +0200, Benoît Person wrote:

On 9 June 2013 08:08, Jeff King [off-list ref] wrote:

quoted

I also wonder if it would be useful to be able to specify not only files
in the filesystem, but also arbitrary blobs. So in 4b above, you could
"git mw preview origin:page.mw" to see the rendered version of what
upstream has done.

Hum, so `git mw preview origin:page.mw` would just do the get
request to the remote mediawiki, save it locally and - maybe - load it
in the browser ? Is it really better than just opening the browser and
typing the right URL ?

Not really, but when you start doing "origin^:page.mw", it may make more
of a difference.

quoted

If you just care about the remote name and not the name of the local
branch, you can just ask for

  my $curr_branch = `git symbolic-ref HEAD`;
  my $remote = `git config "branch.$curr_branch.remote"`;
  my $url = `git config "remote.$remote.url"`;

Of course you would want some error checks and probably some chomp()s in
there, too.

The fact is, `git symbolic-ref HEAD` result would have to be parsed in order
to extract the current branch name like I currently extract the remote name.
So, is it really better than `git rev-parse --symbolic-full-name @{upstream}` ?

It is, because it is not strictly true that an upstream of
"refs/remotes/foo/*" is for the remote "foo" (though in 99% of cases, it
is). To find the upstream, git looks at branch.$curr_branch.remote, then
calculates the upstream based on the fetch refspecs. Then you try to
undo that by converting it back from the right-hand side of the fetch
refspec into a remote name. It would be much easier to just look at the
config. :)

And yes, you do need the short name of the branch from HEAD, not the
full refname. You can use "git symbolic-ref --short" for that. You also
should check that it returns something useful (i.e., that we are not on
a detached HEAD).

quoted

That is probably OK as long as there is only one such remote, and it
would help the case where you have branched off of a local branch (so
your upstream remote is ".").  If there are two mediawiki remotes,
though, it would make sense to simply fail, as you don't know which to
use. But I'd expect the common case by far to be that you simply have
one such remote.

Well, I thought that `git mw preview` could provide an interactive mode
where, if the first search fails, it would find all the mediawiki remotes, and
offers to the user a way to choose the remote ?

That's fine; just as long as we do not silently produce output from an
unknown source when there is ambiguity.

You can do an interactive selection, or even just say something like:

  There are multiple mediawiki remotes, and I do not know which one you
  want to use for your preview. Which of:

    remote1
    remote2

  did you mean? Try using the "-r" option to specify the remote.

and then let the user repeat their command with the "-r" option using
shell history. That saves you from having to write an interactive
component, and teaches the user how to script it.

-Peff

The V2 is on the launchpad but I am still struggling with the code
factoring between git-mw.perl and git-remote-mediawiki.perl :/ .

On 9 June 2013 08:08, Jeff King [off-list ref] wrote:

You could make a Git::MediaWiki.pm module, but installing that would
significantly complicate the build procedure, and potentially be
annoying for users. One trick I have done in the past is to concatenate
bits of perl script together in the Makefile, like this:

  foo: common.pl foo.pl
          { \
            echo '$(PERL_PATH_SQ)' && \
            for i in $^; do \
              echo "#line 1 $src" && \
                cat $src \
            done \
          } >$@+
          mv $@+ $@

That would conflict a bit with the way we chain to git's Makefile,
though. I suspect you could do something complicated like build "foo.pl"
from "common.pl" and "foo-main.pl", then chain to git's Makefile to
build "foo" from "foo.pl".

I've implemented this one for now but after a real-life meeting with
Matthieu Moy we discussed the possibility to build a GitMediawiki.pm
module. It seems more "clean" than the concatenation of perl scripts.
Plus, it would force people to limit side effects inside the functions
used in this package/utils file (I have in mind the mw_connect_maybe
function here and a couple of others which directly *hope* for global
vars to be set to a nice value before being called).

What I find bad in the concatenating-thingy is the mandatory rename of
git-mw.perl into something like git-mw.unmerged.perl and
git-remote-mediawiki.perl into git-remote-mediawiki.unmerged.perl.
Otherwise, like you said, it would be hard to chain to git's Makefile
after the merge.

For now, I have really no idea which one is the best. If I may ask,
what did you have in mind while saying:

You could make a Git::MediaWiki.pm module, but installing that would
significantly complicate the build procedure, and potentially be
annoying for users.

?

Since my previous commit (ea07ec1 in next - use Git.pm functions for
credentials), git-remote-mediawiki.perl already depends on the proper
installation of the Git.pm package. In what ways the need for the
installation of yet another package (GitMediawiki.pm) would annoy a
user ?

Thank you for your time,

Benoit

On Tue, Jun 11, 2013 at 11:31:31PM +0200, Benoît Person wrote:

I've implemented this one for now but after a real-life meeting with
Matthieu Moy we discussed the possibility to build a GitMediawiki.pm
module. It seems more "clean" than the concatenation of perl scripts.
Plus, it would force people to limit side effects inside the functions
used in this package/utils file (I have in mind the mw_connect_maybe
function here and a couple of others which directly *hope* for global
vars to be set to a nice value before being called).

What I find bad in the concatenating-thingy is the mandatory rename of
git-mw.perl into something like git-mw.unmerged.perl and
git-remote-mediawiki.perl into git-remote-mediawiki.unmerged.perl.
Otherwise, like you said, it would be hard to chain to git's Makefile
after the merge.

Yeah, I agree it's very hacky.

For now, I have really no idea which one is the best. If I may ask,
what did you have in mind while saying:

quoted

You could make a Git::MediaWiki.pm module, but installing that would
significantly complicate the build procedure, and potentially be
annoying for users.

Since my previous commit (ea07ec1 in next - use Git.pm functions for
credentials), git-remote-mediawiki.perl already depends on the proper
installation of the Git.pm package. In what ways the need for the
installation of yet another package (GitMediawiki.pm) would annoy a
user ?

I was thinking that you would be self-contained inside the
contrib/mw-to-git directory, and therefore you would have to teach your
code how to install the Git module, and you could not longer just "cp
git-remote-mediawiki" into the right place to install it.

But I think we have already crossed that bridge somewhat with Git.pm.
And if you add your module as perl/Git/MediaWiki.pm and use the existing
perl build system, then it is not any extra effort from the build
system.

That is probably the most sane way to go.

-Peff