{"thread":{"id":"34054","subject":"[PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","startedAt":"2013-06-07T21:50:31Z","lastAt":"2013-06-12T08:55:02Z","messageCount":14,"participants":["benoit.person@ensimag.fr","Matthieu Moy","Jeff King","Benoît Person"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"219740","messageId":"1370641831-9115-1-git-send-email-benoit.person@ensimag.fr","threadId":"34054","inReplyTo":null,"subject":"[PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"","fromEmail":"benoit.person@ensimag.fr","sentAt":"2013-06-07T21:50:31Z","receivedAt":"2013-06-07T21:50:31Z","isPatch":true,"sender":{"key":"benoit.person@ensimag.fr","avatar":null},"body":"From: Benoit Person <benoit.person@ensimag.fr>\n\nThe #7 issue on git-mediawiki's issue tracker [1] states that the ability to\npreview content without pushing would be a nice thing to have.\n\nThis commit is a first attempt to achieve it. It adds a new git command,\nnamed `git mw`. This command accepts the subcommands `help` and `preview`\nfor now.\n\nThe default behaviour for the `preview` subcommand is:\n1- Find the remote name of the current branch's upstream and check if it's a\nwiki one with its url (ie: mediawiki://)\n2- Parse the content of the local file (given as argument) using the distant\nwiki's API.\n3- Retrieve the current page on the distant mediawiki.\n4- Merge those those contents.\n5- Convert relative links to absolute ones.\n6- Save the result on disk.\n\nThe command also accepts argument for more controls:\n  --autoload | -a tries to launch the newly generated file in the user's \n                  default browser\n  --remote | -r provides a way to select the distant mediawiki in which the \n                user wants to preview his file.\n  --output | -o enables the user to choose the output filename. Default output \n                filename is based on the input filename in which the extension\n                `.mw` is replaced with `.html`.\n\nIt works but a couple of points trouble me: \n1-  I had to copy two functions from `git-remote-mediawiki.perl`, I don't \n    really know how we could \"factorize\" those things ? I don't think it makes \n    much sense to create a package just for them ?\n2-  The current behavior is to crash if the current branch do not have an\n    upstream branch on a valid mediawiki remote. To find that specific remote, \n    it runs `git rev-parse --symbolic-full-name @{upstream}` which will return \n    something like `/refs/remotes/$remote_name/master`.\n  2a-  maybe there is a better way to find that remote name ?\n  2b-  would it be useful to add a fallback if that search fails ? searching \n       for a valid mediawiki remote url in all the remotes returned by \n       `git remote` for instance ?\n3-  The current idea of merging the content of the mediawiki's current page \n    with new content fails when the page is a local creation. (Hence the \n    error message when we get a bad result from the `get` call l.129). I \n    thought about two ways to overcome this:\n  3a-  Use the wiki's homepage for the template.\n  3b-  A two-step process:\n       - first we create a general template (based on the wiki's homepage) \n         with a specific flag at the content position. This step is done only \n         if that template do not exists locally.\n       - replace the specific flag with the newly parsed content.\n       The downfall of those two \"solutions\" is on links like 'talk', \n       'view source' etc ... those will need to be updated to. And evven then, \n       it will still fails for page created only locally.\n4-  In the Makefile, there is certainly a more \"Makefily\" way to do it but I \n    had no luck finding it and still preserving the factorization for the \n    `build`, `install` and `clean` target. I ended up with something like this:\n\n    build: $(BUILD_SCRIPTS)\n    $(BUILD_SCRIPTS):\n        $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$@ \\\n                build-perl-script\n\n    install: ...\n    clean: ...\n\n    but clearly, for only two scripts, it's more a refucktoring than a \n    refactoring :/ .\n\n[1] https://github.com/moy/Git-Mediawiki/issues/7\n\n\nSigned-off-by: Benoit Person <benoit.person@ensimag.fr>\nSigned-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>\n\n---\n contrib/mw-to-git/Makefile    |   4 +\n contrib/mw-to-git/git-mw.perl | 249 ++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 253 insertions(+)\n create mode 100644 contrib/mw-to-git/git-mw.perl\n\ndiff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile\nindex f149719..0cba1e3 100644\n--- a/contrib/mw-to-git/Makefile\n+++ b/contrib/mw-to-git/Makefile\n@@ -5,13 +5,17 @@\n ## Build git-remote-mediawiki\n \n SCRIPT_PERL=git-remote-mediawiki.perl\n+SCRIPT_PERL_MW=git-mw.perl\n GIT_ROOT_DIR=../..\n HERE=contrib/mw-to-git/\n \n SCRIPT_PERL_FULL=$(patsubst %,$(HERE)/%,$(SCRIPT_PERL))\n+SCRIPT_PERL_MW_FULL=$(patsubst %,$(HERE)/%,$(SCRIPT_PERL_MW))\n \n all: build\n \n build install clean:\n \t$(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \\\n                 $@-perl-script\n+\t$(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_MW_FULL) \\\n+                $@-perl-script\n\\ No newline at end of file\ndiff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl\nnew file mode 100644\nindex 0000000..a92c459\n--- /dev/null\n+++ b/contrib/mw-to-git/git-mw.perl\n@@ -0,0 +1,249 @@\n+#! /usr/bin/perl\n+\n+# Copyright (C) 2013\n+#     Benoit Person <benoit.person@ensimag.imag.fr>\n+#     Celestin Matte <celestin.matte@ensimag.imag.fr>\n+# License: GPL v2 or later\n+\n+# Tools attached to git-remote-mediawiki (help, preview ...)\n+# Documentation & bugtracker: https://github.com/moy/Git-Mediawiki/\n+\n+use strict;\n+use warnings;\n+\n+use Git;\n+use MediaWiki::API;\n+\n+use Getopt::Long;\n+use HTML::TreeBuilder;\n+use URI::URL qw(url);\n+use IO::File;\n+use LWP::Simple;\n+use Carp;\n+use Readonly;\n+\n+# Constants\n+# Mediawiki filenames can contain forward slashes. This variable decides by which pattern they should be replaced\n+Readonly::scalar $SLASH_REPLACEMENT => \"%2F\";\n+\n+# Vars\n+my $file_name;\n+my $wiki;\n+my $remote_url;\n+\n+my $remote_name = '';\n+my $preview_file_name = '';\n+my $autoload = 0;\n+\n+my %commands = (\n+\t'help' =>\n+\t\t[\\&help, {}, \\&help_help],\n+\t'preview' =>\n+\t\t[\\&preview, {\n+\t\t\t'<>' => \\&file,\n+\t\t\t'output|o=s' => \\$preview_file_name,\n+\t\t\t'remote|r=s' => \\$remote_name,\n+\t\t\t'autoload|a' => \\$autoload\n+\t\t}, \\&preview_help]\n+);\n+\n+sub file {\n+\t$file_name = shift;\n+\treturn $file_name;\n+}\n+\n+# Search for sub-command\n+my $cmd = $commands{'help'};\n+for (my $i = 0; $i < @ARGV; $i++) {\n+\tif (defined $commands{$ARGV[$i]}) {\n+\t\t$cmd = $commands{$ARGV[$i]};\n+\t\tsplice @ARGV, $i, 1;\n+\t\tlast;\n+\t}\n+};\n+GetOptions( %{$cmd->[1]},\n+\t'help|h' => \\&{$cmd->[2]});\n+\n+# Launch command\n+&{$cmd->[0]};\n+\n+######################## Sub-Commands #############################\n+sub preview {\n+\tmy $wiki_page_name;\n+\tmy ($content, $content_tree, $template, $html_tree, $mw_content_text);\n+\n+\t# file_name argumeent is mandatory\n+\tif (! defined $file_name) {\n+\t\tcroak \"File not set, see `git mw help` \\n\";\n+\t}\n+\n+\tif (! -e $file_name) {\n+\t\tcroak \"File $file_name does not exist \\n\";\n+\t}\n+\n+\t# Default preview_file_name is file_name with .html ext\n+\tif ($preview_file_name eq '') {\n+\t\t$preview_file_name = $file_name;\n+\t\t$preview_file_name =~ s/\\.[^.]+$/.html/;\n+\t}\n+\n+\t# Transform file_name into a mediawiki page name\n+\t$wiki_page_name = mediawiki_smudge_filename($file_name);\n+\t$wiki_page_name =~ s/\\.[^.]+$//;\n+\n+\t# Find or verify remote name\n+\tif ($remote_name eq '') {\n+\t\t$remote_name = git_cmd_try {\n+\t\t\tGit::command_oneline('rev-parse', '--symbolic-full-name', '@{upstream}') }\n+\t\t\t\"%s failed w/ code %d\";\n+\t\t$remote_name =~ s/refs\\/remotes\\/(.+)\\/(.+)/$1/\n+\t\t\tor croak \"Could not find remote name\";\n+\t} else {\n+\t\tmy @remotes = git_cmd_try {\n+\t\t\tGit::command('remote') }\n+\t\t\t\"%s failed w/ code %d\";\n+\t\tgrep { $_ eq $remote_name } @remotes\n+\t\t\tor croak \"$remote_name is not a remote\";\n+\t}\n+\n+\t# Find remote url\n+\t$remote_url = git_cmd_try {\n+\t\tGit::config(\"remote.$remote_name.url\") }\n+\t\t\"%s failed w/ code %d\";\n+\t$remote_url =~ s/mediawiki::(.*)/$1/\n+\t\tor croak \"Current remote is not a mediawiki\";\n+\t$remote_url = url($remote_url)->canonical;\n+\n+\t# Create and connect to the wiki if necessary\n+\t$wiki = MediaWiki::API->new;\n+\t$wiki->{config}->{api_url} = \"$remote_url/api.php\";\n+\tmw_connect_maybe();\n+\n+\t# Read file content\n+\topen my $fh, \"<\", $file_name\n+\t\tor croak \"could not open $file_name: $!\";\n+\tmy $document = do { local $/ = undef; <$fh> };\n+\tclose $fh;\n+\n+\t# Load template page\n+\t$template = get(\"$remote_url/index.php?title=$wiki_page_name\")\n+\t\tor croak \"You need to create $wiki_page_name before previewing it\";\n+\t$html_tree = HTML::TreeBuilder->new;\n+\t$html_tree->parse($template);\n+\n+\t# Load new content\n+\t$content = $wiki->api({\n+\t\taction => 'parse',\n+\t\ttext => $document,\n+\t\ttitle => $wiki_page_name\n+\t}) or croak 'No response from distant mediawiki';\n+\t$content = $content->{'parse'}->{'text'}->{'*'};\n+\t$content_tree = HTML::TreeBuilder->new;\n+\t$content_tree->parse($content);\n+\n+\t# Replace old content with new one\n+\t$mw_content_text = $html_tree->look_down('id', 'mw-content-text');\n+\t$mw_content_text->delete_content();\n+\t$mw_content_text->push_content($content_tree);\n+\n+\t# Transform relative links into absolute ones\n+\tfor (@{ $html_tree->extract_links() }) {\n+\t\tmy ($link, $element, $attr) = @$_;\n+\t\tmy $url = url($link)->canonical;\n+\t\t$element->attr($attr, URI->new_abs($url, $remote_url));\n+\t}\n+\n+\t# Save the preview file\n+\t$fh = IO::File->new($preview_file_name, O_WRONLY|O_CREAT)\n+\t\tor croak \"Could not open: $!\";\n+\t$fh->print($html_tree->as_HTML);\n+\n+\t# Auto-loading in browser\n+\tif ($autoload) {\n+\t\topen(my $browser, \"-|:encoding(UTF-8)\", \"xdg-open \".$preview_file_name);\n+\t\tmy $res = do { local $/ = undef; <$browser> };\n+\t\tclose($browser);\n+\t} else {\n+\t\tprint \"preview file saved as: $preview_file_name\\n\";\n+\t}\n+\n+\texit;\n+}\n+\n+######################## Help Functions ###########################\n+\n+sub help {\n+\tprint <<'END';\n+usage: git mw <command> <args>\n+\n+git mw commands are:\n+    Help        Display help information about git mw\n+    preview     Render a local file into an HTML file\n+END\n+\texit;\n+}\n+\n+sub help_help {\n+\tprint <<'END';\n+usage: git mw help\n+END\n+\texit;\n+}\n+\n+sub preview_help {\n+\tprint <<'END';\n+usage: git mw preview [--remote|-r <remote name>] [--autoload|-a]\n+                      [--output|-o <output filename>] <filename>\n+\n+    -r, --remote    Specify which mediawiki should be used\n+    -o, --output    Name of the output file\n+    -a, --autoload  Try to autoload the page in the default browser\n+END\n+\texit;\n+}\n+\n+########################## Functions ##############################\n+\n+sub mediawiki_smudge_filename {\n+\tmy $filename = shift;\n+\t$filename =~ s/\\//@{[$SLASH_REPLACEMENT]}/gx;\n+\t$filename =~ s/ /_/g;\n+\t# Decode forbidden characters encoded in mediawiki_clean_filename\n+\t$filename =~ s/_%_([0-9a-fA-F][0-9a-fA-F])/sprintf(\"%c\", hex($1))/gex;\n+\treturn $filename;\n+}\n+\n+sub mw_connect_maybe {\n+\tmy ($wiki_login, $wiki_password, $wiki_domain);\n+\n+\tgit_cmd_try {\n+\t\t$wiki_login = Git::config(\"remote.$remote_name.mwLogin\");\n+\t\t$wiki_password = Git::config(\"remote.$remote_name.mwPassword\");\n+\t\t$wiki_domain = Git::config(\"remote.$remote_name.mwDomain\");}\n+\t\t\"%s failed w/ code %d\";\n+\n+\tif ($wiki_login) {\n+\t\tmy %credential = (\n+\t\t\t'url' => $remote_url,\n+\t\t\t'username' => $wiki_login,\n+\t\t\t'password' => $wiki_password);\n+\t\tGit::credential(\\%credential);\n+\t\tmy $request = {\n+\t\t\tlgname => $credential{username},\n+\t\t\tlgpassword => $credential{password},\n+\t\t\tlgdomain => $wiki_domain};\n+\t\tif ($wiki->login($request)) {\n+\t\t\tGit::credential(\\%credential, 'approve');\n+\t\t\tprint STDERR \"Logged in mediawiki user \\\"$credential{username}\\\".\\n\";\n+\t\t} else {\n+\t\t\tprint STDERR \"Failed to log in mediawiki user \\\"$credential{username}\\\" on $remote_url\\n\";\n+\t\t\tprint STDERR \"  (error \" .\n+\t\t\t\t$wiki->{error}->{code} . ': ' .\n+\t\t\t\t$wiki->{error}->{details} . \")\\n\";\n+\t\t\tGit::credential(\\%credential, 'reject');\n+\t\t\texit 1;\n+\t\t}\n+\t}\n+\n+\treturn;\n+}\n\\ No newline at end of file\n-- \n1.8.3.rc3.7.gc2f33ed.dirty\n"},{"id":"219856","messageId":"vpqzjv0tokx.fsf@anie.imag.fr","threadId":"34054","inReplyTo":"1370641831-9115-1-git-send-email-benoit.person@ensimag.fr","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-08T19:00:30Z","receivedAt":"2013-06-08T19:00:30Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"benoit.person@ensimag.fr writes:\n\n> From: Benoit Person <benoit.person@ensimag.fr>\n>\n> The #7 issue on git-mediawiki's issue tracker [1] states that the ability to\n> preview content without pushing would be a nice thing to have.\n>\n> This commit is a first attempt to achieve it. It adds a new git command,\n> named `git mw`. This command accepts the subcommands `help` and `preview`\n> for now.\n\nReview could be easier if you have PATCH 1/2 introducing the command\nwith only \"help\" (essentially to check that the build system works), and\nthen focus on \"preview\".\n\nI won't insist in splitting this particular commit, just take it as an\nadvice for future work.\n\n> --- a/contrib/mw-to-git/Makefile\n> +++ b/contrib/mw-to-git/Makefile\n> @@ -5,13 +5,17 @@\n>  ## Build git-remote-mediawiki\n>  \n>  SCRIPT_PERL=git-remote-mediawiki.perl\n> +SCRIPT_PERL_MW=git-mw.perl\n\nWhy do you need another variable? Just adding git-mw.perl to SCRIPT_PERL\nshould do it, no? (Well, probably the make SCRIPT_PERL=$(SCRIPT_PERL)\nlacks quotes around the argument, but then you should fix that).\n\n> +# Constants\n> +# Mediawiki filenames can contain forward slashes. This variable decides by which pattern they should be replaced\n> +Readonly::scalar $SLASH_REPLACEMENT => \"%2F\";\n\nThis one is copied from git-remote-mediawiki.perl, and is a\ngit-mediawiki specific thing, so it would not make sense to put it into\nGit.pm. This starts convincing me that we should have a GitMediawiki.pm\nor so, and both scripts should use it.\n\nAnother option would be to put everything in git-remote-mediawiki.perl,\nand probably to have \"git mw\" as a wrapper around it (to avoid having to\ntype \"git remote-mediawiki\" which is a bit long).\n\nBut the script starts being a bit long, so I think it makes more sense\nto split it. So I'd say\n\nPATCH 1/3 : introduce \"git mw\"\nPATCH 2/3 : move sharable code to a new module (and make sure it's\n            installed properly by \"make install\")\nPATCH 3/3 : actually implement the preview feature\n\nPerhaps others will have other/better advices.\n\n> +\t# Auto-loading in browser\n> +\tif ($autoload) {\n> +\t\topen(my $browser, \"-|:encoding(UTF-8)\", \"xdg-open \".$preview_file_name);\n\nThat could be read from Git's configuration, and default to xdg-open.\nBut you don't want to hardcode it in the middle of the code.\n\nAlso, why use open if you don't want to communicate with the process?\nsystem would be sufficient, and won't need close.\n\nPrefer passing an array of arguments, instead of concatenating strings\nand then rely on command-line parsing to re-split it.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"219889","messageId":"20130609060807.GA8906@sigill.intra.peff.net","threadId":"34054","inReplyTo":"1370641831-9115-1-git-send-email-benoit.person@ensimag.fr","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T06:08:07Z","receivedAt":"2013-06-09T06:08:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 07, 2013 at 11:50:31PM +0200, benoit.person@ensimag.fr wrote:\n\n> The #7 issue on git-mediawiki's issue tracker [1] states that the ability to\n> preview content without pushing would be a nice thing to have.\n\nSounds like a useful goal.\n\n> The default behaviour for the `preview` subcommand is:\n> 1- Find the remote name of the current branch's upstream and check if it's a\n> wiki one with its url (ie: mediawiki://)\n> 2- Parse the content of the local file (given as argument) using the distant\n> wiki's API.\n\nMakes sense.\n\n> 3- Retrieve the current page on the distant mediawiki.\n> 4- Merge those those contents.\n\nI'm not sure what these steps are for. You are trying to preview not\njust your local version, but pulling in any changes that have happened\nupstream since the work you built on top of?\n\nIt seems like that is a separate, orthogonal issue, and git would be the\nright place to do that merge. IOW, as a user, your workflow would be\nsomething like:\n\n  1. git fetch, pulling down the latest copy from the server\n\n  2. make your changes on top\n\n  3. use this command to preview your changes\n\n  4. use git fetch to check whether anything else happened on the\n     server.\n\n       a. If not, go ahead and push.\n\n       b. If upstream changed, use \"git diff\" to inspect the changes to\n          the wiki source. Merge or rebase your changes with respect to\n          what's on the server. Goto step 3 to make sure they look good.\n\nI also wonder if it would be useful to be able to specify not only files\nin the filesystem, but also arbitrary blobs. So in 4b above, you could\n\"git mw preview origin:page.mw\" to see the rendered version of what\nupstream has done.\n\n> It works but a couple of points trouble me: \n> 1-  I had to copy two functions from `git-remote-mediawiki.perl`, I don't \n>     really know how we could \"factorize\" those things ? I don't think it makes \n>     much sense to create a package just for them ?\n\nYou could make a Git::MediaWiki.pm module, but installing that would\nsignificantly complicate the build procedure, and potentially be\nannoying for users. One trick I have done in the past is to concatenate\nbits of perl script together in the Makefile, like this:\n\n  foo: common.pl foo.pl\n          { \\\n            echo '$(PERL_PATH_SQ)' && \\\n            for i in $^; do \\\n              echo \"#line 1 $src\" && \\\n                cat $src \\\n            done \\\n          } >$@+\n          mv $@+ $@\n\nThat would conflict a bit with the way we chain to git's Makefile,\nthough. I suspect you could do something complicated like build \"foo.pl\"\nfrom \"common.pl\" and \"foo-main.pl\", then chain to git's Makefile to\nbuild \"foo\" from \"foo.pl\".\n\n> 2-  The current behavior is to crash if the current branch do not have an\n>     upstream branch on a valid mediawiki remote. To find that specific remote, \n>     it runs `git rev-parse --symbolic-full-name @{upstream}` which will return \n>     something like `/refs/remotes/$remote_name/master`.\n>   2a-  maybe there is a better way to find that remote name ?\n\nIf you just care about the remote name and not the name of the local\nbranch, you can just ask for\n\n  my $curr_branch = `git symbolic-ref HEAD`;\n  my $remote = `git config \"branch.$curr_branch.remote\"`;\n  my $url = `git config \"remote.$remote.url\"`;\n\nOf course you would want some error checks and probably some chomp()s in\nthere, too.\n\n>   2b-  would it be useful to add a fallback if that search fails ? searching \n>        for a valid mediawiki remote url in all the remotes returned by \n>        `git remote` for instance ?\n\nThat is probably OK as long as there is only one such remote, and it\nwould help the case where you have branched off of a local branch (so\nyour upstream remote is \".\").  If there are two mediawiki remotes,\nthough, it would make sense to simply fail, as you don't know which to\nuse. But I'd expect the common case by far to be that you simply have\none such remote.\n\n-Peff\n"},{"id":"219890","messageId":"20130609061222.GB8906@sigill.intra.peff.net","threadId":"34054","inReplyTo":"vpqzjv0tokx.fsf@anie.imag.fr","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T06:12:22Z","receivedAt":"2013-06-09T06:12:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jun 08, 2013 at 09:00:30PM +0200, Matthieu Moy wrote:\n\n> > +\t# Auto-loading in browser\n> > +\tif ($autoload) {\n> > +\t\topen(my $browser, \"-|:encoding(UTF-8)\", \"xdg-open \".$preview_file_name);\n> \n> That could be read from Git's configuration, and default to xdg-open.\n> But you don't want to hardcode it in the middle of the code.\n\nIn fact, I think we provide the \"git-web--browse\" tool for just this\npurpose. It takes care of the trickiness of looking at the \"web.browser\"\nconfig, resolving custom browser tools defined by \"browser.<tool>.*\",\nand handling backgrounding of the browser (which you want to do for\ngraphical browsers but not for terminal ones).\n\n-Peff\n\nPS I agreed with all of the other comments in your review. :)\n"},{"id":"219951","messageId":"vpq38srtun7.fsf@anie.imag.fr","threadId":"34054","inReplyTo":"20130609060807.GA8906@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-09T11:01:48Z","receivedAt":"2013-06-09T11:01:48Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n>> 1- Find the remote name of the current branch's upstream and check if it's a\n>> wiki one with its url (ie: mediawiki://)\n>> 2- Parse the content of the local file (given as argument) using the distant\n>> wiki's API.\n>\n> Makes sense.\n>\n>> 3- Retrieve the current page on the distant mediawiki.\n>> 4- Merge those those contents.\n>\n> I'm not sure what these steps are for. You are trying to preview not\n> just your local version, but pulling in any changes that have happened\n> upstream since the work you built on top of?\n\nSame question here. I'd expect \"git mw preview\" in a mediawiki workflow\nto do what \"pdflatex foo && evince foo.pdf\" do in a latex workflow: see\nin rendered form what I've been doing.\n\nIn a latex flow, if I want to see how my local changes merge with the\nremote ones, I do \"git merge && pdflatex\", and I'd do the same with \"git\nmw\".\n\n> I also wonder if it would be useful to be able to specify not only files\n> in the filesystem, but also arbitrary blobs. So in 4b above, you could\n> \"git mw preview origin:page.mw\" to see the rendered version of what\n> upstream has done.\n\nNext step could even be \"git mw diff $from $to\", using the wiki to\nrender the diff. Not a priority, but could be funny.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"219956","messageId":"CAETqRCjO1Md1PFmFO46KQ6eaEHbHW+RA7+Fh8ku6s7UwfhrPvQ@mail.gmail.com","threadId":"34054","inReplyTo":"vpq38srtun7.fsf@anie.imag.fr","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Benoît Person","fromEmail":"benoit.person@ensimag.fr","sentAt":"2013-06-09T12:18:58Z","receivedAt":"2013-06-09T12:18:58Z","isPatch":true,"sender":{"key":"benoit.person@ensimag.fr","avatar":null},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n> Same question here. I'd expect \"git mw preview\" in a mediawiki workflow\n> to do what \"pdflatex foo && evince foo.pdf\" do in a latex workflow: see\n> in rendered form what I've been doing.\n>\n> In a latex flow, if I want to see how my local changes merge with the\n> remote ones, I do \"git merge && pdflatex\", and I'd do the same with \"git\n> mw\".\n\nIn fact, I should not have used \"merge\" to describe how the two contents\n(page template + new parsed content) are combined together. For\nnow, the code simply replaces the template page's text content (the one\nretrieved from the remote) with the new one. It does not really care if\nthe remote has changes or not. (And, to be honest, I did not thought\nabout that issue ;) ).\n\nBut, like both of you said : in a typical workflow, the merging would be\nleft to the user so the current behavior is fine I think ?\n\n>> I also wonder if it would be useful to be able to specify not only files\n>> in the filesystem, but also arbitrary blobs. So in 4b above, you could\n>> \"git mw preview origin:page.mw\" to see the rendered version of what\n>> upstream has done.\n> Next step could even be \"git mw diff $from $to\", using the wiki to\n> render the diff. Not a priority, but could be funny.\n\nI searched in the Mediawiki API if there was a way to diff from a stored\nrevision and raw text content but I've found nothing :/ . We could make\na little \"hack\" to do that by saving as a new revision the local content,\nand use the \"DeleteRevision\"-thingy from Mediawiki [1] to hide this\nuseless revision but it would floods the remote DB and usually users\nto not have the permission to use that tool. So, for now I would say\nit's a no-go :/ .\n\n[1] http://www.mediawiki.org/wiki/Manual:RevisionDelete\n\nBenoit Person\n\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"219957","messageId":"CAETqRCh9frekD8yiR0bE+WQ7b_et1th8p_LsqrL8NhPnC8yaow@mail.gmail.com","threadId":"34054","inReplyTo":"20130609060807.GA8906@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Benoît Person","fromEmail":"benoit.person@ensimag.fr","sentAt":"2013-06-09T12:35:45Z","receivedAt":"2013-06-09T12:35:45Z","isPatch":true,"sender":{"key":"benoit.person@ensimag.fr","avatar":null},"body":"On 9 June 2013 08:08, Jeff King <peff@peff.net> wrote:\n> I also wonder if it would be useful to be able to specify not only files\n> in the filesystem, but also arbitrary blobs. So in 4b above, you could\n> \"git mw preview origin:page.mw\" to see the rendered version of what\n> upstream has done.\n\nHum, so `git mw preview origin:page.mw` would just do the get\nrequest to the remote mediawiki, save it locally and - maybe - load it\nin the browser ? Is it really better than just opening the browser and\ntyping the right URL ?\n\nCurrently, this URL is one click away when you have preview file loaded\nin a web browser.\n\n>> It works but a couple of points trouble me:\n>> 1-  I had to copy two functions from `git-remote-mediawiki.perl`, I don't\n>>     really know how we could \"factorize\" those things ? I don't think it makes\n>>     much sense to create a package just for them ?\n>\n> You could make a Git::MediaWiki.pm module, but installing that would\n> significantly complicate the build procedure, and potentially be\n> annoying for users. One trick I have done in the past is to concatenate\n> bits of perl script together in the Makefile, like this:\n>\n>   foo: common.pl foo.pl\n>           { \\\n>             echo '$(PERL_PATH_SQ)' && \\\n>             for i in $^; do \\\n>               echo \"#line 1 $src\" && \\\n>                 cat $src \\\n>             done \\\n>           } >$@+\n>           mv $@+ $@\n>\n> That would conflict a bit with the way we chain to git's Makefile,\n> though. I suspect you could do something complicated like build \"foo.pl\"\n> from \"common.pl\" and \"foo-main.pl\", then chain to git's Makefile to\n> build \"foo\" from \"foo.pl\".\n\nok, thanks a lot.\n\n>> 2-  The current behavior is to crash if the current branch do not have an\n>>     upstream branch on a valid mediawiki remote. To find that specific remote,\n>>     it runs `git rev-parse --symbolic-full-name @{upstream}` which will return\n>>     something like `/refs/remotes/$remote_name/master`.\n>>   2a-  maybe there is a better way to find that remote name ?\n>\n> If you just care about the remote name and not the name of the local\n> branch, you can just ask for\n>\n>   my $curr_branch = `git symbolic-ref HEAD`;\n>   my $remote = `git config \"branch.$curr_branch.remote\"`;\n>   my $url = `git config \"remote.$remote.url\"`;\n>\n> Of course you would want some error checks and probably some chomp()s in\n> there, too.\n\nThe fact is, `git symbolic-ref HEAD` result would have to be parsed in order\nto extract the current branch name like I currently extract the remote name.\nSo, is it really better than `git rev-parse --symbolic-full-name @{upstream}` ?\n\n>>   2b-  would it be useful to add a fallback if that search fails ? searching\n>>        for a valid mediawiki remote url in all the remotes returned by\n>>        `git remote` for instance ?\n>\n> That is probably OK as long as there is only one such remote, and it\n> would help the case where you have branched off of a local branch (so\n> your upstream remote is \".\").  If there are two mediawiki remotes,\n> though, it would make sense to simply fail, as you don't know which to\n> use. But I'd expect the common case by far to be that you simply have\n> one such remote.\n\nWell, I thought that `git mw preview` could provide an interactive mode\nwhere, if the first search fails, it would find all the mediawiki remotes, and\noffers to the user a way to choose the remote ?\n\nBenoit Person\n\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"219961","messageId":"vpqfvwrs63f.fsf@anie.imag.fr","threadId":"34054","inReplyTo":"CAETqRCh9frekD8yiR0bE+WQ7b_et1th8p_LsqrL8NhPnC8yaow@mail.gmail.com","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-09T14:37:24Z","receivedAt":"2013-06-09T14:37:24Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Benoît Person <benoit.person@ensimag.fr> writes:\n\n> On 9 June 2013 08:08, Jeff King <peff@peff.net> wrote:\n>> I also wonder if it would be useful to be able to specify not only files\n>> in the filesystem, but also arbitrary blobs. So in 4b above, you could\n>> \"git mw preview origin:page.mw\" to see the rendered version of what\n>> upstream has done.\n>\n> Hum, so `git mw preview origin:page.mw` would just do the get\n> request to the remote mediawiki, save it locally and - maybe - load it\n> in the browser ? Is it really better than just opening the browser and\n> typing the right URL ?\n>\n> Currently, this URL is one click away when you have preview file loaded\n> in a web browser.\n\norigin:page.mw is not necessarily the best example, but HEAD^:page.mw\ncan exist in your local history and not on the wiki. Even HEAD:page.mw\ncan be interesting if you have uncommited changes. Not that it's\nterribly useful to be able to preview it, but once you can deal with\nlocal files, it should be easy enough to generalize it to any blob.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"220079","messageId":"20130609181302.GD810@sigill.intra.peff.net","threadId":"34054","inReplyTo":"vpq38srtun7.fsf@anie.imag.fr","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T18:13:02Z","receivedAt":"2013-06-09T18:13:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 09, 2013 at 01:01:48PM +0200, Matthieu Moy wrote:\n\n> > I also wonder if it would be useful to be able to specify not only files\n> > in the filesystem, but also arbitrary blobs. So in 4b above, you could\n> > \"git mw preview origin:page.mw\" to see the rendered version of what\n> > upstream has done.\n> \n> Next step could even be \"git mw diff $from $to\", using the wiki to\n> render the diff. Not a priority, but could be funny.\n\nI was actually thinking along the same lines. I often do something\nsimilar with Git's documentation. When you are tweaking the formatting\nor an asciidoc knob, it is useful to diff the rendered output to check\nthat the changes had the effect you wanted.\n\nI usually have done so by hand, but I actually wonder if \"git difftool\"\ncould be used as a wrapper for this (I suspect not, because you have to\ndeal with the whole build tree, not just individual blobs).\n\n-Peff\n"},{"id":"220088","messageId":"20130609183247.GF810@sigill.intra.peff.net","threadId":"34054","inReplyTo":"CAETqRCh9frekD8yiR0bE+WQ7b_et1th8p_LsqrL8NhPnC8yaow@mail.gmail.com","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T18:32:47Z","receivedAt":"2013-06-09T18:32:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 09, 2013 at 02:35:45PM +0200, Benoît Person wrote:\n\n> On 9 June 2013 08:08, Jeff King <peff@peff.net> wrote:\n> > I also wonder if it would be useful to be able to specify not only files\n> > in the filesystem, but also arbitrary blobs. So in 4b above, you could\n> > \"git mw preview origin:page.mw\" to see the rendered version of what\n> > upstream has done.\n> \n> Hum, so `git mw preview origin:page.mw` would just do the get\n> request to the remote mediawiki, save it locally and - maybe - load it\n> in the browser ? Is it really better than just opening the browser and\n> typing the right URL ?\n\nNot really, but when you start doing \"origin^:page.mw\", it may make more\nof a difference.\n\n> > If you just care about the remote name and not the name of the local\n> > branch, you can just ask for\n> >\n> >   my $curr_branch = `git symbolic-ref HEAD`;\n> >   my $remote = `git config \"branch.$curr_branch.remote\"`;\n> >   my $url = `git config \"remote.$remote.url\"`;\n> >\n> > Of course you would want some error checks and probably some chomp()s in\n> > there, too.\n> \n> The fact is, `git symbolic-ref HEAD` result would have to be parsed in order\n> to extract the current branch name like I currently extract the remote name.\n> So, is it really better than `git rev-parse --symbolic-full-name @{upstream}` ?\n\nIt is, because it is not strictly true that an upstream of\n\"refs/remotes/foo/*\" is for the remote \"foo\" (though in 99% of cases, it\nis). To find the upstream, git looks at branch.$curr_branch.remote, then\ncalculates the upstream based on the fetch refspecs. Then you try to\nundo that by converting it back from the right-hand side of the fetch\nrefspec into a remote name. It would be much easier to just look at the\nconfig. :)\n\nAnd yes, you do need the short name of the branch from HEAD, not the\nfull refname. You can use \"git symbolic-ref --short\" for that. You also\nshould check that it returns something useful (i.e., that we are not on\na detached HEAD).\n\n> > That is probably OK as long as there is only one such remote, and it\n> > would help the case where you have branched off of a local branch (so\n> > your upstream remote is \".\").  If there are two mediawiki remotes,\n> > though, it would make sense to simply fail, as you don't know which to\n> > use. But I'd expect the common case by far to be that you simply have\n> > one such remote.\n> \n> Well, I thought that `git mw preview` could provide an interactive mode\n> where, if the first search fails, it would find all the mediawiki remotes, and\n> offers to the user a way to choose the remote ?\n\nThat's fine; just as long as we do not silently produce output from an\nunknown source when there is ambiguity.\n\nYou can do an interactive selection, or even just say something like:\n\n  There are multiple mediawiki remotes, and I do not know which one you\n  want to use for your preview. Which of:\n\n    remote1\n    remote2\n\n  did you mean? Try using the \"-r\" option to specify the remote.\n\nand then let the user repeat their command with the \"-r\" option using\nshell history. That saves you from having to write an interactive\ncomponent, and teaches the user how to script it.\n\n-Peff\n"},{"id":"220512","messageId":"CAETqRCiJmnz_1yjwvyWx+=kPkt3M+vKk--CnS=rnQcDA4wMSmg@mail.gmail.com","threadId":"34054","inReplyTo":"20130609060807.GA8906@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Benoît Person","fromEmail":"benoit.person@ensimag.fr","sentAt":"2013-06-11T21:31:31Z","receivedAt":"2013-06-11T21:31:31Z","isPatch":true,"sender":{"key":"benoit.person@ensimag.fr","avatar":null},"body":"The V2 is on the launchpad but I am still struggling with the code\nfactoring between git-mw.perl and git-remote-mediawiki.perl :/ .\n\nOn 9 June 2013 08:08, Jeff King <peff@peff.net> wrote:\n>\n> You could make a Git::MediaWiki.pm module, but installing that would\n> significantly complicate the build procedure, and potentially be\n> annoying for users. One trick I have done in the past is to concatenate\n> bits of perl script together in the Makefile, like this:\n>\n>   foo: common.pl foo.pl\n>           { \\\n>             echo '$(PERL_PATH_SQ)' && \\\n>             for i in $^; do \\\n>               echo \"#line 1 $src\" && \\\n>                 cat $src \\\n>             done \\\n>           } >$@+\n>           mv $@+ $@\n>\n> That would conflict a bit with the way we chain to git's Makefile,\n> though. I suspect you could do something complicated like build \"foo.pl\"\n> from \"common.pl\" and \"foo-main.pl\", then chain to git's Makefile to\n> build \"foo\" from \"foo.pl\".\n\nI've implemented this one for now but after a real-life meeting with\nMatthieu Moy we discussed the possibility to build a GitMediawiki.pm\nmodule. It seems more \"clean\" than the concatenation of perl scripts.\nPlus, it would force people to limit side effects inside the functions\nused in this package/utils file (I have in mind the mw_connect_maybe\nfunction here and a couple of others which directly *hope* for global\nvars to be set to a nice value before being called).\n\nWhat I find bad in the concatenating-thingy is the mandatory rename of\ngit-mw.perl into something like git-mw.unmerged.perl and\ngit-remote-mediawiki.perl into git-remote-mediawiki.unmerged.perl.\nOtherwise, like you said, it would be hard to chain to git's Makefile\nafter the merge.\n\nFor now, I have really no idea which one is the best. If I may ask,\nwhat did you have in mind while saying:\n\n> You could make a Git::MediaWiki.pm module, but installing that would\n> significantly complicate the build procedure, and potentially be\n> annoying for users.\n\n?\n\nSince my previous commit (ea07ec1 in next - use Git.pm functions for\ncredentials), git-remote-mediawiki.perl already depends on the proper\ninstallation of the Git.pm package. In what ways the need for the\ninstallation of yet another package (GitMediawiki.pm) would annoy a\nuser ?\n\nThank you for your time,\n\nBenoit\n"},{"id":"220513","messageId":"20130611213722.GA21203@sigill.intra.peff.net","threadId":"34054","inReplyTo":"CAETqRCiJmnz_1yjwvyWx+=kPkt3M+vKk--CnS=rnQcDA4wMSmg@mail.gmail.com","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-11T21:37:22Z","receivedAt":"2013-06-11T21:37:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 11, 2013 at 11:31:31PM +0200, Benoît Person wrote:\n\n> I've implemented this one for now but after a real-life meeting with\n> Matthieu Moy we discussed the possibility to build a GitMediawiki.pm\n> module. It seems more \"clean\" than the concatenation of perl scripts.\n> Plus, it would force people to limit side effects inside the functions\n> used in this package/utils file (I have in mind the mw_connect_maybe\n> function here and a couple of others which directly *hope* for global\n> vars to be set to a nice value before being called).\n> \n> What I find bad in the concatenating-thingy is the mandatory rename of\n> git-mw.perl into something like git-mw.unmerged.perl and\n> git-remote-mediawiki.perl into git-remote-mediawiki.unmerged.perl.\n> Otherwise, like you said, it would be hard to chain to git's Makefile\n> after the merge.\n\nYeah, I agree it's very hacky.\n\n> For now, I have really no idea which one is the best. If I may ask,\n> what did you have in mind while saying:\n> \n> > You could make a Git::MediaWiki.pm module, but installing that would\n> > significantly complicate the build procedure, and potentially be\n> > annoying for users.\n> \n> Since my previous commit (ea07ec1 in next - use Git.pm functions for\n> credentials), git-remote-mediawiki.perl already depends on the proper\n> installation of the Git.pm package. In what ways the need for the\n> installation of yet another package (GitMediawiki.pm) would annoy a\n> user ?\n\nI was thinking that you would be self-contained inside the\ncontrib/mw-to-git directory, and therefore you would have to teach your\ncode how to install the Git module, and you could not longer just \"cp\ngit-remote-mediawiki\" into the right place to install it.\n\nBut I think we have already crossed that bridge somewhat with Git.pm.\nAnd if you add your module as perl/Git/MediaWiki.pm and use the existing\nperl build system, then it is not any extra effort from the build\nsystem.\n\nThat is probably the most sane way to go.\n\n-Peff\n"},{"id":"220583","messageId":"vpqli6f24z3.fsf@anie.imag.fr","threadId":"34054","inReplyTo":"20130611213722.GA21203@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-12T06:55:12Z","receivedAt":"2013-06-12T06:55:12Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> I was thinking that you would be self-contained inside the\n> contrib/mw-to-git directory, and therefore you would have to teach your\n> code how to install the Git module, and you could not longer just \"cp\n> git-remote-mediawiki\" into the right place to install it.\n>\n> But I think we have already crossed that bridge somewhat with Git.pm.\n> And if you add your module as perl/Git/MediaWiki.pm and use the existing\n> perl build system, then it is not any extra effort from the build\n> system.\n\nI'm not sure having perl/Git/MediaWiki.pm would be a good idea: this\nMediaWiki.pm would be really a mediawiki thing more than a Git thing, so\nthe Git main tree probably want to stay away from it and keep it in\ncontrib.\n\nBut you should be able to use contrib/mw-to-git/perl/GitMediawiki.pm or\nsomething like that and chain to ../../perl/Makefile in\ncontrib/mw-to-git/Makefile.\n\nAlso, for now, git-remote-mediawiki works only after you run \"make\ninstall\" in Git's toplevel. I think that's ok, but it would be weird to\nbe able to use/test git-remote-mediawiki only after doing a \"make\ninstall\" to deploy the new mediawiki Perl module.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"220590","messageId":"20130612085502.GA1935@sigill.intra.peff.net","threadId":"34054","inReplyTo":"vpqli6f24z3.fsf@anie.imag.fr","subject":"Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-12T08:55:02Z","receivedAt":"2013-06-12T08:55:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 12, 2013 at 08:55:12AM +0200, Matthieu Moy wrote:\n\n> > But I think we have already crossed that bridge somewhat with Git.pm.\n> > And if you add your module as perl/Git/MediaWiki.pm and use the existing\n> > perl build system, then it is not any extra effort from the build\n> > system.\n> \n> I'm not sure having perl/Git/MediaWiki.pm would be a good idea: this\n> MediaWiki.pm would be really a mediawiki thing more than a Git thing, so\n> the Git main tree probably want to stay away from it and keep it in\n> contrib.\n\nYes, it's ugly. It means that the mediawiki stuff creeps out of contrib\nand into the main tree; and worse, as part of a public API that gets\ninstalled. We'd have to be a lot more picky about the interface and the\ncode quality.\n\n> But you should be able to use contrib/mw-to-git/perl/GitMediawiki.pm or\n> something like that and chain to ../../perl/Makefile in\n> contrib/mw-to-git/Makefile.\n\nThat might work. Most of the magic in perl/Makefile happens in the\nperl-generated MakeMaker bits, though, so it may not be that easy. I\nhaven't looked.\n\n> Also, for now, git-remote-mediawiki works only after you run \"make\n> install\" in Git's toplevel. I think that's ok, but it would be weird to\n> be able to use/test git-remote-mediawiki only after doing a \"make\n> install\" to deploy the new mediawiki Perl module.\n\nGood point.\n\n-Peff\n"}]}